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-05-08 #326

Closed
MylesBorins opened this issue May 8, 2019 · 5 comments
Closed

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

MylesBorins opened this issue May 8, 2019 · 5 comments

Comments

@MylesBorins
Copy link
Contributor

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:

Links

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

@ljharb

This comment has been minimized.

@demurgos

This comment has been minimized.

@GeoffreyBooth
Copy link
Member

GeoffreyBooth commented May 8, 2019

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

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

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

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

4 participants