Closed ForbesLindesay closed 8 years ago
@ForbesLindesay to accomplish a similar thing I've been creating two builds of my modules and then deciding which to include in an entry point, so my folder structure looks like this:
lib
lib-checked
src
index.js
and index.js
looks like:
if (process.env.NODE_ENV === 'production') {
module.exports = require('./lib');
}
else {
module.exports = require('./lib-checked');
}
The issue with your suggestion is that most people don't process node_modules
with babel and so DCE won't happen. The VM can't do it because process.env.NODE_ENV
can change at any time, so the overhead would still be there.
In this example though, for client side, you're shipping users (who don't use babel/envify/similar) two complete copies of the code, which is surely worse?
I suppose more people use tools like envify/babel on their client side dependencies than for server side node_modules though, so maybe this is the right option.
I suppose more people use tools like envify/babel on their client side dependencies than for server side node_modules though
Exactly, people deploying to the client are much more likely to be using tools which can do this.
I would like to add a "Release" mode, intended for people to use when releasing code flow to npm. I would like it to only add typechecks for arguments (not return types etc.). I would also like to wrap all typechecks in:
That way, most people would get the benefit of helpful type errors in development, but not have the overhead in production, since you can compile away the
process.env.NODE_ENV
then do dead-code elimination. Currently I have to publish two versions (dev
andprod
) of the same npm module to offer this flexibility.