Feature request: 99% smaller global install

[kylecordes]

Over the last few weeks we at https://angularbootcamp.com/ have assisted dozens of developers with getting up and running on the CLI (and of course Angular 2 itself). The results have been good, but the process of getting up and running has been unnecessarily rough. We have been thinking about what aspects make it so.

The most obvious reason is that the CLI is still under heavy development. That's great, we are not complaining about that at all. Good luck, keep going, please ask for help if needed.

But here is a feature / architecture improvement that would help quite a lot:

Currently the initial set up command "npm install -g angular-cli" brings in an astonishing several hundred megabytes of global node dependencies. Global node dependencies are the worst kind of node dependencies; they are the kind most likely to have issues interacting with other (globally) installed packages. Struggling with these dependencies leads to the need for unpleasant things, such as the current CLI upgrade instructions (as of June 2016) which direct the user to discard their entire NPM cache (!).

The solution for this is relatively well understood among the node development community, and would (IMHO) be a great improvement for the Angular CLI project:

Make the thing that we ask people to install globally, much much smaller. Chop away ruthlessly at its dependencies. Throw away every dependency not absolutely necessary for the "ng new" command. From a cursory look at the functionality necessary outside the context of a project, it appears that the global CLI package could easily be made less than a megabyte, with a handful of small utility dependencies. It could be made in such a way that it almost never needs to be upgraded.

Instead, the global package and global command only needs to understand enough to begin the "ng new ____" process. Having started a project, it can perform an NPM install of a different package, one which contains the hundreds of megabytes of machinery needed, all of the stuff needed to make the rest of the CLI work.

The global "ng" could then redirect commands (I think it actually already does this) to the locally installed ng. That means the global ng doesn't need to even know a list of all those other commands other than "new", it doesn't need to know about their help, it doesn't need to change when they change, etc.

I think the current behavior, of epic global node module bloat, is simply inherited from the (generally excellent) Ember CLI. I don't know if the Angular CLI team considers it "in scope" to solve things that come from that direction, but if so, I think this would be a great one to consider.

[acefed]

+1 @kylecordes
I couldn't agree more. Several hundreds of MBs to type 'Hello world' in a browser, many many packages installed globally, which I won't use, ever. Introducing dependency problems in other, unrelated projects. This steers me clear of angular-cli at the moment.

Don't get me wrong, the idea behind angular-cli is great, and I'm thankful for all the excellent work put in. That's why I care, hope this will be fixed, and keep an eye out how this will be handled in future versions of angular-cli. Keep up the good work :)

[filipesilva]

This is something we are trying to address. The brunt of that size is ember-cli related dependencies, which aren't optional.

[kylecordes]

Right - but even sticking with most of the ember-cli implementation under the hood, it would be possible to banish ember-cli from a (new, much smaller) global angular-cli package, and implement the global ng command (which mostly delegates) the locally install ember-cli stuff.

(Related this... it seems likely that angular CLI will eventually need to depend on a fork of ember-cli, rather than the upstream package directly, in order to control our own destiny here and make something ideally suited for Angular use cases. This would make it possible to disable any especially problematic parts of ember-CLI, such as if ember-cli itself complains about not being globally installed.)

[elvirdolic]

Currently a complete npm install and ng build --prod takes 10min without running tests. As we run our builds on VSTS hosted build agent we are not able to use the cached files as the agent is always clean and we won't to commit node_modules. A lot of time for a 1mb artifact :)

[BobbyTable]

Attesting to what @elvirdolic says above, we also run "ng build" on a clean hosted VSTS agent, and this angular project is a "freak" with 250 megs and over 40 000 files worth of dependendencies, to create our 180kb artifact. Loving the tool in every other aspesct, great work.

[intellix]

I think a problem with node/npm dependencies in general. You're creating a 200kb artefact and have to install hundreds of megs of things. We should at least look at which dependencies are the worst offenders and look at alternatives (if any). I imagine tools like Phantom are a big offender, but how would you substitute that?

[mmrath]

Yes this is a general issue with npm packages. But for a similar build with plain webpack2 and karma sass etc, I have around 20k files. With cli it is more than double. I don't have problem in local dev but it is a pain to have it on the CI. I think the biggest burden is ember-cli. This is already a top issue. I am hoping the smart guys of angular-cli team will resolve this soon.

[kylecordes]

I had opened this issue about global install size, and I think that specifically is a more easily solvable problem, versus the general issue of Node transitive dependencies growing surprisingly large. Sticking with the global install size issue, I noticed a while back that over in the React community (our "cousins"?) the "create react app" CLI tool:

https://github.com/facebookincubator/create-react-app

...operates similarly to how I described. There might be some tips that can be picked up from its implementation and used to achieve the same benefit here.

(About the general issue of sprawling node transitive dependencies, it seems that probably warrants a separate issue here so that it can be separately prioritized etc. by the team.)