Skip to content
This repository has been archived by the owner on Sep 2, 2023. It is now read-only.

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

Closed
MylesBorins opened this issue Feb 20, 2019 · 15 comments
Closed

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

MylesBorins opened this issue Feb 20, 2019 · 15 comments

Comments

@MylesBorins
Copy link
Contributor

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:

Links

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

@weswigham
Copy link
Contributor

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

Well.... what do we do now?

@MylesBorins
Copy link
Contributor Author

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
Copy link
Member

ljharb commented 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
Copy link
Contributor

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
Copy link
Member

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
Copy link
Member

ljharb commented Feb 20, 2019

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

@weswigham
Copy link
Contributor

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

@GeoffreyBooth
Copy link
Member

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
Copy link
Member

bmeck commented 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
Copy link
Member

@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
Copy link
Contributor Author

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

@bmeck
Copy link
Member

bmeck commented Feb 21, 2019

@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
Copy link
Member

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
Copy link
Member

bmeck commented Feb 21, 2019

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

@MylesBorins
Copy link
Contributor Author

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

MylesBorins added a commit to MylesBorins/modules that referenced this issue Feb 26, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants