Node.js Foundation Modules Team Meeting 2019-04-24

[MylesBorins]

Time

UTC Wed 24-Apr-2019 19:00 (07:00 PM):

Timezone	Date/Time
US / Pacific	Wed 24-Apr-2019 12:00 (12:00 PM)
US / Mountain	Wed 24-Apr-2019 13:00 (01:00 PM)
US / Central	Wed 24-Apr-2019 14:00 (02:00 PM)
US / Eastern	Wed 24-Apr-2019 15:00 (03:00 PM)
London	Wed 24-Apr-2019 20:00 (08:00 PM)
Amsterdam	Wed 24-Apr-2019 21:00 (09:00 PM)
Moscow	Wed 24-Apr-2019 22:00 (10:00 PM)
Chennai	Thu 25-Apr-2019 00:30 (12:30 AM)
Hangzhou	Thu 25-Apr-2019 03:00 (03:00 AM)
Tokyo	Thu 25-Apr-2019 04:00 (04:00 AM)
Sydney	Thu 25-Apr-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-04-24&iso=20190424T19
• or http://www.wolframalpha.com/input/?i=07PM+UTC%2C+Apr+24%2C+2019+in+local+time

Links

• Minutes Google Doc: https://docs.google.com/document/d/12hKVk4C9PNkHHZoOQA6I2Y_oUlAPteDTnEIyyp9Odqc/edit
• Previous Minutes Google Doc: https://docs.google.com/document/d/1t9sYWYkDEAZKMhj-OGNlCeVyPjxOVYpscyOEury3Vhw/edit

Agenda

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

Approve PR (5 Minutes)

• Governance: "Pull Requests" post Phase 2 upstream #311

Discussion (50 minutes)

• Review Phase 3 #316
  • 10 minute timebox
• To Dual Mode or Not to Dual Mode
  • 30 minute timebox
  • Refs:
    • Exports main #41
    • Proposal for dual ESM/CommonJS packages #273
    • Proposal for single-mode packages with optional fallbacks for older versions of node #299
• Proposal: Support loading package by own "name" #306
  • 5 minute timebox
• Moving forward with Dynamic Modules? #252
  • 5 minute timebox

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]

I didn’t think we were still debating if we should support dual ESM/CommonJS packages, but if we are, there was discussion in the import file resolution proposal repo in GeoffreyBooth/node-import-file-specifier-resolution-proposal#1 and GeoffreyBooth/node-import-file-specifier-resolution-proposal#11 that led to this text:

Dual instantiation

The ESM and CommonJS interpretations of a module have independent storage. The same source module may be loaded as both an ESM version and a CommonJS version in the same application, in which case the module will be evaluated twice (once for each parse goal) and the resulting instances will never have the same identity. This means that whilst import and import() may return a CommonJS exports value for a module whose interpretation is confirmed to be CommonJS, require() will never return the ESM namespace object for a module whose interpretation is ESM.

Applications that avoid require() and only rely on Node’s interpretation of a module, via import and import(), will never trigger simultaneous instantiation of both versions. With this proposal, the only way to encounter this dual-instantiation scenario is if some part of the application uses import/import() to load a module and some other part of the application overrides Node’s interpretation by using require() or [module.createRequireFromPath][nodejs-docs-modules-create-require-from-path] to load that same module.

The choice to allow dual-instantiation was made to provide well-defined deterministic behaviour. Alternative behaviours, such as throwing a runtime exception upon encountering the scenario, were deemed brittle and likely to cause user frustration. Nevertheless, dual instantiation is not an encouraged pattern. Users should ideally avoid dual-instantiation by migrating consumers away from require to use import or import().

It took me a while to find this; if people don’t mind, I’d like to migrate that repo’s discussions and final output .md file into this repo so that this history is easier to find in a search.

[jdalton]

(I may be late to the meeting, I approved #311)