Node.js Foundation Modules Team Meeting 2019-05-08

[MylesBorins]

Time

UTC Wed 08-May-2019 19:00 (07:00 PM):

Timezone	Date/Time
US / Pacific	Wed 08-May-2019 12:00 (12:00 PM)
US / Mountain	Wed 08-May-2019 13:00 (01:00 PM)
US / Central	Wed 08-May-2019 14:00 (02:00 PM)
US / Eastern	Wed 08-May-2019 15:00 (03:00 PM)
London	Wed 08-May-2019 20:00 (08:00 PM)
Amsterdam	Wed 08-May-2019 21:00 (09:00 PM)
Moscow	Wed 08-May-2019 22:00 (10:00 PM)
Chennai	Thu 09-May-2019 00:30 (12:30 AM)
Hangzhou	Thu 09-May-2019 03:00 (03:00 AM)
Tokyo	Thu 09-May-2019 04:00 (04:00 AM)
Sydney	Thu 09-May-2019 05:00 (05:00 AM)

Or in your local time:

• http://www.timeanddate.com/worldclock/fixedtime.html?msg=Node.js+Foundation+Modules%20Team+Meeting+2019-05-08&iso=20190508T19
• or http://www.wolframalpha.com/input/?i=07PM+UTC%2C+May+08%2C+2019+in+local+time

Links

• Minutes Google Doc: https://docs.google.com/document/d/18ZUWtRYq-H5JwcFfGdUFsHi5Q5QB5mCbCngAM_N-MUE/edit?usp=sharing
• Previous Minutes Google Doc: https://docs.google.com/document/d/12hKVk4C9PNkHHZoOQA6I2Y_oUlAPteDTnEIyyp9Odqc/edit

Agenda

Extracted from modules-agenda labelled issues and pull requests from the nodejs org prior to the meeting.

nodejs/modules

• Proposal: CommonJS named exports defined in package.json #324
• Proposal for dual ESM/CommonJS packages #273
• Feedback on extension resolution #323
• Proposal: Support loading package by own "name" #306
• Proposal for single-mode packages with optional fallbacks for older versions of node #299
• Moving forward with Dynamic Modules? #252

nodejs/ecmascript-modules

• esm: scoped --type, cpp refactoring #57
• esm: experimental wasm modules #46
• Exports main #41

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

[GeoffreyBooth]

Consensuses reached:

• The WASM PR (esm: experimental wasm modules ecmascript-modules#46) can land. 8 👍s in the meeting plus additional approvals on that PR get it over the top.
• We all agree we want to support dual packages in a better way than is achievable now.
• The new-field-for-ESM-entry-point PR (Exports main ecmascript-modules#41) can potentially land behind a new flag, assuming one person who wasn’t on the meeting today agrees and that everyone approves the revised PR. (@MylesBorins?) This PR would be against modules-lkgr like we did for all the Phase 2 work, and would not become an upstream PR until we’re done working on at least dual package stuff or maybe all of Phase 3. At some point down the line we’ll need to either replace this field with overloaded "main" (if extension searching is enabled and people prefer overloaded "main" to a new field) or remove the flag; the flag is only to gather feedback.
• @weswigham will open a PR on ecmascript-modules against modules-lkgr for require of ESM; just the basic functionality for now, without handling of packages and/or refactoring/merging the resolvers.
• The named-exports-in-package.json PR (Proposal: CommonJS named exports defined in package.json #324) can move forward into design and implementation. It’s no one’s preference, but it might end up shipping if no better alternatives achieve consensus.

[MylesBorins]

Follow up because I was not in the meeting

We all agree we want to support dual packages in a better way than is achievable now.

I object to this. I've made my objection official in the issue tracking dual mode and will follow up with a more in depth case study explaining why. As such I do not agree to the new field landing behind a flag

@weswigham will open a PR on ecmascript-modules against modules-lkgr for require of ESM; just the basic functionality for now, without handling of packages and/or refactoring/merging the resolvers.

I want to make it clear that I still have extreme reservations about this proposal. I've added my thoughts to the tracking issue.

[MylesBorins]

Also, it seems like there was discussion about continuing the work for the project in the ecmascript-modules fork. At this point I don't see a benefit in us doing a large amount of work in the fork, aside from workshopping single PRs before sending upstream. I would very much like us to avoid getting too far ahead of master in the fork for now unless it is necessary. If we have consensus about something it should simply land upstream. If we don't have consensus we shouldn't be landing it in a fork