Uh oh!
There was an error while loading. Please reload this page.
[v12.x] Backport unflag --experimental-modules - #33055
Conversation
targos
commented
Apr 25, 2020
This is to prepare the next v12.x minor, which is scheduled for 2020-05-26 |
ljharb
left a comment
There was a problem hiding this comment.
Does this include removal of the warning, and any other ESM bugfixes that were part of v13/v14?
| if (!this.exportKeys) { | ||
| // When using --expose-internals, we do not want to reflect the named | ||
| // exports from core modules as this can trigger unnecessary getters. | ||
| const internal = this.id.startsWith('internal/'); |
There was a problem hiding this comment.
| constinternal=this.id.startsWith('internal/'); | |
| constinternal=StringPrototypeStartsWith(this.id,'internal/'); |
i realize this is a backport PR, so maybe it should land in master with this change first, but it seems important to avoid brittleness in LTS specifically.
targos
commented
Apr 25, 2020
This doesn't include the removal of the warning. |
ljharb
commented
Apr 25, 2020
Do we want it unflagged on LTS, without the warning? We removed the warning in v13 because it was inhibiting adoption; i think it would have that effect much more on an LTS version. |
targos
commented
Apr 25, 2020
I did not include the removal of the warning in this PR but I intend to cherry pick it as well later |
MylesBorins
commented
Apr 26, 2020
Please open removing the warning as a separate PR. I'm not sure that we should remove the warning on LTS prior to 14.x moving to LTS |
nodejs-github-bot
commented
Apr 26, 2020
ljharb
commented
Apr 26, 2020
@MylesBorins let's discuss in the next modules meeting; i'm not sure we should remove the flag without removing the warning. |
MylesBorins
commented
Apr 26, 2020
via email
Totally reasonable to bring it up in the meeting. I do want to mention that
we've had consensus to remove the flag for months and have been telling
people we plan to do so. We have not had consensus around removing the
warning. …On Sun, Apr 26, 2020, 3:44 AM Jordan Harband ***@***.***> wrote:
@MylesBorins <https://github.com/MylesBorins> let's discuss in the next
modules meeting; i'm not sure we should remove the flag without removing
the warning.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#33055 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADZYV6MHG46RX6KYHABVPDROPQ4DANCNFSM4MQXFYKA>
.
|
richardlau
commented
Apr 26, 2020
A question I have is does removing the flag potentially cause an observable change in behaviour if, say, packages had defined fields such as described/warned about in #33074? Or do package.json files with esm fields already get loaded as esm on 12.x without the experimental flag (I was under the impression they weren’t)? |
ljharb
commented
Apr 26, 2020
i believe any package that has opted in to use conditional exports, for example, will suddenly start to generate a warning in 12 if this lands without removing the warning - to my recollection, that experience is a big part of why we removed the warning in 13. |
richardlau
commented
Apr 26, 2020
My question was more around for anyone who is not currently opting in to esm but may be using dependencies that might start behaving differently once the flag is removed. |
SimenB
commented
May 4, 2020
Landing this will also close #33202 I guess 🙂 |
PR-URL: nodejs#29866 Reviewed-By: Michaël Zasso <targos@protonmail.com> Reviewed-By: Myles Borins <myles.borins@gmail.com>
PR-URL: nodejs#30720 Reviewed-By: Guy Bedford <guybedford@gmail.com>
targos
commented
May 7, 2020
Landed on v12.x-staging |
/cc @nodejs/modules-active-members @nodejs/lts