Upstream changes to ESM in nodejs/node

[MylesBorins]

During today's meeting there was discussion about what should we do with upstream changes to core. Some suggestions were

• nothing, allow changes to happen as they have been
• feature freeze. Allow bug fixes and infrastructure changes but do not land new features
• stop all changes against the esm implementation
• remove esm from core and start from scratch

It is worth noting that this team does not currently have any ability to demand that any of the above be implemented, but we do have enough representation from collaborators within this group that we can definitely make it work in practice if we have consesnsus

None of these solutions are ideal, but we do need to figure out a compromise.

One thing I think will be important if we do any sort of freeze on development, or removal of code, is that we set clear deadlines and expected deliverables for when that freeze is over, or when code is brought back.

[MylesBorins]

/cc @nodejs/tsc who will likely want to follow this conversation

[mhdawson]

Not to say this is the right solution, but early development for N-API was done in a repo under the Node.js org which was a clone of master. This did result in a big PR that was hard for people to review but otherwise worked fairly well until we believed it as stable enough to pull into master.

[devsnek]

imo the best course is to allow changes that work with whatever our current direction is. that way we can stick to maintaining the direction and the people in core can stick to making code. if we change direction then all we have to do is change some code (i'm willing to do this, i hope other people are too). as long as we keep modules experimental while we figure this all out its pretty fine.

[weswigham]

TBQH, I don't think anyone's wholly against people continuing to write code (beyond philosophical issues to do with writing code without full direction), so long as "The code already exists" isn't used as a reason to silence or force discussions and designs within the group (they may be counter to any existing implementation), or to block future work that may eliminate current implementations. But I shouldn't presume to speak for others.

[benjamingr]

I'm strictly +1 on allowing changes in nodejs/node and improvements on the existing loader - it's under a flag and marked experimental anyway and we can discuss design while it's worked on anyway.

[mcollina]

Not to say this is the right solution, but early development for N-API was done in a repo under the Node.js org which was a clone of master. This did result in a big PR that was hard for people to review but otherwise worked fairly well until we believed it as stable enough to pull into master.

It worked well for http2 too. That being said, we have shipped some esm support under a flag. I think we should not discard that option for specific topics, i.e. named exports, interop and other things were a single PR would create a lot of traffic to nodejs/node. For less contentious topics, doing a PR against nodejs/node will be fine.

I'm 👎 to freezing, removing and "starting over". I think we should leverage the current releases to gather feedback from users. As long as the code stays within the experimental boundaries, we can also test different ideas and gather feedbacks.

[bmeck]

I have voiced my opinions repeatedly and would prefer not to halt PRs. In particular, I wish not to halt progress on bug fixes or missing features that are non-controversial by nature such as import() support which is mandated by spec, or import.meta.url which was non-controversial to land.

If we halt progress, I strongly would desire to remove all ESM code from core and move it to a fork that can continue to progress. I would like to create a level playing field for all implementations again at that point since that is what a moratorium on PRs would signal to me. It seems that there is disagreement on how to progress so I am unsure if that fork would continue to be in the nodejs organization but due to perceptions of bias. I would also probably encourage us not to keep it under the nodejs organization if we take that route.

[MylesBorins]

A quick proposal.

How would people feel about allowing for semver-patch changes to land as per usual, but to hold off on landing semver-minor prs until the group has reached consensus on an implementation?

[bmeck]

@MylesBorins if we can go forward with that on a feature level of consensus I think that is fine. I do still want to work on the user land Loader bits since thats most of what I'm doing right now and isn't the disambiguation mechanism. If desired I can pause that too since there are other APIs that would be nice but are not directly related to Modules that would aid things. I'm also unsure if we need to stop the vm.* bits since they shouldn't be much more than hooks into the actual specification.

[TimothyGu]

I'm also unsure if we need to stop the vm.* bits since they shouldn't be much more than hooks into the actual specification.

👍 on this. Work on the VM module has not been controversial.

[mhdawson]

+1 on landing at least semver minor changes

[jkrems]

+1 on landing changes until we have "official" opinions (use cases, goals, scope) and are a chartered working group. It seems weird to change process in nodejs/node based on what is - at least at this point - just "people talking to each other".