Repository navigation
Node.js Foundation Modules Team Meeting 2019-02-20 #270
Description
Time
UTC Wed 20-Feb-2019 20:00 (08:00 PM):
| Timezone | Date/Time |
|---|---|
| US / Pacific | Wed 20-Feb-2019 12:00 (12:00 PM) |
| US / Mountain | Wed 20-Feb-2019 13:00 (01:00 PM) |
| US / Central | Wed 20-Feb-2019 14:00 (02:00 PM) |
| US / Eastern | Wed 20-Feb-2019 15:00 (03:00 PM) |
| London | Wed 20-Feb-2019 20:00 (08:00 PM) |
| Amsterdam | Wed 20-Feb-2019 21:00 (09:00 PM) |
| Moscow | Wed 20-Feb-2019 23:00 (11:00 PM) |
| Chennai | Thu 21-Feb-2019 01:30 (01:30 AM) |
| Hangzhou | Thu 21-Feb-2019 04:00 (04:00 AM) |
| Tokyo | Thu 21-Feb-2019 05:00 (05:00 AM) |
| Sydney | Thu 21-Feb-2019 07:00 (07:00 AM) |
Or in your local time:
- http://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js+Foundation+Modules%20Team+Meeting+2019-02-20&iso=20190220T20
- or http://www.wolframalpha.com/input/?i=08PM+UTC%2C+Feb+20%2C+2019+in+local+time
Links
- Minutes Google Doc: https://docs.google.com/document/d/1AFnHc85SzFZFUqL6xL7xTDOmFB9FM6q9yapjYGQiXi0/edit
- Previous Minutes Google Doc: https://docs.google.com/document/d/14pkjW9fnsgjImVabQQLLgtrJn2x_FCpMGUmoDJej_kQ/edit
Agenda
Extracted from modules-agenda labelled issues and pull requests from the nodejs org prior to the meeting.
Note
This is an out of band follow up to last week’s meeting. The majority of this week’s discussion will be based on the following doc
https://docs.google.com/document/d/1DSWrdV1fzXvlOdTZ5MngDX7v6CU4ZUheJ7ysOZ2uK0w/edit?usp=sharing
Discussion in this issue
We will walk through contentious subjects, attempt to reach consensus quickly, otherwise move towards a vote. We will then review the resulting implementation and attempt to reach consensus that this is what we will move forward with.
Discussion
- Review last weeks discussion
- 5 minute timebox
- CommonJS interop
- 10 minute timebox
- Refs:
- CommonJS import interoperability decisions #264
- Make an update to Dynamic Modules Development in Node.js #24894
- Import named vs default from CommonJS packages #260
- Moving forward with Dynamic Modules? #252
- CJS named exports via two-phase execution #31
- WIP [Do not merge] - Irp type dynamic modules #29
- File Extension Resolution
- 15 minute timebox
- Refs:
- File extension/directory index resolution in ESM #268
- Loaders
- 5 minute timebox
- Requirements to replace upstream
- 10 minute timebox
- Refs:
- Minimum to release? #253
- Requirements to remove flag
Invited
- Modules team: @nodejs/modules
Notes
The agenda comes from issues labelled with modules-agenda across all of the repositories in the nodejs org. Please label any additional issues that should be on the agenda before the meeting starts.
Joining the meeting
- link for participants: https://zoom.us/j/656987750
- For those who just want to watch: https://www.youtube.com/c/nodejs+foundation/live
Activity
weswigham commentedon Feb 20, 2019
Man, I love getting booted while someone's mid-sentence XD
Well.... what do we do now?
MylesBorins commentedon Feb 20, 2019
LOL TSC meeting
To be continue next week. @Fishrock123 mentioned we may want to do a summit. SHould we clear an entire day or afternoon to work on this?
ljharb commentedon Feb 20, 2019
This "one meeting at a time across all node" is ridiculous; can someone please link me to where we're trying to fix that?
weswigham commentedon Feb 20, 2019
We were rapidly approaching "we should vote on weather we have full cjs-style extension and index resolution in the esm resolver" point of the conversation, and were pretty much just presenting opening arguments for the yea and nay sides of it. Should we vote on it asynchronously (as it's obviously an opinion question and we will never reach consensus on it, as stated during the meeting)? Or should we pick it up again later?
GeoffreyBooth commentedon Feb 20, 2019
Yes but only if you can make it viable for people to attend remotely. I stayed up through the middle of the night to call into the Berlin meeting and then no one ever enabled the web meeting for that one.
ljharb commentedon Feb 20, 2019
@weswigham it’s way too soon to vote; there are many opinions left unvoiced.
weswigham commentedon Feb 20, 2019
Aight. Guess we'll need to schedule more time for it, then.
GeoffreyBooth commentedon Feb 21, 2019
So in the meeting we agreed to put the current
importof CommonJS (which is default export only) behind a flag. Someone please remind me why we’re not merging in nodejs/ecmascript-modules#29 and putting that behind a flag? Because the specific implementation of named exports via dynamic modules might change, and we don’t want to merge any implementation in while we’re discussing what it might be?bmeck commentedon Feb 21, 2019
@GeoffreyBooth we have heard objections to Dynamic Modules within this group and some statements of intent to block at TC39 from within the group. I believe that Dynamic Modules being merged is early given that we have objections that would effectively force the proposal to stop.
GeoffreyBooth commentedon Feb 21, 2019
@bmeck Merged unflagged, certainly. But what about behind a flag like we're planning to do for defaults only? What was the reasoning behind not doing that?
I guess the question is what we should do if the dynamic modules approach continues to flounder at tc39. We can cut interop entirely, we can release defaults only flagged or unflagged, or we can release dynamic flagged. If we're going to release some version of interop behind a flag anyway, why not release full interop flagged rather than defaults only flagged?
Not meaning to start a debate here, just asking if these questions were addressed in the meeting. I don't recall us considering these options. If we didn't, I think we should review them in an upcoming meeting.
MylesBorins commentedon Feb 21, 2019
@GeoffreyBooth merging dynamic modules was discussed in the meeting and we did not have consensus to move forward with it
bmeck commentedon Feb 21, 2019
@GeoffreyBooth
Because we should be aiming towards what people can use reliably if we want to move forward with under our own power, rather than encouraging them to move to something that we may not have the power to ship. We do no service by encouraging what we already see as a currently unsafe/non-consensus route. We even have members seeking to block the proposal entirely so we are partly to blame for why it is not moving forward at TC39.
Default only and no interop work as things exist today. Encouraging usage of a feature and then removing it is much more jarring and requires more work than releasing minimal iterations that should be safe to use. If we cannot agree to ship with default only, we will ship without interop, this follows how this group has been able to make progress.
As with other features, we don't ship more when we lack consensus/clear ability to move forward; we remove controversial parts until we can agree on some smaller amount of things that are agreeable and under our ability to ship and do not cause conflict on their own.
GeoffreyBooth commentedon Feb 21, 2019
Sorry I think there's a misunderstanding. I meant, why not ship full interop behind a flag—a permanent flag. Not an experimental flag implying that the feature might someday get unflagged, but a flag for opting into nonstandard/non-spec compliant behavior. Is that not something that Node does?
bmeck commentedon Feb 21, 2019
@GeoffreyBooth not to my knowledge anywhere, however other runtimes built ontop of Node such as Meteor have done so.
MylesBorins commentedon Feb 21, 2019
@GeoffreyBooth I am not in support of this especially when it involves floating a patch on top of V8 that can prove to be unwieldily.
doc: 2019-02-20 Notes