Out-of-Band Meeting Proposal

[guybedford]

Since yesterday's meeting it turns out we were able to work around the async bootstrap issues with a more conservative approach that gets all the tests passing on the experimental modules unflagging PR.

This means that if we can find consensus on requirements for release, there is a window for us to still meet the Node.js 12 LTS release which is on the 21st of October, two days before our next meeting.

In order for us to discuss this possibility, I'd like to propose we arrange an out-of-band meeting early next week. I've created a Doodle to find a shared time for this meeting here -https://doodle.com/poll/a4nvpv6tqf7cnu9g. Please fill this out when you can.

The resolutions from last meeting have now been implemented. I'd like to ask you all to please put some serious consideration to where we are on modules, and any considerations or feedback you have concerning a shippable implementation. It feels like we are very close here, but if we do not have consensus to release there will be other opportunities in future as well - lets see how discussion goes!

[ljharb]

I'll reiterate the concern I continue to have - that without a way to support dual modules (both pre-module node + post-module node; and a way to do require('x') and import from 'x' in post-module node) immediately upon unflagging, we'll be doing a great disservice to the community.

My preference would be to hold off unflagging until we've figured out how to achieve it - one of our original use cases from the document.

[GeoffreyBooth]

Without a way to support dual modules (both pre-module node + post-module node; and a way to do require('x') and import from 'x' in post-module node) immediately upon unflagging, we’ll be doing a great disservice to the community.

Missing the LTS window and not shipping support for ES modules for another year or more also does a great disservice to the community.

We all wanted a better solution for dual packages. I was one of the champions of that effort. Ultimately the best I or anyone could do was require('x') and import from 'x/module', or vice versa require('x/commonjs') and import from 'x', and I wrote the docs explaining and recommending that approach. With "exports" we at least get friendly paths on both sides.

I consider the “ignore the hazard” solution (if you can call it that) to be off the table; it just won’t find approval from core. That leaves “require of ESM” as the last remaining potential solution for making require('x')/import from 'x' a reality. And require of ESM is still achievable; it can ship after unflagging, just as loaders can, and might need to ship in 13 anyway if it creates any breaking changes for CommonJS.

In the meantime people will presumably use the 'x/module' approach, and that’s fine if slightly verbose, and that’ll continue to work in 13 and beyond. I think most members of the community would prefer we unflag now with that limitation rather than wait, especially since there’s no guarantee that we’ll ever find a better solution; it’s hardly a certainty that either core might yield on the hazard or that require of ESM will be implemented in a way that core will accept. If there was a promising solution on the table that had consensus and we just needed time to implement it, sure, I might see holding off unflagging in the hope that we can make that happen; but like you write, this has been a top use case from the beginning and this is the best we’ve been able to come up with after literally years of study.

Conversely, unflagging will draw a lot of new attention to modules in Node, and we might get some new contributors with fresh ideas—maybe someone even implements require of ESM (or some new solution) in a way that it can slip into a later 12.x version.

[ljharb]

When you say "from core", who in core is opposed to "ignore the hazard"?

[GeoffreyBooth]

When you say “from core”, who in core is opposed to “ignore the hazard”?

@MylesBorins, for one. And as both the leader of this group and a member of the TSC I would expect a lot of TSC members would defer to his judgment on this. So sure, if you can convince him, you stand a chance; but the more we’ve been researching it the more firm he’s gotten.

[ljharb]

I think it would be worth getting an opinion from the TSC on "ignore the hazard".

[MylesBorins]

@ljharb generally things don’t go to the TSC unless there is a lack of consensus. We can request their opinion but honestly they will most likely defer to those who have been working on the problem space. @mcollina, @Fishrock123, @targos, and @mhdawson have been most involved in this process up until now and can maybe chime in. /cc @nodejs/tsc in case anyone else has an opinion. The next meeting is next Wednesday, and we can definitely put this on the agenda. If we want the TSC to give an opinion do you have an explicit thing you are proposing as an alternative for then to consider? If the alternative is “not shipping” I don’t think individuals will find that a compelling alternative. Do you have an explicit alternative to propose including what we would need to implement? If we bring it to the TSC and they defer to our group or prefer the current implementation do you plan to block consensus anyways? What are our options?

[ljharb]

@MylesBorins sure. but if there's pressure to unflag in the modules group (ie, full consensus isn't the goal) then why are we holding back solutions just because they lack full consensus?

Let me ask a different way. Let's say the modules group as a whole decides that "ignore the hazard" is acceptable. What solutions seem to be currently available that would allow for dual require/import of a specifier?

[Fishrock123]

Is there a summary of the issue this refers to?

[GeoffreyBooth]

Is there a summary of the issue this refers to?

@Fishrock123 Please see #371 and https://github.com/jkrems/singleton-issue. Potential solutions are discussed in https://github.com/nodejs/modules/blob/master/doc/plan-for-new-modules-implementation.md#phase-4-further-improvements-after-unflagging under the “Dual CommonJS/ESM packages” bullet.

[GeoffreyBooth]

Let’s say the modules group as a whole decides that “ignore the hazard” is acceptable.

Currently, at least, this isn’t the case. Besides me and @MylesBorins and @guybedford (and @jkrems?) publicly opposed, this was discussed in the 2019-08-28 and 2019-09-11 meetings and there didn’t seem to be much support within our group for ignoring the hazard.

[mcollina]

I think the ship has sailed to hit the v12 LTS milestone. I'm not keen on unflagging an experimental feature right before we hit the LTS mark. We can definitely land it after the LTS mark, and I think we should land it in Node v13 (keeping the warning).

[guybedford]

#400 sounds like a sensible plan forward here.

It would still be useful to have an out-of-band meeting to be able to determine what we want to ship in the 12 LTS though.

We're currently a few short on quorum responses for the Doodle - please reply there if you haven't already.

[guybedford]

*what we want to ship flagged I mean here