Repository navigation
Out-of-Band Meeting Proposal #399
Description
Activity
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')andimport 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.
Without a way to support dual modules (both pre-module node + post-module node; and a way to do
require('x')andimport 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')andimport from 'x/module', or vice versarequire('x/commonjs')andimport 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 “
requireof ESM” as the last remaining potential solution for makingrequire('x')/import from 'x'a reality. Andrequireof 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 thatrequireof 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
requireof ESM (or some new solution) in a way that it can slip into a later 12.x version.Reacted by LinzWhen you say "from core", who in core is opposed to "ignore the hazard"?
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.
I think it would be worth getting an opinion from the TSC on "ignore the hazard".
- @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?
@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?
Is there a summary of the issue this refers to?
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.
Reacted by Jordan HarbandLet’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.
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).
Reacted by Michaël Zasso, Corey Farrell and Sam Roberts#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.
*what we want to ship flagged I mean here
@guybedford it's too late for that anyway. Today's release is the one that will transition to LTS
Reacted by Jordan Harband and Jan Olaf MartinShipping an LTS release on a Friday? That’s bold . . .
Reacted by Jordan Harband and Gary CryeYou misunderstood me. LTS releases must have their commits bake into a Current release for two weeks. 12.x LTS starts in two weeks. So today's current release has everything that will be in the first 12.x LTS (except the commit that changes the release type)
@targos I wasn't aware there was an LTS cutoff two weeks before, I guess we will have to apply further changes to the next minor then? Or can further --experimental-modules changes land on patch releases?
The goal here would be to be able to say "12 LTS --experimental-modules" is the current recommended implementation. But if we've already missed the cutoff for such a thing then certainly there is no need for an out-of-band meeting.
- Anything that goes into 13 can be backported to LTS two weeks later. Since we are experimental / behind a flag we don't need to wait for a minor…On Fri, Oct 11, 2019, 5:10 PM Guy Bedford ***@***.***> wrote: @targos <https://github.com/targos> I wasn't aware there was an LTS cutoff two weeks before, I guess we will have to apply further changes to the next minor then? Or can further --experimental-modules changes land on patch releases? The goal here would be to be able to say "12 LTS --experimental-modules" is the current recommended implementation. But if we've already missed the cutoff for such a thing then certainly there is no need for an out-of-band meeting. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#399?email_source=notifications&email_token=AADZYV6G3PTHF2W3YQ7CPQLQODTWDA5CNFSM4I7UPAP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEBBHD3A#issuecomment-541225452>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADZYV7I356VNXFN6UZD2F3QODTWDANCNFSM4I7UPAPQ> .
Ok, in that case, there is no need for an out-of-band meeting then and we can treat the Node 12 case as a possible backport. It is a shame not to have met the deadline - myself and @bmeck have been working on this modules branch for nearly 3 years now. I hope we don't let this drag on for much more than the current 4 years since ES6 for landing modules in Node.js.
Reacted by Rob Palmer, Zack Schuster, Jordan Harband, Geoffrey Booth and Christopher S. Case
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!