• ✅login: jkrems / (4c7e3e8)

For maintainers only:

• This needs to be documented (issue in webpack/webpack.js.org will be filed when merged)
• This needs to be backported to webpack 4 (issue will be created when merged)

/cc @hardfist @fi3ework @ahabhgk @h-a-n-a What do you think?

IMO this is not necessary to add into the core, user can add new DefinePlugin({ "import.meta.DEBUG": JSON.stringify(true) }) to achieve this.

IMO this is not necessary to add into the core, user can add new DefinePlugin({ "import.meta.DEBUG": JSON.stringify(true) }) to achieve this.

The target audience for this feature is library authors. Which means that adding a DefinePlugin to the users config isn't something they can do.

I'd be surprised if a library author wouldn't just use (or keep using) process.env.NODE_ENV if the alternative requires each user of the library to set custom bundler configs.

@ahabhgk I agree, library developers should be able to define the mode without additional guides on how to configure the bundle

I agree with this point. But libraries already has various similar variables, such as process.env.NODE_ENV and import.meta.env, adding a new variable will further fragment the ecosystem if most libraries have not adapted, or runtimes/bundlers have not supported it.

@ahabhgk Does rspack support - import.meta.env.MODE/import.meta.env.PROD/import.meta.env.DEV?

No, rspack keep the same with webpack (supports optimization.nodeEnv and user can define other variables by DefinePlugin), and rspack-cli will set optimization.nodeEnv by build or serve command, just like webpack-cli does, and rsbuild (the better and opinionated version rspack-cli) supports both process.env.NODE_ENV and import.meta.env.MODE/import.meta.env.PROD/import.meta.env.DEV.

On topic: I agree that universal support for import.meta.env.DEV would be an alternative. It would be a sad outcome to me because it comes with some of the same issues that NODE_ENV had but I understand the "it's here, might as well join the momentum" argument. Universal support would trump most other concerns, realistically.

To recap from the explainer, the two big issues with .env.DEV are:

• It comes with .PROD and .MODE which makes it easy to "misuse": If somebody refactors !DEV into PROD, suddenly the library will ship debug code to production by default. This has been a recurring issue with NODE_ENV where people accidentally ran dev-only code in production.
• import.meta.env.DEV breaks in vanilla JS, so a library using it won't run in a browser or any other broader JS environment as-is. You can use defensive code like import.meta.env?.DEV but for libraries with a build step, that can create additional indirection which could make things more fragile for optimization. And also: You'd have to remember adding that ? consistently. The same was true for process.env because "process" isn't a universal global in JS.

Neither of those are necessarily "fatal flaws" but it's a bit sad if the recommended replacement for NODE_ENV repeats two of NODE_ENV's biggest gotchas. If that ship truly has sailed (see rsbuild support), I could update the PR to add .env.DEV instead.

@jkrems I'm afraid that for this to be standard we need to mention here all the developers of bundlers and maybe even TC39, I would not like to create problems for future library developers by adopting some rules that will be revised.

@jkrems I'm afraid that for this to be standard we need to mention here all the developers of bundlers and maybe even TC39, I would not like to create problems for future library developers by adopting some rules that will be revised.

Definitely! This isn't worth landing unless all bundlers agree to support it. Since it's based on the "development" condition and that condition is only a cross-bundler convention, I'm not sure if there's a better "standards venue" than cross-bundler agreement to do it.

P.S.: FWIW, I'd love it if there was a central place where cross-bundler APIs were documented/specified - or even a "test262 but for bundlers" at some point.

@jkrems maybe we can start it here - https://github.com/tc39/ecma262 or https://github.com/tc39/proposals and ask where we can start discussion

(For context, I'm an - admittedly not very active - TC39 delegate.)

I'll ask in the TC39 chat if there's appetite to pursue this at that level but in the past my feeling was that import.meta was explicitly "hands off" (similar to module resolution in general) from an ECMAScript perspective.

@jkrems I understand that on the other hand it could allow standardizing the behavior of libraries in different environments, not just for bundles, which could have its advantages.

FYI, there's now a dedicated channel for JS tool maintainers/contributors: https://matrix.to/#/#tc39-tools-:matrix.org

P.S.: Matrix because that's where other TC39 chats are happening. If you think another place would be more appropriate, happy to move discussions there as well. :)