Possibility about conditional export ES6 module based on process.env.NODE_ENV?

I wrote a utility library and I want to tree-shaking them when my user publishes their app.

In Webpack v4, you need to make your module ES6 to support tree-shaking, but I also want to split my development build and my production build into different files.

What I want is exactly like react's NPM module:

// index.js
'use strict';

if (process.env.NODE_ENV === 'production') {
  module.exports = require('./cjs/react.production.min.js');
} else {
  module.exports = require('./cjs/react.development.js');
}

This leads me questions.

If I make my utility modules all commonjs, I will never get tree-shaking, my app gets so huge.

If I make my utility modules all ES6 static export, I will have to include development message in production code.

And publishing two modules (eg: my-utility and my-utility-es) will not helping, because in development, my code looks like this:

import { someFunc } from 'my-utility';

but in production code, I will have to change it to this:

import { someFunc } from 'my-utility-es';

How can I solve this problem?

Update

To be more clear, my development build and production build contains different source code (eg: production build has stripped all error message).

So specify webpack mode isn't satisfying for me.

I've found out the answer by myself, I think the best way to do this is through babel macros:

import { something } from 'myLibrary/macro';

// In webpack development:
// ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓
// import { something } from 'myLibrary/development';

// In webpack production:
// ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓
// import { something } from 'myLibrary/production';

My macro implementation:

import { createMacro } from 'babel-plugin-macros';

function macro({ references, state, babel }) {
  state.file.path.node.body.forEach(node => {
    if (node.type === 'ImportDeclaration') {
      if (node.source.value.includes('myLibrary/macro')) {
        if (process.env.NODE_ENV === 'production') {
          node.source.value = 'myLibrary/module/production';
        } else {
          node.source.value = 'myLibrary/module/development';
        }
      }
    }
  });

  return { keepImports: true };
}

export default createMacro(macro);

Conditional exports naming usability discussion � Issue #452 , Possibility about conditional export ES6 module based on process.env. NODE_ENV? I wrote a utility library and I want to tree-shaking them� It wouldn't have to be checking the actual current value of the "real" process.env.NODE_ENV variable while generating the Webpack config, because I would know that any time I'm doing a "production" build, I would want to set that value in the client code to "production'.

Cannot conditionally require modules based on process.env , module: conditional exports condition renaming proposal for usability Removing "default" will break the current implementation in node 13 for sense as I read it as “this is the browser-environment file for this path. Originally, based on discussions with various Node folks, my At least it had a chance. Teams. Q&A for Work. Stack Overflow for Teams is a private, secure spot for you and your coworkers to find and share information.

All you need to solve this problem is to use mode. See Specify the Mode.

Since webpack v4, specifying mode automatically configures DefinePlugin for you:

webpack.prod.js

  const merge = require('webpack-merge');
  const common = require('./webpack.common.js');

  module.exports = merge(common, {
    mode: 'production',
  });

They mention React by name:

If you're using a library like react, you should actually see a significant drop in bundle size after adding this plugin.

rollup.js, Expected Behavior With the following code: if (process.env. Cannot conditionally require modules based on process.env. With ES6 import I don't think I can do a conditional import as the import statement NODE_ENV . Thanks for the question. Here's my package.json. I think everything is the latest available. You will see that I am confused about dependencies and devDependencies.Given that I'm building a bundle, shouldn't everything be a devDependency?

Webpack, React & WordPress: A Modern Development Stack , rollup.config.js import fetch from 'node-fetch'; export default Note: While in watch mode, the ROLLUP_WATCH environment variable will main.js and chunk-[hash].js , where [hash] is a content based hash string. Babel will convert our modules to CommonJS before Rollup gets a chance to do its thing, causing it to fail. For example, when process.env.NODE_ENV is not set to 'production' some libraries may add additional logging and testing to make debugging easier. However, with process.env.NODE_ENV set to 'production' they might drop or add significant portions of code to optimize how things run for your actual users.

webpack-scss-sass-file does not work with conditional css extract, For us, extending WordPress was based on the common approach of a plugin ease of building a singular React-based app on a Node-hosted platform or the like. High possibility of duplicated dependencies in the bundles; Difficulty sharing "cross-env NODE_ENV=themedev npx webpack --progress --hide- modules",. @guybedford My concern with folders with separate modules is that you would need conditional logic in each of the modules. It would be more ideal if I could make all of the decisions in one module, and then use that information to load only the right modules. Or alternatively I would include Modernizr and then I could also do:

sass-loader - Webpack, I think the key here is to use the new ES6 module syntax as described in the Rollup documentation. This will also give Rollup the possibility to apply features like chunking and export { test }; The files module2.js and module3.js are the same like module1. The Rollup config looks like this: const production = ! process.env. Given the options: (a) detect based on module-only syntax (b) detect based on explicit list in package.json (c) detect based on a node-specific "use module"; directive: (a) Seems to be the least frictionful with easily explainable edge cases. People will get it wrong on the first try and then will learn.

Comments
  • You cannot get tree-shaking using es5/commonJS module.exports syntax. But as shared below, you can use webpack --mode to remove the "development" portions of the code.
  • Sorry, but this doesn't answer my question, I've updated my question.