If I do the following:
import _ from 'lodash';
but I only use _.find
, for example, does Meteor still include the entire lodash codebase? Or should I stick with importing only what I need:
import _find from 'lodash/find';
If I do the following:
import _ from 'lodash';
but I only use _.find
, for example, does Meteor still include the entire lodash codebase? Or should I stick with importing only what I need:
import _find from 'lodash/find';
Hey Sam
I donât know, and Iâve wondered the same.
The Dart language from Google offers a âshaking treeâ compilerâŚ
I think Elm does as well?
And somewhat related, Iâd love to see comments stripped from generated js.
So comments can be liberally used in code, but be completely missing when app is deployed.
That would be nice.
And automatically remove PropTypes.
I think all of the above is achievable with WebpackâŚ
It looks like it does include the whole lodash codebase even though you want to import a single function.
I donât know if combining webpack with Meteor makes sense. Theyâre two separate build systems.
Youâre saying import _find from 'lodash/find'
will include the entire lodash codebase? Yikes. How did you verify that?
I was confused by that once and created a barebones meteor app, added lodash, imported a single method from the library, built the bundle, searched through the final js file for instances of lodash methods (making sure I was not confusing them for already bundled underscore methods) and there I found both libraries in their full glory!
Was this lodash from an atmosphere package? Or from npm?
That was from npm and nothing else was loaded except for a barebones meteor appâs defaults.
yep, meteor build toolâs not pefect
thereâs even a package for it, but itâs kinda outdated
Iâve worked on it a little bit, but kinda moved away from meteor for now
Couldnât you go into the lodash code, copy the relevant function and paste it into your own helper module?
Yikes! How about catching up with upstream releases? Or transitive dependencies? That just doesnât scale.
Google Closure Compiler does dead code elimination and it works pretty good for ClojureScript.
Is there a post-processing step where one could hook and call GCC on the bundle?
If not, it could still be integrated in the deploy process. Would be nice to try
If youâre importing a specific lodash function instead of the complete library, the build tool will make sure only that specific function is included in your final bundle.
As a quick example:
meteor create lodash-test
cd lodash-test
meteor npm install --save lodash
meteor npm install
client/main.js
with:import toUpper from 'lodash/toUpper';
console.log(toUpper('make me taller!'));
--production
option:meteor --production
Load the app in your browser, view source, then click on the bundled .js file link.
Search for lodash
; the first hit will show you that only the toUpper
code is included.
Ah this has been what Iâve lacked
import toUpper from 'lodash/toUpper';
Because this was what I tries
import { toUpper } from 'lodash'
In my defense, I was not aware (too lazy to check) that lodash also provides individual files exporting individual methods.
I got too caught up in the lack of tree shaking or similar strategies within the bundle that I overlooked library authorsâ simple and elegant out of box solution