Skip to content

Feature request: 99% smaller global install #1263

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
kylecordes opened this issue Jul 1, 2016 · 17 comments
Closed

Feature request: 99% smaller global install #1263

kylecordes opened this issue Jul 1, 2016 · 17 comments
Assignees
Labels
feature Issue that requests a new feature P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent

Comments

@kylecordes
Copy link

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
Copy link

acefed commented Jul 2, 2016

+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 filipesilva added feature Issue that requests a new feature P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent labels Jul 3, 2016
@filipesilva
Copy link
Contributor

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

@kylecordes
Copy link
Author

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
Copy link

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
Copy link

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
Copy link
Contributor

intellix commented Sep 29, 2016

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
Copy link
Contributor

mmrath commented Sep 29, 2016

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
Copy link
Author

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.)

@niklas-dahl
Copy link
Contributor

Hey,
as a proof of concept that this is totally doable I created https://github.com/niklas-dahl/global-angular-cli.
It's just a small tool that can run the ng new command and after that it just proxies every other command to the locally installed angular-cli (just like the real angular-cli).

It's 0.1% the size of the real angular-cli (with dependencies).

Having a second project/npm package just for the global version isn't very nice but AFAIK the is no way to tell npm that some dependencies are only required when installing locally, so I think having a seperate package is the only way to solve this issue.

@kylecordes
Copy link
Author

That is fantastic proof of concept. I see your todo list in your README, all of those seem doable with this design, alternatively some of them go away if it can "proxy" slightly earlier, running some of the code behind the real ng new command.

I wonder what other obstacles there are?

The existence of more than one package in NPM is a small price to pay for a 99.9% reduction in global install footprint. I'm also happy to have estimated too big, when I wrote this original issue I was thinking about a mere 99% reduction. :-)

@niklas-dahl
Copy link
Contributor

Actually didnt thought of this but proxying earlier is a great idea.
something like this:

  1. create the project folder
  2. locally install angular-cli
  3. proxy an ng init to the local angular-cli
  4. pretty much done.

If this approach works it automatically supports all the features currently missing.
This would be even smaller in size :D

@filipesilva
Copy link
Contributor

I should mention that we moved the ember-cli version we use to inside angular-cli, and are in the process of reducing the install size by removing unused functionality.

@filipesilva filipesilva added this to the RC1 milestone Nov 21, 2016
@mmrath
Copy link
Contributor

mmrath commented Nov 23, 2016

@filipesilva I think moving ember-cli to angular-cli still does not address this completely. Will the global angular-cli now install very few dependencies (99% smaller)? POC idea mentioned by @niklas-dahl looks great in that aspect.

@hansl
Copy link
Contributor

hansl commented Dec 21, 2016

We cut our install time greatly. The real fix will need some refactoring of the whole CLI architecture.

Tracking issue for install time: #3199. Closing this.

@b-mi
Copy link

b-mi commented Aug 12, 2018

This is quick:
ng new proj --skip-install
npm update

But to run app is there is need to install this:
npm install --save @angular-devkit/build-angular @angular/compiler-cli

And this install nearly same as npm install (slightly less) - 23749 files, 181 MB (full node_modules 205 MB).

Installing from local zip/7z is not good too, there are so many small (useless) files that creating of them take min. 2 minutes on HDD.

@b-mi
Copy link

b-mi commented Aug 12, 2018

... and why we need install so often? Every update of libraries need test which versions of libraries are functional, and try to find hidden way to get over strange error messages, mess in library cache after updates, and reach succesful compiling our projects.

@angular-automatic-lock-bot
Copy link

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 8, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
feature Issue that requests a new feature P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent
Projects
None yet
Development

No branches or pull requests

10 participants