Modules: ES modules warnings removal timelines

Created on 12 Feb 2020  路  8Comments  路  Source: nodejs/modules

We're currently emitting the following warnings for ES module features:

  • conditional exports resolutions ({ require: ... } or { node: ... } but not { default: ... })
  • package self-resolution
  • experimental modules warning whenever using ES module imports
  • experimental loader warning when using --experimental-loader

All these warnings apply to both 12 and 13 currently, just behind the --experimental-modules flag on 12.

On our current timeline I believe we were planning to unflag the implementation in 12.x for April, which I assume would involve removing the first three warnings of the list at least?

Does that sound like a correct assumption? Should we possibly disable the warnings sooner on either branch?

Most helpful comment

I support complete removal of runtime warnings from 1 through 3, I feel that these are ready to be "documentation-only" experimental.

I think the --experimental-loader runtime warning is still appropriate. My preference is that this be removed when the flag is changed from --experimental-loader to --loader. Contrary to the first three bullet-points I think --experimental-loader is not yet feature complete and suspect it will face breaking changes (move to separate thread for example).

One thing maybe the experimental loader warning could be deferred to first-use? So if you enable an experimental loader but never actually load any ES module code it would be great to skip this warning. I'm thinking of situations where a module's npm test sets an experimental-loader globally via NODE_OPTIONS then runs many test processes with only a couple tests that actually load ES modules.

All 8 comments

I assume we should at least remove the warnings a few weeks before to reduce the amount of code churn just before unflagging?

Are warnings about --experimental-vm-modules (ExperimentalWarning: vm.SourceTextModule is an experimental feature. This feature could change at any time) part of the same timeline, or is that separate afterwards?

Just chiming in with some feedback from #31819 (per @MylesBorins's suggestion):

I've now seen two packages accept PRs (and then publish releases) to add conditional export maps without understanding that this introduces a warning for their users in Node v13. There is no mention of this in the docs, except for a general "Experimental" notice at the very top of the "ESM" docs page.

This is a recommendation to remove that warning in Node v13 now that the behavior is unflagged. It's a warning shown to the wrong person: the consumer has no control over how the package author writes their package.json.

If that's not acceptable, then at least I'd recommend adding a warning closer to the docs section on conditional exports, since that's the section that package authors are being linked to in PRs.

Thanks @FredKSchott for following this up and for the feedback. I've created a PR for removing the warnings in https://github.com/nodejs/node/pull/31845, and we are continuing to discuss this. It's a fine line to manage here between enabling experimentation while also ensuring we don't let experimental work stabilize too soon, but this will at least land by April at the latest we expect.

If we do continue to keep the warning, updating the docs certainly sounds sensible to me to avoid confusion.

Also a question for the PR above - should we include removing the experimental modules warnings entirely in that PR as well?

One benefit of removing the warnings for experimental modules would be getting more usage feedback on 13 before 12 LTS backport.

The above sounds like a driving reason to me to consider that.

I support complete removal of runtime warnings from 1 through 3, I feel that these are ready to be "documentation-only" experimental.

I think the --experimental-loader runtime warning is still appropriate. My preference is that this be removed when the flag is changed from --experimental-loader to --loader. Contrary to the first three bullet-points I think --experimental-loader is not yet feature complete and suspect it will face breaking changes (move to separate thread for example).

One thing maybe the experimental loader warning could be deferred to first-use? So if you enable an experimental loader but never actually load any ES module code it would be great to skip this warning. I'm thinking of situations where a module's npm test sets an experimental-loader globally via NODE_OPTIONS then runs many test processes with only a couple tests that actually load ES modules.

I think the --experimental-loader runtime warning is still appropriate. My preference is that this be removed when the flag is changed from --experimental-loader to --loader.

No objection, but we need a way to silence warnings from particular diagnostic groups then.

This was echoed by @addaleax in comment https://github.com/nodejs/node/pull/29935#issuecomment-541242051. Unfortunately, I don't know if we ever saw progress on this idea.

I believe the only one left is --loader, should we keep this issue open?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

SMotaal picture SMotaal  路  5Comments

guybedford picture guybedford  路  3Comments

WebReflection picture WebReflection  路  5Comments

mhdawson picture mhdawson  路  4Comments

arlac77 picture arlac77  路  3Comments