Node.js Foundation Modules Team Meeting 2019-02-20

[MylesBorins]

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

#261

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
  • 5 minute timebox
  • Refs:
    • Entry points proposal spec and implementation #32
    • Import file specifier proposal implementation #256
    • Mode: esm proposal #247

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

[weswigham]

Man, I love getting booted while someone's mid-sentence XD

Well.... what do we do now?

[MylesBorins]

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]

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]

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]

SHould we clear an entire day or afternoon to work on this?

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]

@weswigham it’s way too soon to vote; there are many opinions left unvoiced.

[weswigham]

Aight. Guess we'll need to schedule more time for it, then.

[GeoffreyBooth]

So in the meeting we agreed to put the current import of 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]

@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]

@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]

@GeoffreyBooth merging dynamic modules was discussed in the meeting and we did not have consensus to move forward with it

[bmeck]

@GeoffreyBooth

why not release full interop flagged rather than defaults only flagged?

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]

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]

@GeoffreyBooth not to my knowledge anywhere, however other runtimes built ontop of Node such as Meteor have done so.