I love the capabilities that this CLI provides, but it's real world implementation is a nightmare. Let's say for instance someone has a pre-existing project using A1 with Jade/Pug. The conversion to A2 is extremely problematic. Beyond having to gulp your jade/pug into basic html before you build your project, the build process dumps all of it's created files into one directory "dist". From the outside this seems fine, and for some simple implementations of A2 it would be fine. But for more real world solutions it is very problematic. First off, the resulting html and JS files should be able to be relocated (split into different directories) defined by entries in the angular-cli.json.
MEAN stack project example
If we point the build to output it's contents to where we can display the resulting HTML '/views/dist', then we cannot access the accompanying .JS bundles. If we output the contents of the build to our public folders like "/public/dist", then our node routing cannot access the HTML.
So beyond moving either the JS or HTML results to separate directories manually, this solution doesn't work for us.
Now beyond that, once you have separated the HTML & JS bundles it would make things very handy if you could generate an additional HTML file within the build results. This file would ONLY have the references to the JS bundles; say you name it Resouces.html.
Example "Resources.html":
* assume these are formatted appropriately *
src="/js/custom/location/inline.js"
src="/js/custom/location/main.4b35c69fe3ac9cc5dbdd.bundle.js"
If you generated the "Resources.html" file in the build process, then we could simply include it in our base Jade/Pug starting point and forgo working with the resulting HTML entirely.
Currently, even with all of the shuffling around we are doing our base (app-entry) jade/pug file looks like this.
block content
include index.html
If you have further questions or need examples, I would be happy to provide them.
All the best,
-d
You don't have to use this and you can always do a PR
a PR? I want to use the CLI for the bundling and minification support.
@fullstackdave you're coming at it pretty strong. The conversion from Angular 1 to Angular 2 is not extremely problematic and is actually pretty straight forward and documented. If you're using Jade / Pug you can continue to do so if you want to maintain your build pipeline. If you want to begin leveraging the CLI for generation you can still use a custom serve and build pipeline. You don't have to use everything.
Furthermore there are no issues when it comes to serving an Angular CLI based app from node. I do this on a regular basis for my current employer. Instead of using a ng serve you could use ng build --watch then point node to the dist directory. Add in a send index for anything your router would pick up and you're good to go.
The CLI does provide bundling, minification, and now AOT, all brought to the community by mostly volunteers contributing in their free time after working a full time job.
@zackarychapple I am not certain you understand my issue completely. We do not have issues with regards to running our apps via node. The issue is related to moving the apps into production.
If you have examples of your solution, I would be very interested in having a look.
Typed text can come across differently than other forms of communication; please don't confuse my attempts at clarity as being strong or insulting.
i recommend you to give survivejs webpack book a read.
Webpack is really awesome if learn properly, I'm still learning it but yeah if you want to make something good for your specific use scenario then you must master webpack and make your own deployment strategy
The CLI has a somewhat specific development lifecycle that I understand isn't really suitable for all setups.
Apps created with it are meant to have the ng commands control serving (while developing) and building. After building, the dist/ folder contains a bundled app that should be deployed as a static site.
I realize that your projects' needs are different, and Angular CLI is perhaps not well suited for it:
You seem to want to mix in a CLI generated project as part of your existing MEAN stack setup. I'd recommend configuring your setup directly to use Angular 2 instead of attempting such a deep customization of a CLI managed project, as the CLI is just not that costumizable.
This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.
Read more about our automatic conversation locking policy.
_This action has been performed automatically by a bot._