Npm packages in the production bundle

[JWo1F]

I have some problems with npm packages in my bundles.

1. I create a new meteor project, add a npm package (lodash for example) and use it in the client-only-side (client/ folder for example). Then I run meteor build. Wait (soooo many time). Open final archive and see /bundle/programs/server/npm/node_modules/. Among other things I see lodash folder. In the server area (!). What for?
2. I create a new meteor project, add a native (atmosphere) package (reywood:publish-composite for example). Then I run meteor build. Wait. Open final archive and see /bundle/programs/server/npm/node_modules/meteor/reywood_publish-composite/node_modules/. I see eslint folders. What for? Ok. Go to publish-composite github repository. Open the package.json. All eslint packages in devDependencies area. Why they in the production bundle?

All of this points make my bundles sooo big. And it's very bad, I think.

Examples at my github repo: https://github.com/JWo1F/meteor-npm-bugs

Meteor version: 1.6.1.
Operating System: Fedora 21.

[KoenLav]

We have recently witnessed similar results with the materialize:materialize and grounddb packages.

Somehow node_modules folders (mostly consisting of phantomjs) get added to the bundle.

Our solution was to either upgrade the packages to their Npm counterparts or fork them and make some modifications to the package.json files included in the subdirectories (which were, apparently, not needed).

[hwillson]

Regarding #1: When you npm install a package, npm expects that package to be installed in a server side node_modules directory. Instead of altering npm's expected behaviour, Meteor is following npm's lead here. It's important to note that if you've installed an npm package (that can be used on the client side) and aren't referencing it on the client side, it won't be included in the client side JS bundle (which is a much more important use case, since client side bundle size is more impactful than server side bundle size). If you would like to see this behave differently, please start a new discussion over in the http://github.com/meteor/meteor-feature-requests repo.

Regarding #2: Sounds like a bug. As of Meteor 1.4.2, devDependencies are stripped from the bundled app (unless running in test mode). It looks like this scenario (a third party Atmosphere package with npm based devDependencies) wasn't caught.

[cpury]

@hwillson

It's important to note that if you've installed an npm package (that can be used on the client side) and aren't referencing it on the client side, it won't be included in the client side JS bundle

Can you define what it means for a package to be "referenced" on the client?

E.g. I require a package inside methods, wrapped with a if (Meteor.isServer), and that seems to count as a client-side reference as well (it gets included in the client-side bundle).

[smeijer]

Same problem here. I've decided to remove some stuff from the final build, to reduce my Docker image with 125MB!

RUN find /app -type d \( \
    -name "*-garbage-*" -o \
    -name ".temp-*" -o \
    -name "docs" -o \
    -name "examples" -o \
    -name "samples" -o \
    -name "phantomjs-prebuilt" \
    \) -exec rm -rf {} +

The phantomjs-prebuild was included by Apollo. That one alone took 68MB!

In addition to the folders above, I also remove some additional files:

RUN find /app -type f \( \
    -name "*.md" -o \
    -name "*.markdown" -o \
    -name "*.ts" -o \
    -name "*.exe" \
    \) -delete

And a final step is to remove npm and yarn from my production container, to save another 23MB.

I expected that it would also be safe to remove node_modules/*.js.map, as that also is a noticeable difference. But removing those will make the app crash on the ecmascript package.

At this moment, I've slimmed down my container from 521MB to 339MB by removing a couple of packages that were defined in package.json, but never imported in any code (these are now removed in the code-base, not pre-build). And by cleaning the node_modules with the commands above (post-build).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[afrokick]

At least, we can apply @smeijer script automatically after finishing build. Any idea how to integrate it?