Pattern for separate dev/prod CJS files?

[markerikson]

We've been using TSDX for Redux Toolkit, which currently generates 3 CommonJS files: index.js, redux-toolkit.cjs.development.js, and redux-toolkit.cjs.production.js.

The index.js file looks like:

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

In package.json, we've got main: ./dist/index.js pointing to that file.

I'm playing around with Microbundle for the first time, and it looks like it isn't really set up to do that kind of pattern. So, questions:

• Is there a way to get Microbundle to output both dev and prod CJS builds like that?
• Is that "build both, import the right one at runtime" approach even something we would want?

Curious for any info folks can provide on how to set things up the right way here.

[artalar]

Hi, I'm interested in this topic too.
As I understand we may modify a babel config by babel.config.js at the root of a package (and add babel-plugin-dev-expression), but I did not found how to generate separate builds with different suffixes.

Also, I don't get why the runtime check tests the NODE_ENV for 'production' if the user builds an app without passed NODE_ENV we will exports the development build which is not correct imho. It should looks like NODE_ENV === 'dev' ? dev : prod

[developit]

This is not supported in Microbundle because it only works in CommonJS, and only when bundled with specific configuration or executed in Node. It also has a terrible default behavior of including both variants. Relying on magic Node globals in a browser context doesn't make sense.

There are many solutions that don't have these problems:

• create two sets of bundles for development and production, and use aliases to import them
• provide an API into which a foo-module/debug add-on can be injected (this has the nice benefit of forcing reasonable separation of development and production code)
• check whether the complexity of having two separate builds is actually worthwhile - in a lot of cases, the size difference is small.

[amannn]

create two sets of bundles for development and production, and use aliases to import them

Does this mean the consumer of the library has to create an alias? I'm currently looking for a way for popular bundlers to pick up the right build automatically while providing an ESM build but I can't seem to find one.

So far I've been using the CJS way that @markerikson has mentioned above.

[rschristian]

Does this mean the consumer of the library has to create an alias?

Yes, they would.