Reduce installed package size #369
Comments
sindresorhus
added
enhancement
|
@sindresorhus: That appears to be a bug on your machine. On mine it works fine: So I'm really not sure why you're seeing that. Maybe file a bug report with npm? |
|
Actually, it is only $ npm install --productionIf you create a new project and just do this: $ npm init
# default for every prompt
$ npm i babel-core babel-preset-es2015 babel-preset-stage-2I get a relatively svelte Adding Adding
|
|
@jamestalmage: that's strange, I did go above and beyond my usual intelligence level and create a new project to install AVA, but I'll try again when I'm home. |
|
What are we hoping to achieve here? With changing dependencies this is a never ending struggle. That said, looks like all Babel dependencies require Presumably we could downgrade to Of course there's other dependencies doing weird stuff, like To measure I did a fresh install from NPM (in an empty directory) and ran |
|
@novemberborn There are some things that can be done even if the worst offender, Babel and fsevents, are out of our control. Many packages include junk like tests or examples directory, etc. I did a PR marathon a few years ago for Yeoman on 100+ different packages adding a "files" property to their package.json to reduce the total disk size of the dependency tree. That helped a lot. Pretty much have this still open for when I have time to do the same here. |
Sure, fair enough. Somebody should write a tool for that 😜 Also thinking about it more I'm doubtful we can change our |
Actually if we have a dependency which merely reexports |
I thought about that. Actually, I think it would be better if Babel did that (all the Babel 6 plugins should depend on a differently named module that exports |
👍 |
|
Is detecting Node v6 possible or an option? Would we still want babel to be part of ava when the environment is ES2015-compliant? |
|
@jokeyrhyme AVA still injects features that have not yet landed in ES2015 or ES2016, such as I don't know if it's possible to correctly detect the Node version, but that'd be at runtime, not at install time. The team could remove the ES2015 preset when all supported Node versions support it, but that could take a while. |
|
@jfmengels we might be able to install babel in a pre/post-install npm hook, and only install exactly the transforms needed to get us from the current version of node to stage-2 or whatever our threshold is. That would mean fewer dependencies for newer Nodes? |
|
@jokeyrhyme That's unfortunately not an option for so many reasons. Some of the best features of AVA require Babel, so I don't see why anyone would want to drop it for some minor space savings. The biggest Babel size issue is about to get fixed anyways babel/babel#3438. If you want to help out with this, I'd suggest you find packages in the dependency tree that includes junk like test/examples/etc folders and ask them (or better yet do a PR) to use the |
|
Here's a list of packages we depend on that doesn't have a files entry or .npmignore. Please help us reduce the size of AVA by submitting PRs to those packages adding a Tip:
The list was generated with: |
|
It may also be worth thinking about install time as well as size. See #841 -- on my machine, AVA's install took ~50.1s. I wonder how much of that is I/O (in which case it will be fixed by addressing the size issue) vs. dependency resolution (in which case the deep nesting itself is also a cause) vs. network traffic (a bit of both, since package requests are made individually). Another option is to pull out some of the larger deps that only cater to certain use cases into optional plugins, although I suspect the core team would prefer to avoid additional config. |
|
The real issue here is that I don't see us dropping lots of dependencies. The only dependencies that would be easy to replace, are also ones that are not really going to cut down on download times. Also, I really don't think comparing cleared cache download times is that valuable. I'm much more concerned with download times when we have mostly cache hits. (AVA is still pretty bad by that metric as well, but it's not as extreme). |
|
Hello. I have been checking the list of packages, and found out that many of them already have a closed PR, specially from feross and substack authors. I submit an updated list here with some packages edited in bold, the ones with a new PR and the ones that have an The reason and previous discussions on why the PRs were not accepted can be found in feross/is-buffer#12 PACKAGE LIST
|
|
https://github.com/siddharthkp/cost-of-modules is also a nice tool: |
|
With npm 5.3, in a temp directory: The final size matches what Finder reports. I think that's pretty good! Plus, installation times are a lot better with npm 5. Whilst we can always improve this, I don't think there's much use in keeping this issue open. |
Latest master (b79fdfd), when installed with npm@3.5.2, is 68 MB. Most of that is Babel stuff.
We should look into ways we can reduce the size.
(Output from DaisyDisk)
Turns out every single Babel package includes a dependency on
babel-runtimeand for some reason it's not deduped by npm@3, not even withnpm dedupe:The text was updated successfully, but these errors were encountered: