meteor-node-stubs package provides client “stub” implementations of Node.js built-in functions (e.g.
util, etc.) which are not implemented on the client. So while the Node.js
crypto on the browser, which is done with
crypto-browserify. In an isomorphic application, where client and server code is shared, you can probably understand how critical these stub packages might be — which is why we include the package in every new Meteor application. (Surely we wouldn’t include it just for fun, right? )
Now while the
meteor-node-stubs package is included in all new Meteor applications, the individual stub implementations (e.g.
crypto, etc., as itemized in the
package.json from the actual source for
meteor-node-stubs, here) are only included in the generated client bundle if their usage is detected by Meteor’s import scanner. If you don’t provide the
meteor-node-stubs package, then it’s possible that your client code could fail at run-time due to the absence of the necessary stub package which mimics the server implementation.
If you are finding (e.g. via the bundle visualizer) that your client bundle is including stub packages which you don’t expect to be included, you’ll want to analyze your module entry points carefully. Meteor will include a stub implementation if it finds Node.js module usage while bundling your application. It may be that your own application code is doing a
require('crypto'), or it may be one of your Node module dependencies! Either way, it’s worth investigating, as you may find that you’re unnecessarily including a large amount of unneeded code by not being careful about what you import!
So while @robertlowe’s recommendation number “two” and “three” are very reasonable, I would use caution before just removing
meteor-node-stubs and urge you to understand the implications. If Meteor thinks it’s needed, you should probably gain understanding of why that is. Only then will you be able to confirm that those packages aren’t needed.