-
Notifications
You must be signed in to change notification settings - Fork 12k
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
Comments
+1 @kylecordes 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 :) |
This is something we are trying to address. The brunt of that size is |
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.) |
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 :) |
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. |
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? |
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. |
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.) |
Hey, 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. |
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. :-) |
Actually didnt thought of this but proxying earlier is a great idea.
If this approach works it automatically supports all the features currently missing. |
I should mention that we moved the |
@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. |
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. |
This is quick: But to run app is there is need to install this: 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. |
... 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. |
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
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.
The text was updated successfully, but these errors were encountered: