Does Meteor's build process remove unneeded code/modules?

help
1

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';
2 Likes
2

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.

2 Likes
3

And automatically remove PropTypes.

4

I think all of the above is achievable with Webpack…

5

It looks like it does include the whole lodash codebase even though you want to import a single function.

6

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?

7

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!

1 Like
8

Was this lodash from an atmosphere package? Or from npm?

9

That was from npm and nothing else was loaded except for a barebones meteor app’s defaults.

10

yep, meteor build tool’s not pefect

11

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

12

Couldn’t you go into the lodash code, copy the relevant function and paste it into your own helper module?

13

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 :slight_smile:

14

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:

  1. Create a test app:
meteor create lodash-test
cd lodash-test
meteor npm install --save lodash
meteor npm install
  1. Replace the contents of client/main.js with:
import toUpper from 'lodash/toUpper';
console.log(toUpper('make me taller!'));
  1. Run the app with the --production option:
meteor --production

  1. Load the app in your browser, view source, then click on the bundled .js file link.

  2. Search for lodash; the first hit will show you that only the toUpper code is included.

5 Likes
15

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 :expressionless:

4 Likes