-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Package download size #1283
Comments
The main reason we decided to go this route was under the assumption that lodash would already be included in users node_modules/caches. The actual size of asyncjs distribution file size (what is loaded when you do
we already do this, the main file points to a dist/ file that is finely tuned to reduce size (you noticed we use lodash internals, we do so to reduce size of the distribution size) Also see #914 |
Just to provide a data point here, between async@1.5.x and async@2.x, for most folks, it's a difference of ~0.8 seconds as far as install time. Now granted, that differential is 800% of the entire install size back in async@1.5.x, so it feels like a lot :p But it's really not that bad-- and like @megawac mentioned, in some cases, the lodash deps will be cached already (although I've noticed that, depending on your NPM version, it still gets very chatty about them regardless.) Before updating Waterline's async dep:
After updating to async@2:
@TehShrike if initial download/install time is a big factor for your use case, you could consider doing something like what we did for Lodash 3.10.x. Granted, we only made that repo for an unrelated reason, but it does have the nice side effect of shrinking the download size back to what it was before, if not smaller. But be warned! You'll have to keep yours up to date in order to pick up changes from |
I've been thinking about this a bit more. The reason we include Lodash is so you can What if we used Rollup to flatten each of our individual methods down to single files? Lodash would become a devDependency, and requiring a single method in turn wouldn't require a dozen or more other files. There would be some code duplication, and Async itself would get larger, but it will probably be smaller than Async + Lodash. For people using only a few Async methods, their code would get smaller and faster, due to less CJS overhead. It also might fix that bug where certain Lodash internals are missing for some people in some cases. #1352 What do you think? |
@megawac any thoughts on the above? |
That's definitely an option, though I think it kind of defeats the purpose of modularizing these files. Perhaps slightly better would be to copy only the lodash files we need into the repo and map the imports of I think it might be a better option to start using the lodash npm modules, at least for the now distributable code. Switching to the npm modules would remove our dependence on lodash internal implementations, however it would likely also increase our distributable sizes as we'd start importing things like deep string support (perhaps webpack might help?).
This is barely a consideration from my testing as most file system imports are a one time operation on the order of milliseconds and |
FWIW, I'm getting more bearish on our use of Lodash, especially since we're already relying on Lodash internals to cut down on bundle size. Our most commonly used Lodash method is |
Done! |
The inclusion of lodash made the download size for async jump dramatically: http://pkgsize.com/async.html
This had the side effect of causing other highly-used packages to have their download sizes doubled or more:
In a world where people are already sensitive to module download size, an extra 5MIb seems undesirable.
I started to look at what was being used to change the dependencies over to the individual lodash packages published to npm in an attempt to decrease the download size, but async seems to depend on "private" lodash files that aren't published in their own modules.
I'm not sure what the best solution is here.
You could use rollup or some other tree-shaking bundler to inline lodash and eliminate the unused code, but that results in a higher bundle size for anyone using lodash in the browser.
lodash internal functions seem tightly integrated into this library, so I can only imagine how much work refactoring them out would be.
The text was updated successfully, but these errors were encountered: