From 823c10721332f84b08ce3794b82775802dcfbe88 Mon Sep 17 00:00:00 2001 From: Joyee Cheung Date: Thu, 8 Feb 2018 23:08:41 +0800 Subject: [PATCH 001/226] doc: use ncu-team sync to sync member list --- README.md | 76 +++++++++++++++++++++++++++++-------------------------- 1 file changed, 40 insertions(+), 36 deletions(-) diff --git a/README.md b/README.md index b265630..01ef651 100644 --- a/README.md +++ b/README.md @@ -15,39 +15,43 @@ Work includes: ## Modules [Team Members](https://github.com/orgs/nodejs/teams/modules/members) -* [Yuta Hiroto](https://github.com/abouthiroppy) @abouthiroppy -* [Benjamin Gruenbaum](https://github.com/benjamingr) @benjamingr -* [Ben Newman](https://github.com/benjamn) @benjamn -* [Bradley Meck](https://github.com/bmeck) @bmeck -* [Benedikt Meurer](https://github.com/bmeurer) @bmeurer -* [C J Silverio](https://github.com/ceejbot) @ceejbot -* [Chris Dickinson](https://github.com/chrisdickinson) @chrisdickinson -* [Daniel Rosenwasser](https://github.com/DanielRosenwasser) @DanielRosenwasser -* [Ahmad Abdul-Aziz](https://github.com/devamaz) @devamaz -* [Gus Caplan](https://github.com/devsnek) @devsnek -* [Eugene Ostroukhov](https://github.com/eugeneo) @eugeneo -* [Evan Plaice](https://github.com/evanplaice) @evanplaice -* [Jeremiah Senkpiel](https://github.com/Fishrock123) @Fishrock123 -* [Gil Tayar](https://github.com/giltayar) @giltayar -* [Guy Bedford](https://github.com/guybedford) @guybedford -* [Hassan Sani](https://github.com/inidaname) @inidaname -* [James M Snell](https://github.com/jasnell) @jasnell -* [John-David Dalton](https://github.com/jdalton) @jdalton -* [Jan Olaf Krems](https://github.com/jkrems) @jkrems -* [Lin Clark](https://github.com/linclark) @linclark -* [Jordan Harband](https://github.com/ljharb) @ljharb -* [Wassim Chegham](https://github.com/manekinekko) @manekinekko -* [Matteo Collina](https://github.com/mcollina) @mcollina -* [Matt DuLeone](https://github.com/mduleone) @mduleone -* [Michael Dawson](https://github.com/mhdawson) @mhdawson -* [Myles Borins](https://github.com/MylesBorins) @MylesBorins -* [Refael Ackermann](https://github.com/refack) @refack -* [Rob Palmer](https://github.com/robpalme) @robpalme -* [Michaël Zasso](https://github.com/targos) @targos -* [Torgny Bjers](https://github.com/tbjers) @tbjers -* [Timothy Gu](https://github.com/TimothyGu) @TimothyGu -* [Andrea Giammarchi](https://github.com/WebReflection) @WebReflection -* [Wesley Wigham](https://github.com/weswigham) @weswigham -* [Khaidi Chu](https://github.com/XadillaX) @XadillaX -* [Yosuke Furukawa](https://github.com/yosuke-furukawa) @yosuke-furukawa -* [Zack Schuster](https://github.com/zackschuster) @zackschuster + + +- [@abouthiroppy](https://github.com/abouthiroppy) - Yuta Hiroto +- [@benjamingr](https://github.com/benjamingr) - Benjamin Gruenbaum +- [@benjamn](https://github.com/benjamn) - Ben Newman +- [@bmeck](https://github.com/bmeck) - Bradley Meck +- [@bmeurer](https://github.com/bmeurer) - Benedikt Meurer +- [@ceejbot](https://github.com/ceejbot) - C J Silverio +- [@chrisdickinson](https://github.com/chrisdickinson) - Chris Dickinson +- [@DanielRosenwasser](https://github.com/DanielRosenwasser) - Daniel Rosenwasser +- [@devamaz](https://github.com/devamaz) - Ahmad Abdul-Aziz +- [@devsnek](https://github.com/devsnek) - Gus Caplan +- [@eugeneo](https://github.com/eugeneo) - Eugene Ostroukhov +- [@evanplaice](https://github.com/evanplaice) - Evan Plaice +- [@Fishrock123](https://github.com/Fishrock123) - Jeremiah Senkpiel +- [@giltayar](https://github.com/giltayar) - Gil Tayar +- [@guybedford](https://github.com/guybedford) - Guy Bedford +- [@inidaname](https://github.com/inidaname) - Hassan Sani +- [@jasnell](https://github.com/jasnell) - James M Snell +- [@jdalton](https://github.com/jdalton) - John-David Dalton +- [@jkrems](https://github.com/jkrems) - Jan Olaf Krems +- [@linclark](https://github.com/linclark) - Lin Clark +- [@ljharb](https://github.com/ljharb) - Jordan Harband +- [@manekinekko](https://github.com/manekinekko) - Wassim Chegham +- [@mcollina](https://github.com/mcollina) - Matteo Collina +- [@mduleone](https://github.com/mduleone) - Matt DuLeone +- [@mhdawson](https://github.com/mhdawson) - Michael Dawson +- [@MylesBorins](https://github.com/MylesBorins) - Myles Borins +- [@refack](https://github.com/refack) - Refael Ackermann +- [@robpalme](https://github.com/robpalme) - Rob Palmer +- [@targos](https://github.com/targos) - Michaël Zasso +- [@tbjers](https://github.com/tbjers) - Torgny Bjers +- [@TimothyGu](https://github.com/TimothyGu) - Timothy Gu +- [@WebReflection](https://github.com/WebReflection) - Andrea Giammarchi +- [@weswigham](https://github.com/weswigham) - Wesley Wigham +- [@XadillaX](https://github.com/XadillaX) - Khaidi Chu +- [@yosuke-furukawa](https://github.com/yosuke-furukawa) - Yosuke Furukawa +- [@zackschuster](https://github.com/zackschuster) - + + From bbeb2575310e0e120327e5bdfa54c12dacf32500 Mon Sep 17 00:00:00 2001 From: zackschuster Date: Thu, 8 Feb 2018 23:36:02 +0000 Subject: [PATCH 002/226] Update meeting availability links --- RESOURCES.md | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/RESOURCES.md b/RESOURCES.md index 5be937f..2aed9b7 100644 --- a/RESOURCES.md +++ b/RESOURCES.md @@ -7,31 +7,28 @@ * [ESM modules in node: npm edition](https://gist.github.com/ceejbot/b49f8789b2ab6b09548ccb72813a1054) ### Meetings -* [Meeting availability](https://doodle.com/poll/cqavkzwxtxzccs4z) +* [Meeting availability #1](https://doodle.com/poll/cqavkzwxtxzccs4z) +* [Meeting availability #2](https://doodle.com/poll/vdb8cgz48q3zzt2t) ### Prior Art Following a list of ESM and CommonJS relevant projects. #### Transpilers - * [Babel](http://babeljs.io) transpiled ES6+ including modules downgraded to CommonJS with an `exports.default` strategy * [TypeScript](https://www.typescriptlang.org) transpiled classes including ES6 like/inspired modules #### Bundlers - * [Webpack](https://webpack.js.org) multi purpose bundler compatible with CommonJS `exports.default` strategy. Actually diverging from npm resolution preferring a `browser` field in the `package.json` instead of actual CommonJS. * [Rollup](https://rollupjs.org) next-generation ES6 module bundler with tree shaking capability * [Parceljs](https://parceljs.org/) multi purpose bundler focused on zero config and performance * [Browserify](http://browserify.org) the CommonJS module bundler that brought NodeJS to the Web #### Compilers - * [Reify](https://www.npmjs.com/package/reify) compiles ESM syntax to CommonJS, supporting live bindings without rewriting imported variable names * [@std/esm](https://github.com/standard-things/esm) is a fork of Reify focused on following Node's ESM support roadmap while providing a bridge from the CJS/ESM usage of today to the ESM of tomorrow. #### Runtime Utilities - * [cjs4esm](https://github.com/WebReflection/cjs4esm#cjs4esm--) brings CommonJS modules and `require` to ESM compatible environments such [SpiderMonkey](https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey), [JSC](https://trac.webkit.org/wiki/JavaScriptCore), or ESM compatible browsers * [import.js](https://github.com/WebReflection/import.js#importjs) is a dynamic `import(...)` polyfill * [SpiderMonkey](https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey) [ESM Loader](https://searchfox.org/mozilla-central/source/js/src/shell/ModuleLoader.js) From 88349009f8f775ecbb2410324eba05fff3bc7118 Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Wed, 14 Feb 2018 23:58:51 -0500 Subject: [PATCH 003/226] doc: s/Google Hangouts/Zoom --- GOVERNANCE.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 532be71..2e4dda9 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -14,7 +14,7 @@ Collaborators and given commit-access to the project. ### Team Meetings -The Team meets bi-weekly on a Google Hangout On Air. A designated moderator +The Team meets bi-weekly on Zoom.us. A designated moderator approved by the Team runs the meeting. Each meeting should be published to YouTube. From 24e1ec4233ca048162c304e7468059ac3bd36e3f Mon Sep 17 00:00:00 2001 From: Benjamin Gruenbaum Date: Fri, 23 Feb 2018 03:47:24 +0200 Subject: [PATCH 004/226] Revert "doc: s/Google Hangouts/Zoom" --- GOVERNANCE.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 2e4dda9..532be71 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -14,7 +14,7 @@ Collaborators and given commit-access to the project. ### Team Meetings -The Team meets bi-weekly on Zoom.us. A designated moderator +The Team meets bi-weekly on a Google Hangout On Air. A designated moderator approved by the Team runs the meeting. Each meeting should be published to YouTube. From 7504c01d2c50befae35e47b4164c738983640324 Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Wed, 14 Feb 2018 16:04:28 -0500 Subject: [PATCH 005/226] doc: add meeting notes for Feb 14 2018 --- doc/meetings/2017-02-14.md | 99 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 99 insertions(+) create mode 100644 doc/meetings/2017-02-14.md diff --git a/doc/meetings/2017-02-14.md b/doc/meetings/2017-02-14.md new file mode 100644 index 0000000..5bd2d98 --- /dev/null +++ b/doc/meetings/2017-02-14.md @@ -0,0 +1,99 @@ +# Node.js Foundation Modules Team Meeting 2018-02-14 + +## Links + +* **Recording**: https://www.youtube.com/watch?v=QURheOVmqDk +* **GitHub Issue**: https://github.com/nodejs/modules/issues/25 +* **Minutes Google Doc**: https://docs.google.com/document/d/17T8ZeF2mUPffiDvulqd_HqD_JrTNaf8ch2dFT1hMfD0/edit?usp=sharing + +## Present + +Benjamin Gruenbaum (@benjamingr) +Bradley Meck (@bmeck) +C J Silverio @ceejbot +Daniel Rosenwasser (@DanielRosenwasser) +Gus Caplan (@devsnek) +Jeremiah Senkpiel (@fishrock123) +Gil Tayar (@giltayar) +Guy Bedford (@guybedford) +Rebecca Turner (@iarna) +James M Snell (@jasnell) +John-David Dalton (@jdalton) +Lin Clark (@linclark) +Wassim Chegham (@manekinekko) +Matt DuLeone (@mduleone) +Michael Dawson (@mhdawson) +Myles Borins (@mylesborins) +Andrea Giammarchi (@WebReflection) +Wesley Wigham (@weswigham) +Zack Schuster (@zackschuster) + +## Agenda + +### Announcements + +### nodejs/modules + +* How often and when should we meet? [#2](https://github.com/nodejs/modules/issues/2) + - Meeting doodle - https://doodle.com/poll/vdb8cgz483zzt2t - Default is in EST 4PM + - **ACTION ITEM FOR MYLES**: Email people about finalized time on Friday & add to Node.js Google Calendar +* Scope of team [#17](https://github.com/nodejs/modules/issues/17) + - Not chartering immediately - will come later down the line + - Should we expand scope to include CJS components + - Mention of a few issus by Bradley. Seems like these are EJS issues as + Well. + - CommonJS is frozen, we cannot table issues that will affect external + behaviour +* Managing Signal to Noise [#15](https://github.com/nodejs/modules/issues/15) + - Myles to document “Discussion” Tag mechanism +* Governance and Membership Requirements [#8](https://github.com/nodejs/modules/issues/8) + - Do we need more time than 48 hours for approving PRs? + - Some say yes. + - We have a very large group; much of the time members may be caught off guard. Perhaps we need some sort of quorum. + - Maybe a way to manage engagement? + - Sure, but PRs are the least concerning thing. The points of conflict are typically not code changes though. + - Just to clarify, when we talk about PRs, we’re typically talking about non-code based PRs that pertain to this group. + - So do we want a quorum-based decision process for this repo? + - Action item: Bradley will document this quorum policy. + - If we have no dissenters, move forward on a given decision. + - I.e. decision making is based on “tacit approval” - silence means approval by default + - When necessary (e.g. objections come up), quorum is 50% of active members of the working group. + - (Q: what is active?) + - We expect membership activity to taper off, so whoever is currently still active. + - What is explicit approval? + - Something as simple as “LGTM”, :+1:, etc. + - How do we track “active” participants? + - Our most recent metric has been “did you fill out the form for this meeting?” + - If someone isn’t active and just shows up for a single decision, is that fair? + - Do we track engagement by the tracker or by meetings? + - Does interest in a set of specific domains imply inactivity? + - No, that’s not quite what the concern is about. + - How about “if in the first two months, we see a lack of activity, we ask the participant to step to observer status?” + - That can be an extremely sensitive topic. We should come up with something explicit. + - Conclusion: continue discussing this on the issue tracker +* Online Module Summit [#9](https://github.com/nodejs/modules/issues/9) + - Really great knowledge-sharing exercise discussing topics we feel are important. + - That way anyone who can’t participate can catch up with it. + - Conclusion: Bradley will plan this out. +* Guiding Design Principles [#11](https://github.com/nodejs/modules/issues/11) + - Is there a difference between our design principles and our scope. + - Bradley: “I think they’re very different - our design principles give us our goals” + - Our scope is what we’re allowed to do. + - Jeremiah: “Is this not different from the goals document?” + - Conclusion: kick this back to the issue tracker +* initial GOALS declaration [#23](https://github.com/nodejs/modules/pull/23) + - Bradley: don’t want to pull this in yet. + - Also, request for clarification from Webpack. + - Will discuss further. + - Wesley: Should have an explicit rationale for why we’ve established each goal + - Yes, let’s add that to the PR. + +## Q&A, Other + +No questions for this week. + +## Upcoming Meetings + +* **Node.js Foundation Calendar**: https://nodejs.org/calendar + +Click `+GoogleCalendar` at the bottom right to add to your own Google calendar. From 62fccd9452306520eca8ef7036db708c5e8b29ea Mon Sep 17 00:00:00 2001 From: Gus Caplan Date: Wed, 14 Feb 2018 16:09:51 -0600 Subject: [PATCH 006/226] add newlines to members present --- doc/meetings/2017-02-14.md | 36 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/doc/meetings/2017-02-14.md b/doc/meetings/2017-02-14.md index 5bd2d98..3e80a94 100644 --- a/doc/meetings/2017-02-14.md +++ b/doc/meetings/2017-02-14.md @@ -8,24 +8,24 @@ ## Present -Benjamin Gruenbaum (@benjamingr) -Bradley Meck (@bmeck) -C J Silverio @ceejbot -Daniel Rosenwasser (@DanielRosenwasser) -Gus Caplan (@devsnek) -Jeremiah Senkpiel (@fishrock123) -Gil Tayar (@giltayar) -Guy Bedford (@guybedford) -Rebecca Turner (@iarna) -James M Snell (@jasnell) -John-David Dalton (@jdalton) -Lin Clark (@linclark) -Wassim Chegham (@manekinekko) -Matt DuLeone (@mduleone) -Michael Dawson (@mhdawson) -Myles Borins (@mylesborins) -Andrea Giammarchi (@WebReflection) -Wesley Wigham (@weswigham) +Benjamin Gruenbaum (@benjamingr) +Bradley Meck (@bmeck) +C J Silverio @ceejbot +Daniel Rosenwasser (@DanielRosenwasser) +Gus Caplan (@devsnek) +Jeremiah Senkpiel (@fishrock123) +Gil Tayar (@giltayar) +Guy Bedford (@guybedford) +Rebecca Turner (@iarna) +James M Snell (@jasnell) +John-David Dalton (@jdalton) +Lin Clark (@linclark) +Wassim Chegham (@manekinekko) +Matt DuLeone (@mduleone) +Michael Dawson (@mhdawson) +Myles Borins (@mylesborins) +Andrea Giammarchi (@WebReflection) +Wesley Wigham (@weswigham) Zack Schuster (@zackschuster) ## Agenda From bd8d05ffb7e960f17156c83e433eee1b075370b1 Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Thu, 15 Feb 2018 17:19:10 -0500 Subject: [PATCH 007/226] fixup: fix doodle link --- doc/meetings/2017-02-14.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/meetings/2017-02-14.md b/doc/meetings/2017-02-14.md index 3e80a94..8bc5944 100644 --- a/doc/meetings/2017-02-14.md +++ b/doc/meetings/2017-02-14.md @@ -35,7 +35,7 @@ Zack Schuster (@zackschuster) ### nodejs/modules * How often and when should we meet? [#2](https://github.com/nodejs/modules/issues/2) - - Meeting doodle - https://doodle.com/poll/vdb8cgz483zzt2t - Default is in EST 4PM + - Meeting doodle - https://doodle.com/poll/vdb8cgz48q3zzt2t - Default is in EST 4PM - **ACTION ITEM FOR MYLES**: Email people about finalized time on Friday & add to Node.js Google Calendar * Scope of team [#17](https://github.com/nodejs/modules/issues/17) - Not chartering immediately - will come later down the line From ba54a61a0bbae57db2f28d97523ec55655de4b4a Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Thu, 15 Feb 2018 01:07:58 -0500 Subject: [PATCH 008/226] doc: move code of conduct to CODE_OF_CONDUCT.md It is currently in the GOVERNAMCE.md file. I think it should be easy to find and not buried in a document people may not see. --- CODE_OF_CONDCUCT.md | 6 ++++++ 1 file changed, 6 insertions(+) create mode 100644 CODE_OF_CONDCUCT.md diff --git a/CODE_OF_CONDCUCT.md b/CODE_OF_CONDCUCT.md new file mode 100644 index 0000000..c78cd24 --- /dev/null +++ b/CODE_OF_CONDCUCT.md @@ -0,0 +1,6 @@ +### Code of Conduct + +The [Node.js Code of Conduct][] applies to this Team. + +[Node.js Code of Conduct]: https://github.com/nodejs/admin/blob/master/CODE_OF_CONDUCT.md +[Node.js Moderation Policy]: https://github.com/nodejs/admin/blob/master/Moderation-Policy.md From d9113817c6ba65a3ecb3ef8d8c88ab4f36e8339e Mon Sep 17 00:00:00 2001 From: Benjamin Gruenbaum Date: Thu, 15 Feb 2018 10:39:54 +0200 Subject: [PATCH 009/226] Rename CODE_OF_CONDCUCT.md to CODE_OF_CONDUCT.md --- CODE_OF_CONDCUCT.md => CODE_OF_CONDUCT.md | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename CODE_OF_CONDCUCT.md => CODE_OF_CONDUCT.md (100%) diff --git a/CODE_OF_CONDCUCT.md b/CODE_OF_CONDUCT.md similarity index 100% rename from CODE_OF_CONDCUCT.md rename to CODE_OF_CONDUCT.md From 02e06faa286590e54eebceb6168d239d84d417c0 Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Thu, 15 Feb 2018 16:59:56 -0500 Subject: [PATCH 010/226] fixup: fixed it --- CODE_OF_CONDUCT.md | 8 ++++++-- GOVERNANCE.md | 12 ------------ 2 files changed, 6 insertions(+), 14 deletions(-) diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index c78cd24..c33bae8 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -1,6 +1,10 @@ -### Code of Conduct +# Code of Conduct -The [Node.js Code of Conduct][] applies to this Team. +The [Node.js Code of Conduct][] applies to this team. + +# Moderation Policy + +The [Node.js Moderation Policy][] applies to this team. [Node.js Code of Conduct]: https://github.com/nodejs/admin/blob/master/CODE_OF_CONDUCT.md [Node.js Moderation Policy]: https://github.com/nodejs/admin/blob/master/Moderation-Policy.md diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 532be71..2381ca1 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -86,15 +86,3 @@ By making a contribution to this project, I certify that: personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. - -### Moderation Policy - -The [Node.js Moderation Policy][] applies to this Team. - -### Code of Conduct - -The [Node.js Code of Conduct][] applies to this Team. - -[Node.js Code of Conduct]: https://github.com/nodejs/admin/blob/master/CODE_OF_CONDUCT.md -[Node.js Moderation Policy]: https://github.com/nodejs/admin/blob/master/Moderation-Policy.md - From 9ef6df8bd8d8911efc498f007991a6a4cf1a0b64 Mon Sep 17 00:00:00 2001 From: Bradley Farias Date: Wed, 14 Feb 2018 14:10:58 -0600 Subject: [PATCH 011/226] Document quorum required in order to merge PRs --- GOVERNANCE.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 2381ca1..139bc51 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -60,6 +60,10 @@ or else the discussion will continue. Simple majority wins. Note that some changes to Team membership require unanimous consensus. See "Team Membership" above. +### Merging PRs into this Repository + +Pull requests must reach consensus in a meeting in order to be merged into this repository. Merging of pull requests must be decided during a meeting that has a minimal quorum of 50% of all active members. A pull request that is is unable to reach quorum due to lack of consensus or quorum must not be merged into this repository. + ## Developer's Certificate of Origin 1.1 From 8c3cd47104dc8c1eb305466ab38fe0069408ffdb Mon Sep 17 00:00:00 2001 From: Bradley Farias Date: Wed, 14 Feb 2018 16:20:26 -0600 Subject: [PATCH 012/226] observers callout --- GOVERNANCE.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 139bc51..f0e1564 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -62,7 +62,7 @@ Note that some changes to Team membership require unanimous consensus. See ### Merging PRs into this Repository -Pull requests must reach consensus in a meeting in order to be merged into this repository. Merging of pull requests must be decided during a meeting that has a minimal quorum of 50% of all active members. A pull request that is is unable to reach quorum due to lack of consensus or quorum must not be merged into this repository. +Pull requests must reach consensus in a meeting in order to be merged into this repository. Merging of pull requests must be decided during a meeting that has a minimal quorum of 50% of all active members. Members with observer status are not considered active members for the purposes of reaching quorum. A pull request that is is unable to reach quorum due to lack of consensus or quorum must not be merged into this repository. ## Developer's Certificate of Origin 1.1 From 3f59f4b688eae140f1423e59dd59325390c3a79a Mon Sep 17 00:00:00 2001 From: Bradley Farias Date: Thu, 15 Feb 2018 09:44:34 -0600 Subject: [PATCH 013/226] errata and editorial exceptions --- GOVERNANCE.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index f0e1564..e03753e 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -62,7 +62,11 @@ Note that some changes to Team membership require unanimous consensus. See ### Merging PRs into this Repository -Pull requests must reach consensus in a meeting in order to be merged into this repository. Merging of pull requests must be decided during a meeting that has a minimal quorum of 50% of all active members. Members with observer status are not considered active members for the purposes of reaching quorum. A pull request that is is unable to reach quorum due to lack of consensus or quorum must not be merged into this repository. +Pull requests must reach consensus in a meeting in order to be merged into this repository. Merging of pull requests must be decided during a meeting that has a minimal quorum of 50% of all active members. Members with observer status are not considered active members for the purposes of reaching quorum. A pull request that is is unable to reach quorum due to lack of consensus or quorum must not be merged into this repository. Pull requests that fail to be merged will be addressed on a case by case basis. + +#### Errata and Editorial Changes + +A special exception is made for pull requests seeking to fix errata or perform editorial changes to this repository. Errata or editorial pull requests may be merged without being presented at a meeting if a reasonable time is given for review and there no dissent. The time period seen as reasonable for review varies on a case by case basis as determined by the author. A member may request a specific time period for review of a errata or editorial pull request not to exceed the next meeting date. If a time for review is requested, members must wait for that time period to pass or review be completed prior to that time. ## Developer's Certificate of Origin 1.1 From 98e6bf5752aceee322844c781dec6c7663019e3c Mon Sep 17 00:00:00 2001 From: Bradley Farias Date: Thu, 15 Feb 2018 10:50:09 -0600 Subject: [PATCH 014/226] be more explicit about scope of merging PRs --- GOVERNANCE.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index e03753e..0c8add6 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -62,6 +62,8 @@ Note that some changes to Team membership require unanimous consensus. See ### Merging PRs into this Repository +This section does not apply to [the Node.js core repository](https://github.com/nodejs/node). It only applied to [the Modules repository](https://github.com/nodejs/modules). + Pull requests must reach consensus in a meeting in order to be merged into this repository. Merging of pull requests must be decided during a meeting that has a minimal quorum of 50% of all active members. Members with observer status are not considered active members for the purposes of reaching quorum. A pull request that is is unable to reach quorum due to lack of consensus or quorum must not be merged into this repository. Pull requests that fail to be merged will be addressed on a case by case basis. #### Errata and Editorial Changes From 686094c3f823046bcd413b3f7dc1921d654bd163 Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Wed, 14 Feb 2018 23:58:51 -0500 Subject: [PATCH 015/226] doc: s/Google Hangouts/Zoom --- GOVERNANCE.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 0c8add6..90c93b0 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -14,7 +14,7 @@ Collaborators and given commit-access to the project. ### Team Meetings -The Team meets bi-weekly on a Google Hangout On Air. A designated moderator +The Team meets bi-weekly on Zoom.us. A designated moderator approved by the Team runs the meeting. Each meeting should be published to YouTube. From 2b52e8566367485e8a4f371132b2808656d0d58e Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Wed, 28 Feb 2018 15:36:22 -0500 Subject: [PATCH 016/226] doc: use ncu-team sync to sync member list --- README.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/README.md b/README.md index 01ef651..59d49e0 100644 --- a/README.md +++ b/README.md @@ -25,6 +25,7 @@ Work includes: - [@ceejbot](https://github.com/ceejbot) - C J Silverio - [@chrisdickinson](https://github.com/chrisdickinson) - Chris Dickinson - [@DanielRosenwasser](https://github.com/DanielRosenwasser) - Daniel Rosenwasser +- [@dduleone](https://github.com/dduleone) - Dan DuLeone - [@devamaz](https://github.com/devamaz) - Ahmad Abdul-Aziz - [@devsnek](https://github.com/devsnek) - Gus Caplan - [@eugeneo](https://github.com/eugeneo) - Eugene Ostroukhov @@ -32,10 +33,12 @@ Work includes: - [@Fishrock123](https://github.com/Fishrock123) - Jeremiah Senkpiel - [@giltayar](https://github.com/giltayar) - Gil Tayar - [@guybedford](https://github.com/guybedford) - Guy Bedford +- [@iarna](https://github.com/iarna) - Rebecca Turner - [@inidaname](https://github.com/inidaname) - Hassan Sani - [@jasnell](https://github.com/jasnell) - James M Snell - [@jdalton](https://github.com/jdalton) - John-David Dalton - [@jkrems](https://github.com/jkrems) - Jan Olaf Krems +- [@justinfagnani](https://github.com/justinfagnani) - Justin Fagnani - [@linclark](https://github.com/linclark) - Lin Clark - [@ljharb](https://github.com/ljharb) - Jordan Harband - [@manekinekko](https://github.com/manekinekko) - Wassim Chegham @@ -45,8 +48,10 @@ Work includes: - [@MylesBorins](https://github.com/MylesBorins) - Myles Borins - [@refack](https://github.com/refack) - Refael Ackermann - [@robpalme](https://github.com/robpalme) - Rob Palmer +- [@robwormald](https://github.com/robwormald) - Rob Wormald - [@targos](https://github.com/targos) - Michaël Zasso - [@tbjers](https://github.com/tbjers) - Torgny Bjers +- [@tbranyen](https://github.com/tbranyen) - Tim Branyen - [@TimothyGu](https://github.com/TimothyGu) - Timothy Gu - [@WebReflection](https://github.com/WebReflection) - Andrea Giammarchi - [@weswigham](https://github.com/weswigham) - Wesley Wigham From dc5de2f9d07d81e5de2aa136bfebb4bedc232d4d Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Wed, 28 Feb 2018 16:25:12 -0500 Subject: [PATCH 017/226] doc: correct year for meeting note --- doc/meetings/{2017-02-14.md => 2018-02-14.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename doc/meetings/{2017-02-14.md => 2018-02-14.md} (100%) diff --git a/doc/meetings/2017-02-14.md b/doc/meetings/2018-02-14.md similarity index 100% rename from doc/meetings/2017-02-14.md rename to doc/meetings/2018-02-14.md From 198b66a77c977cdd4a5d65142cdab2a0fe5ce87f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Micha=C3=ABl=20Zasso?= Date: Fri, 2 Mar 2018 11:34:33 +0100 Subject: [PATCH 018/226] doc: editorial fixes to GOVERNANCE.md (#40) --- GOVERNANCE.md | 29 ++++++++++++++++++++++------- 1 file changed, 22 insertions(+), 7 deletions(-) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 90c93b0..22ecd85 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -29,9 +29,9 @@ group of Collaborators. Any community member or contributor can ask that something be added to the next meeting's agenda by logging a GitHub Issue. Any Collaborator, Team member or the moderator can add the item to the agenda by adding -the ***diag-agenda*** tag to the issue. +the ***modules-agenda*** tag to the issue. -Prior to each Team meeting the moderator will share the Agenda with +Prior to each Team meeting the moderator will share the agenda with members of the Team. Team members can add any items they like to the agenda at the beginning of each meeting. The moderator and the Team cannot veto or remove items. @@ -48,11 +48,11 @@ The Team follows a [Consensus Seeking](http://en.wikipedia.org/wiki/Consensus-seeking_decision-making) decision-making model. -When an agenda item has appeared to reach a consensus the moderator +When an agenda item has appeared to reach a consensus, the moderator will ask "Does anyone object?" as a final call for dissent from the consensus. -If an agenda item cannot reach a consensus a Team member can call for +If an agenda item cannot reach a consensus, a Team member can call for either a closing vote or a vote to table the issue to the next meeting. The call for a vote must be seconded by a majority of the Team or else the discussion will continue. Simple majority wins. @@ -62,13 +62,28 @@ Note that some changes to Team membership require unanimous consensus. See ### Merging PRs into this Repository -This section does not apply to [the Node.js core repository](https://github.com/nodejs/node). It only applied to [the Modules repository](https://github.com/nodejs/modules). +This section does not apply to [the Node.js core repository](https://github.com/nodejs/node). +It only applies to [the Modules repository](https://github.com/nodejs/modules). -Pull requests must reach consensus in a meeting in order to be merged into this repository. Merging of pull requests must be decided during a meeting that has a minimal quorum of 50% of all active members. Members with observer status are not considered active members for the purposes of reaching quorum. A pull request that is is unable to reach quorum due to lack of consensus or quorum must not be merged into this repository. Pull requests that fail to be merged will be addressed on a case by case basis. +Pull requests must reach consensus in a meeting in order to be merged into this +repository. Merging of pull requests must be decided during a meeting that has a +minimal quorum of 50% of all active members. Members with observer status are +not considered active members for the purposes of reaching quorum. A pull +request that is is unable to reach quorum due to lack of consensus or quorum +must not be merged into this repository. Pull requests that fail to be merged +will be addressed on a case by case basis. #### Errata and Editorial Changes -A special exception is made for pull requests seeking to fix errata or perform editorial changes to this repository. Errata or editorial pull requests may be merged without being presented at a meeting if a reasonable time is given for review and there no dissent. The time period seen as reasonable for review varies on a case by case basis as determined by the author. A member may request a specific time period for review of a errata or editorial pull request not to exceed the next meeting date. If a time for review is requested, members must wait for that time period to pass or review be completed prior to that time. +A special exception is made for pull requests seeking to fix errata or perform +editorial changes to this repository. Errata or editorial pull requests may be +merged without being presented at a meeting if a reasonable time is given for +review and there no dissent. The time period seen as reasonable for review +varies on a case by case basis as determined by the author. A member may +request a specific time period for review of an errata or editorial pull request +not to exceed the next meeting date. If a time for review is requested, members +must wait for that time period to pass or review be completed prior to that +time. ## Developer's Certificate of Origin 1.1 From af7d918e8d26a1320940037861389a8cd7e0cae9 Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Wed, 28 Feb 2018 16:23:38 -0500 Subject: [PATCH 019/226] doc: add meeting notes for 2018-02-28 --- doc/meetings/2018-02-28.md | 179 +++++++++++++++++++++++++++++++++++++ 1 file changed, 179 insertions(+) create mode 100644 doc/meetings/2018-02-28.md diff --git a/doc/meetings/2018-02-28.md b/doc/meetings/2018-02-28.md new file mode 100644 index 0000000..1b8e2b2 --- /dev/null +++ b/doc/meetings/2018-02-28.md @@ -0,0 +1,179 @@ +# Node.js Foundation Modules Team Meeting 2018-02-28 + +## Links + +* **Recording**: http://www.youtube.com/watch?v=PO07agjJ_1Y +* **GitHub Issue**: https://github.com/nodejs/modules/issues/36 +* **Minutes Google Doc**: https://docs.google.com/document/d/1ZA_0tK8ZKoo1Lh2kLl-DIckVnYb7rOV-ASjrsjEW3mI/edit + +## Present + +Myles Borins (@MylesBorins) +Wesley Wigham (@weswigham) +Bradley Farias (@bmeck) +C J Silverio (@ceejbot) +Torgny Bjers (@tbjers) +Dan DuLeone (@dduleone) +Lin Clark (@linclark) +Gil Tayar (@giltayar) +Gus Caplan (@devsnek) +Guy Bedford (@guybedford) +Rebecca Turner (@iarna) +Hassan Sani (@inidaname) +Matt DuLeone (@mduleone) +Chris Dickinson (@chrisdickinson) +Jeremiah Senkpiel (@Fishrock123) +Michael Zasso (@targos) +Benjamin Gruenbaum (@benjamingr) +Daniel Rosenwasser (@DanielRosenwasser) +Justin Fagnani (@justinfagnani) +Matteo Collina (@mcollina) +Ben Newman (@benjamn) +John-David Dalton (@jdalton) +Michael Dawson (@mhdawson) +Jan Krems (@jkrems) +Jordan Harband (@ljharb) + +## Agenda + +### Announcements + +* raising hands to talk (UI in participants list) +* could use someone to take notes +* post youtube link please + +### nodejs/modules + +* Online Module Summit [#9](https://github.com/nodejs/modules/issues/9) + - Target date: end of March, beginning of April, post-upcoming-TC39 - meeting + - Probably will be closer to UTC than other timezones. + - Fill the Doodle if you want to attend! + - You can suggest topics for discussion at the summit in the above issue. + +* doc: add meeting notes for Feb 14 2018 [#27](https://github.com/nodejs/modules/pull/27) + - Notes from the last meeting + - Any problems? + - Nope. + - Merged! + +* doc: move code of conduct to CODE_OF_CONDUCT.md [#29](https://github.com/nodejs/modules/pull/29) + - Moves Code of Conduct out of the Governance document. + - Objections? + - Nope. + - Merged! + +* Document quorum required in order to merge PRs [#26](https://github.com/nodejs/modules/pull/26) + - Outstanding block from James Snell + - Brad: background: wanted to seek quorum during meetings + - James felt that we shouldn’t need to wait for meetings to merge PRs. + - Could be okay to just wait for meetings to merge PRs given the small amount of time between meetings. + - Editorial & Errata changes probably okay - don’t need a meeting to merge those types of PRs in. + - Matteo: Can probably roll with this for now, but may want to revisit this to address James’ feedback. + - Brad: Clarifying question: can’t merge into node itself, or nodejs/modules? + - CJ: Hard part will be identifying consensus and documenting clearly. Any work that is done before that is work that will potentially have to be backed out. + - Myles: Have 3-4 items on agenda that will directly touch this; let’s move forward for now. + - Objections? + - Consensus, let’s merge it in. + +* doc: s/Google Hangouts/Zoom [#34](https://github.com/nodejs/modules/pull/34) + - Concerns? + - Silence + - Conclusion: Landed + +* Governance and Membership Requirements [#8](https://github.com/nodejs/modules/issues/8) + - At the end of the last meeting, we reached quorum/consensus that people who haven’t filled in the Doodle would be moved into observer status. + - Some individuals felt that this was not in the spirit of the Node foundation; potentially a pre-optimization for a problem that hasn’t occurred. + - Request to keep people around who didn’t get the chance to fill out the Doodle last time. + - Perhaps we want to just keep everyone as members until we actually hit a problem? + - Wesley: what percentage is quorum? + - 1 person above 50% of total membership + - But we only have the exact quorum of people here today + - Actually we have 26! + - We had 21 just a few minutes ago + - That’s indeed why we had a concern originally. + - Anyone who’s observer status: anyone have an objection to having been moved over? + - LJHarb: may need a more comprehensive criteria of participation; lots of anxiety about what engagement means given other obligations. + - Brad: Quorum PR had a timeline for how quickly PRs can be merged in; potentially should address concerns of participation? + - Myles: proposal so that people moved to observer status can request to be moved back to participators + - Jan: idea of moving people to observer status and then making them go through a process seems unnecessary + - MichaelD: Either reverse or send an email to the list with the request to renew membership + - Hassan: process was confusing, we need a more agreeable standard to move people to observer status + - Myles: would like to move people from observer status back to participants, figure out what to do when we actually hit a problem with quorum. + - Objections? + - None + - Proceed. + +* maintain a summary document/website [#35](https://github.com/nodejs/modules/issues/35) + - Let’s timebox to 5 minutes? + - Gus C: community as a whole seems pretty disengaged from what’s going on, hard for people to keep track of node eps + - Want to keep the community informed about where things stand here. + - Brad: Originally tried to use a wiki for this, became a dumping ground for different interop ideas. Without a known state of things, does it make sense to explain the current state of things? + - tbranyen: would be helpful to have an FAQ-style list to explain how things get to where they are. + - Brad: will probably be months before we want to put anything on the website + - Myles: does it make sense to at least start thinking about where the site will live/what it will look like/what the copy will be like? + - Matteo: There’s definitely a need in the community to understand why things are the way which they are. + - Rebecca: When we come to consensus on things, that’s probably the appropriate time to add it to this document. + - Myles: maybe add something to document things like knowns, known unknowns, etc. + - Gil: this sort of thing may slow us down + - Wesley: context for why things are the way they are may be more important than just how things are. + - Jeremiah: high level objectives might be good to put into that document. + - Conclusion: kick it back to the repo, bring it up in the next meeting + +* Scope of team [#17](https://github.com/nodejs/modules/issues/17) +* Guiding Design Principles [#11](https://github.com/nodejs/modules/issues/11) +* initial GOALS declaration [#23](https://github.com/nodejs/modules/pull/23) + - CJ: request a reset of the goals document + - Would like the group to back up and take a more user-centric approach + - List use-cases we want to support with ESM, with interop, and more. + - Allows us to focus on the problem: how will Node users write with ES modules to write JS programs. + - Implementations will fall out more easily given the use-cases we want to support. + - Matteo: there is a spec which gives Node leeway, but a lot of behavior is dictated by the spec. + - Can end up with Babel modules if we just go against the spec. + - Brad + - When we talk about “user-centric” goals, agree; we should remove any goals that are driven by implementation-details. + - Would also like not to talk purely about how CommonJS works. + - Have to think about how the web browsers work; we can’t dictate how browsers will work. + - LJHarb + - use-cases are best way to explain why we are making the decisions which we are. + - Use-cases are also what motivated current implementation; see this as less of a reset, more of a review + - CJ: spec is a living document; spec shapes how we implement, but if we find a place where the spec is incompatible with the use-cases we have in mind, we should bring that to TC39 to explain how ECMA-262 is not allowing Node to provide those use-cases + - Jan: use-cases can be motivated by how Node users use CommonJS today + - Justin F: want to bring web perspective, think more about ergonomics about modules on the web, use this as a way to provide feedback to bring a solid experience to both ecosystems + +### nodejs/node + +* esm: Implement esm mode flag [#18392](https://github.com/nodejs/node/pull/18392) + - https://docs.google.com/presentation/d/1xK1ana_TIxfAHX33CYVHFnJsV0If_YirLtRBBga9cv0/edit?usp=sharing + - Builds on proposal of using .mjs a differentiator as well as wykatz’s “In Defense of .js” + - Introduces a ‘module’ field to package.json + - Problems with module field: Most build tools will use ambiguous syntax detection mechanisms in conjunction with the ‘module’ field. + - Idea: for a .js file, walk up to a package.json, see if it has “mode”: “esm”, treat it as an ES module if so. + - Pros + - Enables .js in Node for ES modules + - Provides relatively simple interop in the ecosystem + - Packages can upgrade to ES Modules as a non-breaking change. + - Build tools already work similarly; integrating with that would be ideal + - Myles + - bring questions/comments/concerns to the PR itself + - How do we want to interact with PRs in core itself? + - Rebecca + - Should discourage any module-related work in core. + - Would feel bad for contributors if any work was overridden. + - Brad + - Have spent >4 years working on this; expect wasted work + - With an implementation, we can see implementation problems themselves. + - So don’t want to stop ongoing work + - Myles: will open issue to discuss ways to deal with conflict within the group + - Guy + - keep in mind, things that might be considered a reset might actually be fairly small changes in practice + - Also: please look at PR! Can be merged in, but lacks critical feedback currently. + +## Q&A, Other + +* Did not have time to do Q/A + +## Upcoming Meetings + +* **Node.js Foundation Calendar**: https://nodejs.org/calendar + +Click `+GoogleCalendar` at the bottom right to add to your own Google calendar. From 31dc5be41f624cf04fb40c8c10d83c2b5ee27ccf Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Wed, 28 Mar 2018 16:07:07 -0400 Subject: [PATCH 020/226] doc: add meeting notes for 2018-03-28 --- doc/meetings/2018-03-28.md | 69 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 69 insertions(+) create mode 100644 doc/meetings/2018-03-28.md diff --git a/doc/meetings/2018-03-28.md b/doc/meetings/2018-03-28.md new file mode 100644 index 0000000..0904b99 --- /dev/null +++ b/doc/meetings/2018-03-28.md @@ -0,0 +1,69 @@ +# Node.js Foundation Modules Team Meeting 2018-03-28 + +* **Recording**: https://www.youtube.com/watch?v=moQDM4Jy09s +* **GitHub Issue**: https://github.com/nodejs/modules/issues/52 +* **Minutes Google Doc**: https://docs.google.com/document/d/1w2BV_O-ZzNupIthznKwAdA_wgOiDSD-kcZZ819bjNsE + + +## Present + +@MylesBorins (Myles Borins) +@TimothyGu +@ceejbot (C J Silverio) +@iarna (Rebecca Turner) +@justinfagnani (Justin Fagnani) +@linclark (Lin Clark) +@tbjers (Torgny Bjers) +@inidaname (Hassan Sani) +@jdalton (John-David Dalton) +@devsnek (Gus Caplan) +@manekinekko (Wassim Chegham) +@benjamn (Ben Newman) +@bmeck (Bradley Farias) +@weswigham (Wesley Wigham) + +## Agenda + +Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. + +### Approving PRs ~ 1 minute timebox + +* doc: add meeting notes for 2018-03-14 [#50](https://github.com/nodejs/modules/pull/50) + - make pr to update rules around meeting notes + +### For awareness ~ 3 minute timebox per item + +#### PRs against Core + +* module: fix `e.stack` error when throwing undefined or null [#19282](https://github.com/nodejs/node/pull/19282) +* loader: allow importing wasm modules [#18972](https://github.com/nodejs/node/pull/18972) + +#### Announcements + +* Travel Fund Available for Team Members to Attend Collaborator Summit in Berlin May 31 - June 1 [#48](https://github.com/nodejs/modules/issues/48) +* Online Module Summit ~ April 3rd [#9](https://github.com/nodejs/modules/issues/9) + +### Discussion + +* Membership requirements [#43](https://github.com/nodejs/modules/issues/43) + - 10 minute timebox + - What should we do to make sure that we are able to maintain quorum + - Is Observer sufficient + - Punting to next week when more people are around +* Package-Name-Maps a proposal for bare imports in browsers [#51](https://github.com/nodejs/modules/issues/51) + - 10 minute timebox + - Presentation from Justin + - Work done internally at Google with a number of stakeholders + - trying to figure out how to get bare module specifiers working in the browser + - currently you need to use the full path to the file. + - arguably works right now if you are not publishing packages, but it doesn’t scale + - proposal https://github.com/domenic/package-name-maps + - package name maps supports scopes as a way to customize names -> maps + - you can override for specific urls + - currently mechanism to declare your package map is a script tag, inlined or external file + - question about if this is sidestepping the need for “loader hooks” +* Use Cases Meeting [#41](https://github.com/nodejs/modules/issues/41) + - 25 minute timebox + - https://docs.google.com/document/d/10BBsIqdAXB9JR2KUzQGYbCiVugYBnxE4REBakX29yyo/edit#heading=h.osxlcsy402fz + - reviewed Justin’s use Cases + - reviewed Rob’s use cases From 2cc6264cf4d9d1a50777f7d36ded7e11955e577e Mon Sep 17 00:00:00 2001 From: Timothy Gu Date: Wed, 28 Mar 2018 13:08:31 -0700 Subject: [PATCH 021/226] Add my name --- doc/meetings/2018-03-28.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/meetings/2018-03-28.md b/doc/meetings/2018-03-28.md index 0904b99..c7ef3e6 100644 --- a/doc/meetings/2018-03-28.md +++ b/doc/meetings/2018-03-28.md @@ -8,7 +8,7 @@ ## Present @MylesBorins (Myles Borins) -@TimothyGu +@TimothyGu (Timothy Gu) @ceejbot (C J Silverio) @iarna (Rebecca Turner) @justinfagnani (Justin Fagnani) From 9f514722a07b78fec094ce0323c92d31e3bf9653 Mon Sep 17 00:00:00 2001 From: Rob Palmer Date: Thu, 29 Mar 2018 08:59:58 +0100 Subject: [PATCH 022/226] Add attendee name --- doc/meetings/2018-03-28.md | 1 + 1 file changed, 1 insertion(+) diff --git a/doc/meetings/2018-03-28.md b/doc/meetings/2018-03-28.md index c7ef3e6..7c09950 100644 --- a/doc/meetings/2018-03-28.md +++ b/doc/meetings/2018-03-28.md @@ -21,6 +21,7 @@ @benjamn (Ben Newman) @bmeck (Bradley Farias) @weswigham (Wesley Wigham) +@robpalme (Rob Palmer) ## Agenda From 1faee5ef5e9d6a4f243de6b204ee665c05e608a0 Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Tue, 3 Apr 2018 00:00:39 -0400 Subject: [PATCH 023/226] doc: update members list * sync with with ncu-team sync \#31 should have added @thelarkinn to the members list. It was closed for unrelated reasons but we never got Sean on the list. * s/Modules Team Members/Members * remove hyperlink from "Members" header The original hyperlink lead to: https://github.com/orgs/nodejs/teams/modules/members Which is only accessible to people in the Node.js org afaict. The member list is in the doc, the link is likely to just confuse folks. * update ncu-team meta data It now can inline Members and Observers. This is connected to the ACL in github. The Observers header is currently commented out. * fix link in governance to membership list --- GOVERNANCE.md | 2 +- README.md | 15 +++++++++++---- 2 files changed, 12 insertions(+), 5 deletions(-) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 22ecd85..ecb82fb 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -1,7 +1,7 @@ ### Modules Team For the current list of Team members, see the project -[README.md](./README.md#current-project-team-members). +[README.md](./README.md#members). ### Collaborators diff --git a/README.md b/README.md index 59d49e0..7f18785 100644 --- a/README.md +++ b/README.md @@ -13,11 +13,10 @@ Work includes: * Node.js and Browser interoperability * VM Modules implementation -## Modules [Team Members](https://github.com/orgs/nodejs/teams/modules/members) +## Members - + -- [@abouthiroppy](https://github.com/abouthiroppy) - Yuta Hiroto - [@benjamingr](https://github.com/benjamingr) - Benjamin Gruenbaum - [@benjamn](https://github.com/benjamn) - Ben Newman - [@bmeck](https://github.com/bmeck) - Bradley Meck @@ -33,6 +32,7 @@ Work includes: - [@Fishrock123](https://github.com/Fishrock123) - Jeremiah Senkpiel - [@giltayar](https://github.com/giltayar) - Gil Tayar - [@guybedford](https://github.com/guybedford) - Guy Bedford +- [@hiroppy](https://github.com/hiroppy) - Yuta Hiroto - [@iarna](https://github.com/iarna) - Rebecca Turner - [@inidaname](https://github.com/inidaname) - Hassan Sani - [@jasnell](https://github.com/jasnell) - James M Snell @@ -52,11 +52,18 @@ Work includes: - [@targos](https://github.com/targos) - Michaël Zasso - [@tbjers](https://github.com/tbjers) - Torgny Bjers - [@tbranyen](https://github.com/tbranyen) - Tim Branyen +- [@TheLarkInn](https://github.com/TheLarkInn) - Sean Larkin - [@TimothyGu](https://github.com/TimothyGu) - Timothy Gu - [@WebReflection](https://github.com/WebReflection) - Andrea Giammarchi - [@weswigham](https://github.com/weswigham) - Wesley Wigham - [@XadillaX](https://github.com/XadillaX) - Khaidi Chu - [@yosuke-furukawa](https://github.com/yosuke-furukawa) - Yosuke Furukawa -- [@zackschuster](https://github.com/zackschuster) - +- [@zackschuster](https://github.com/zackschuster) - Zack Schuster + + + + + + From 9f05b6b6f4b147eb9a55ede57188264b13899ccd Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Thu, 12 Apr 2018 10:54:06 -0400 Subject: [PATCH 024/226] doc: update membership list with ncu-team sync As per the discussion in the last meeting I have reached out to some members privately about moving to observer status. As people respond and opt-in to being moved to observers I am updating their status in the GitHub ACL. This PR will remain open until the next meeting so that we can avoid multiple PRs. If anyone would like to be include in the list of people being moved from Active-Member to Observer please comment in this thread and I'll take care of that. I wanted to thank all those included in this PR for their hard work and willingness to move to be Observers. I hope that you all continue to participate in the repo and attend meetings when it is convenient. --- README.md | 33 +++++++++++++++++---------------- 1 file changed, 17 insertions(+), 16 deletions(-) diff --git a/README.md b/README.md index 7f18785..d02b83a 100644 --- a/README.md +++ b/README.md @@ -15,27 +15,20 @@ Work includes: ## Members - + - [@benjamingr](https://github.com/benjamingr) - Benjamin Gruenbaum - [@benjamn](https://github.com/benjamn) - Ben Newman - [@bmeck](https://github.com/bmeck) - Bradley Meck -- [@bmeurer](https://github.com/bmeurer) - Benedikt Meurer - [@ceejbot](https://github.com/ceejbot) - C J Silverio - [@chrisdickinson](https://github.com/chrisdickinson) - Chris Dickinson - [@DanielRosenwasser](https://github.com/DanielRosenwasser) - Daniel Rosenwasser -- [@dduleone](https://github.com/dduleone) - Dan DuLeone -- [@devamaz](https://github.com/devamaz) - Ahmad Abdul-Aziz - [@devsnek](https://github.com/devsnek) - Gus Caplan -- [@eugeneo](https://github.com/eugeneo) - Eugene Ostroukhov -- [@evanplaice](https://github.com/evanplaice) - Evan Plaice - [@Fishrock123](https://github.com/Fishrock123) - Jeremiah Senkpiel - [@giltayar](https://github.com/giltayar) - Gil Tayar - [@guybedford](https://github.com/guybedford) - Guy Bedford -- [@hiroppy](https://github.com/hiroppy) - Yuta Hiroto - [@iarna](https://github.com/iarna) - Rebecca Turner - [@inidaname](https://github.com/inidaname) - Hassan Sani -- [@jasnell](https://github.com/jasnell) - James M Snell - [@jdalton](https://github.com/jdalton) - John-David Dalton - [@jkrems](https://github.com/jkrems) - Jan Olaf Krems - [@justinfagnani](https://github.com/justinfagnani) - Justin Fagnani @@ -46,24 +39,32 @@ Work includes: - [@mduleone](https://github.com/mduleone) - Matt DuLeone - [@mhdawson](https://github.com/mhdawson) - Michael Dawson - [@MylesBorins](https://github.com/MylesBorins) - Myles Borins -- [@refack](https://github.com/refack) - Refael Ackermann - [@robpalme](https://github.com/robpalme) - Rob Palmer -- [@robwormald](https://github.com/robwormald) - Rob Wormald - [@targos](https://github.com/targos) - Michaël Zasso - [@tbjers](https://github.com/tbjers) - Torgny Bjers -- [@tbranyen](https://github.com/tbranyen) - Tim Branyen -- [@TheLarkInn](https://github.com/TheLarkInn) - Sean Larkin - [@TimothyGu](https://github.com/TimothyGu) - Timothy Gu -- [@WebReflection](https://github.com/WebReflection) - Andrea Giammarchi - [@weswigham](https://github.com/weswigham) - Wesley Wigham - [@XadillaX](https://github.com/XadillaX) - Khaidi Chu -- [@yosuke-furukawa](https://github.com/yosuke-furukawa) - Yosuke Furukawa -- [@zackschuster](https://github.com/zackschuster) - Zack Schuster - +## Observers +- [@bmeurer](https://github.com/bmeurer) - Benedikt Meurer +- [@dduleone](https://github.com/dduleone) - Dan DuLeone +- [@devamaz](https://github.com/devamaz) - Ahmad Abdul-Aziz +- [@eugeneo](https://github.com/eugeneo) - Eugene Ostroukhov +- [@evanplaice](https://github.com/evanplaice) - Evan Plaice +- [@hiroppy](https://github.com/hiroppy) - Yuta Hiroto +- [@jasnell](https://github.com/jasnell) - James M Snell +- [@refack](https://github.com/refack) - Refael Ackermann +- [@robwormald](https://github.com/robwormald) - Rob Wormald +- [@tbranyen](https://github.com/tbranyen) - Tim Branyen +- [@TheLarkInn](https://github.com/TheLarkInn) - Sean Larkin +- [@WebReflection](https://github.com/WebReflection) - Andrea Giammarchi +- [@yosuke-furukawa](https://github.com/yosuke-furukawa) - Yosuke Furukawa +- [@zackschuster](https://github.com/zackschuster) - Zack Schuster + From cd906e8e1513dbee5216c3135589f4af52807d28 Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Thu, 12 Apr 2018 01:50:33 -0400 Subject: [PATCH 025/226] doc: add meeting notes for 2018-04-11 --- doc/meetings/2018-04-11.md | 75 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 75 insertions(+) create mode 100644 doc/meetings/2018-04-11.md diff --git a/doc/meetings/2018-04-11.md b/doc/meetings/2018-04-11.md new file mode 100644 index 0000000..ffe33c9 --- /dev/null +++ b/doc/meetings/2018-04-11.md @@ -0,0 +1,75 @@ +# Node.js Foundation Modules Team Meeting 2018-04-11 + +* **Recording**: +* **GitHub Issue**: https://github.com/nodejs/modules/issues/61 +* **Minutes Google Doc**: https://docs.google.com/document/d/1qS0_Cwfgy3hw_dOuRoiEtMtdL_QrWPcFJQrRQrXth6M/ + +## Present + +@benjamingr - Benjamin Gruenbaum +@MylesBorins - Myles Borins +@mhdawson - Michael Dawson +@mduleone - Matt DuLeone +@tbjers - Torgny Bjers +@bmeck - Bradley Farias +@guybedford - Guy Bedford +@devsnek - Gus Caplan +@robpalme - Rob Palmer +@jdalton - John-David Dalton +@weswigham - Wesley Wigham +@targos - Michael Zasso +@iarna - Rebecca Turner +@ljharb - Jordan Harband +@benjamn - Ben Newman +@fishrock Jeremiah Senkpiel + +## Agenda + +Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. + +### Approving PRs + +* doc: add meeting notes for 2018-03-28 [#53](https://github.com/nodejs/modules/pull/53) + - 1 minute timebox +* doc: add meeting notes for 2018-03-14 [#50](https://github.com/nodejs/modules/pull/50) + - 1 minute timebox + +* Expand and Refine Membership rules [#59](https://github.com/nodejs/modules/pull/59) + - 5 minute timebox + +* Don’t have quorum so cannot approve. Myles provided overview of PR to change membership rules. Need more people to approve, no objections from those in the meeting. + +### Discussion + +* Can I be an observer? [#56](https://github.com/nodejs/modules/issues/56) + - 3 minute Timebox + - Ask to open PR to add himself and we’ll get quorum there, unless enough people join such that we have quorum in the meeting. +* Cache system mismatch with web [#62](https://github.com/nodejs/modules/issues/62) + - Bradley provide a brief summary of the issue. Difference between caching related to + modules with indirect links. We need to decide if we want to be more compatible with + web versus what it does today. Would remove support for some use cases if we move + toward web compatibility. + - JDD, may allow addition of fragment to make it closer to what Node.js does + - Rebecca Turner, added context about how symlinks are used. Concern is where + some modules have behaviour enabled and others don’t. May need to diverge from + web behaviour due to our legacy behaviour. + - Bradley, would make things better,but still cannot could on unique key + - If import.meta no ok for our use case, what about adding a new meta (path?) + - Bradley, we probably need a new meta to support some use cases. Seconded Rebecca’s + comment as ecosystem is not well prepared to handle breaking existing Node.js usage. + - Myles +1 on adding new meta if needed for our use case, as opposed to trying to fit + with Meta.import.url if that does not fit. Myles should we setup meeting with those working + on standards to discuss? No objections -> yes. +* Use Cases (Tracking Issue) [#55](https://github.com/nodejs/modules/issues/55) + - 35 minute timebox + - doc for use cases + - LJHarb took us through a number of the cases here: https://docs.google.com/document/d/10BBsIqdAXB9JR2KUzQGYbCiVugYBnxE4REBakX29yyo/edit + - Rebecca we should number them to allow easy reference. + - John to open Issue/PR to capture move to the next step. + + * Feature discussion based on use cases + * discussed and captured here: https://docs.google.com/document/d/1HuH5E1d_mNuziBxPDRZVjpdfmUPhqVg0MUUcYDnqwn8/edit + + +* Membership requirements [#43](https://github.com/nodejs/modules/issues/43) + - Short discussion From 36f34d21ea6813263da42b7860e79af32f4542a8 Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Thu, 15 Mar 2018 02:20:58 -0400 Subject: [PATCH 026/226] doc: add meeting notes for 2018-03-14 closes: https://github.com/nodejs/modules/issues/47 refs: https://www.youtube.com/watch?v=U9xG4JPdznA refs: https://docs.google.com/document/d/1fwQ_XkYyJO3p5fE2o9H9i7iWii0LB4OyQxepBlaa6-Y/edit --- doc/meetings/2018-03-14.md | 119 +++++++++++++++++++++++++++++++++++++ 1 file changed, 119 insertions(+) create mode 100644 doc/meetings/2018-03-14.md diff --git a/doc/meetings/2018-03-14.md b/doc/meetings/2018-03-14.md new file mode 100644 index 0000000..b4ce3d7 --- /dev/null +++ b/doc/meetings/2018-03-14.md @@ -0,0 +1,119 @@ +# Node.js Foundation Modules Team Meeting 2018-03-14 + +* **Recording**: https://www.youtube.com/watch?v=U9xG4JPdznA +* **GitHub Issue**: https://github.com/nodejs/modules/issues/47 +* **Minutes Google Doc**: https://docs.google.com/document/d/1fwQ_XkYyJO3p5fE2o9H9i7iWii0LB4OyQxepBlaa6-Y/edit + +## Present + +Chris Dickinson (@chrisdickinson) +Myles Borins (@MylesBorins) +Wesley Wigham (@weswigham) +Michael Zasso (@targos) +Gus Caplan (@devsnek) +Gil Tayar (@giltayar) +C J Silverio (@ceejbot) +Torgny Bjers (@tbjers) +Matt DuLeone (@mduleone) +Benjamin Gruenbaum (@benajingr) +Daniel Rosenwasser (@DanielRosenwasser) +John-David Dalton (@jdalton) +Rebecca Turner (@iarna) +Lin Clark (@linclark) +Guy Bedford (@guybedford) +Bradley Farias (@bfarias) +Jordan Harband (@ljharb) +Hassan Sani (@inidaname) +Justin Fagnani (@justinfagnani) +Ben Newman (@benjamn) +Jeremiah Senkpiel (@Fishrock123) +Jan Olaf Krems (@jkrems) + +## Agenda + +Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. + + +### nodejs/modules + +#### Approving PRs ~ 1 minute timebox + +* doc: add meeting notes for 2018-02-28 [#38](https://github.com/nodejs/modules/pull/38) + * No objections! + +#### For awareness ~ 3 minute timebox + +* doc: add MANIFESTO.md [#45](https://github.com/nodejs/modules/pull/45) + * Remove stuff relating to implementation. + * Should occur later today. + * Please look over this! + +* Use Cases Meeting [#41](https://github.com/nodejs/modules/issues/41) + * Brad created a forum to discuss different use-cases. + * Pattern in GitHub discussions to go in-depth into use-cases. + * Maybe someone else should run that. + * Please chime in if you're interested. + * We have time to discuss that today. + +* Online Module Summit [#9](https://github.com/nodejs/modules/issues/9) + * Had a doodle open for several weeks - decided it will be on the April 3rd. + * Schedule should be out around Wednesday next week. + +### Discussion + +* Upstream changes to ESM in nodejs/node [#42](https://github.com/nodejs/modules/issues/42) + * Bradley: is there anything controversial around vm.module? + * JDD, Wesley, DanielR, CJ: Seconding notion that avoiding new functionality that is user-facing seems reasonable + * Named exports: any objections? + * Bradley: We just said we wanted to avoid user-facing functionality, but that's user-facing functionality. + * Wesley: We are concerned over named exports being a general mechanism beyond Node's core modules. + * Jeremiah: \[\[follow-up, something about get-accessors]] + * Rebeca: Will have to address things on a case-by-case basis + * Jordan: concerned with anything going forward that can leak into the package ecosystem; should have a lot of caution around what we do. + * Gil: Instead of setting up principles, maybe we should just decide things on a case-by-case basis. + * Myles: want "push over pull" - hard to make people keep up to date on everything. + +* Use Cases for ESM in Node.js + * CJ + * https://gist.github.com/ceejbot/d8703c71dd5cfba4ba93e755371e96e7 + * Use-cases that explicitly have no implementation detail in mind. + * Jeremiah + * How large do you imagine this list getting? + * Bradley + * I like the list, but I want to see adjustments about how the use-cases are fulfilled. + * Perhaps things are too specific? e.g. code coverage is achieved, maybe not necessarily via a loader hook + * Daniel: don't be too afraid of the length of the list until it becomes a problem + * Jan: What about existing direction around code-coverage? + * CJ: V8's code coverage functionality is speculative at this point; not clear that it satisfies all the use-cases people have in mind. + * Bradley: keep language in mind! We didn't say anything disparaging just now, but be respectful of others' efforts. + * Guy: as someone who's worked with/on transpilers as first-class citizens, I do wonder whether the use-case is worthwhile. + * It'll probably be done in some form, but is it worth listing? + * Justin: should probably consider it a use-case, not clear if it should be discouraged, but compat concern is a valid one. + * Daniel: even if we feel like it's not a valid scenario, we should consider them as use-cases if people are doing it today + * Wesley: ESM should not be seen as an opportunity to start again + * Ben: Keep in mind other module formats beyond CJS + * Chris: Easy to try to "editorialize" what we want to do, but it's worth reviewing the use-cases after thinking them through. + * Jan: We're considering what people do today, but what about what people will *want* to do in the future? + * Myles: Please fill up that form with use-cases and we can iterate! + * Maybe a Google Doc (I swear I'm not trying to sell everyone on using Google Docs!) would be easier to iterate on than on GitHub issues? + +* WASM/ES Module integration (Lin Clark) + * (hopefully I've done this presentation justice! - @DanielRosenwasser) + * Would like users to be able to use import/export .wasm files from .js files. + * Importing & exporting ESM declarations reference the same memory locations. + * Steps in typical ESM + * Construction: fetch module files, turn them into module records, recursively fetch dependencies (\[\[RequestedModules]]), do the same. + * Instantiation: + * Depth-first post-order traversal. + * Module environment records will be created if necessary + * Evaluation + * Bindings are linked together; for variables, set to 'undefined' until set by the respective exporting module. + * How would this work in WASM? + * Similar steps + * What about cyclic dependencies? + * Live bindings may not work because these values need to be set to undefined, but wasm only sees numeric values. + * May have to work with TC39 to just remove cyclical import restriction for non-JS module dependencies. + * Difficult to do eager construction (e.g. bundling) + * Need to figure this out. + * Bradley: Problems with live bindings importing from JS? + From 250cd08f2ca53ab1553de9b9b9e8628967d6825d Mon Sep 17 00:00:00 2001 From: Gus Caplan Date: Fri, 23 Mar 2018 08:42:44 -0500 Subject: [PATCH 027/226] fix formatting of attendees list --- doc/meetings/2018-03-14.md | 42 +++++++++++++++++++------------------- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/doc/meetings/2018-03-14.md b/doc/meetings/2018-03-14.md index b4ce3d7..7e10c9e 100644 --- a/doc/meetings/2018-03-14.md +++ b/doc/meetings/2018-03-14.md @@ -6,27 +6,27 @@ ## Present -Chris Dickinson (@chrisdickinson) -Myles Borins (@MylesBorins) -Wesley Wigham (@weswigham) -Michael Zasso (@targos) -Gus Caplan (@devsnek) -Gil Tayar (@giltayar) -C J Silverio (@ceejbot) -Torgny Bjers (@tbjers) -Matt DuLeone (@mduleone) -Benjamin Gruenbaum (@benajingr) -Daniel Rosenwasser (@DanielRosenwasser) -John-David Dalton (@jdalton) -Rebecca Turner (@iarna) -Lin Clark (@linclark) -Guy Bedford (@guybedford) -Bradley Farias (@bfarias) -Jordan Harband (@ljharb) -Hassan Sani (@inidaname) -Justin Fagnani (@justinfagnani) -Ben Newman (@benjamn) -Jeremiah Senkpiel (@Fishrock123) +Chris Dickinson (@chrisdickinson) +Myles Borins (@MylesBorins) +Wesley Wigham (@weswigham) +Michael Zasso (@targos) +Gus Caplan (@devsnek) +Gil Tayar (@giltayar) +C J Silverio (@ceejbot) +Torgny Bjers (@tbjers) +Matt DuLeone (@mduleone) +Benjamin Gruenbaum (@benajingr) +Daniel Rosenwasser (@DanielRosenwasser) +John-David Dalton (@jdalton) +Rebecca Turner (@iarna) +Lin Clark (@linclark) +Guy Bedford (@guybedford) +Bradley Farias (@bfarias) +Jordan Harband (@ljharb) +Hassan Sani (@inidaname) +Justin Fagnani (@justinfagnani) +Ben Newman (@benjamn) +Jeremiah Senkpiel (@Fishrock123) Jan Olaf Krems (@jkrems) ## Agenda From 7e81d719238e50dcd8cb814bcdc67eacf7b95415 Mon Sep 17 00:00:00 2001 From: Gus Caplan Date: Wed, 25 Apr 2018 14:08:54 -0500 Subject: [PATCH 028/226] fix newlines in attendence list --- doc/meetings/2018-03-28.md | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/doc/meetings/2018-03-28.md b/doc/meetings/2018-03-28.md index 7c09950..604b19d 100644 --- a/doc/meetings/2018-03-28.md +++ b/doc/meetings/2018-03-28.md @@ -7,20 +7,20 @@ ## Present -@MylesBorins (Myles Borins) -@TimothyGu (Timothy Gu) -@ceejbot (C J Silverio) -@iarna (Rebecca Turner) -@justinfagnani (Justin Fagnani) -@linclark (Lin Clark) -@tbjers (Torgny Bjers) -@inidaname (Hassan Sani) -@jdalton (John-David Dalton) -@devsnek (Gus Caplan) -@manekinekko (Wassim Chegham) -@benjamn (Ben Newman) -@bmeck (Bradley Farias) -@weswigham (Wesley Wigham) +@MylesBorins (Myles Borins) +@TimothyGu (Timothy Gu) +@ceejbot (C J Silverio) +@iarna (Rebecca Turner) +@justinfagnani (Justin Fagnani) +@linclark (Lin Clark) +@tbjers (Torgny Bjers) +@inidaname (Hassan Sani) +@jdalton (John-David Dalton) +@devsnek (Gus Caplan) +@manekinekko (Wassim Chegham) +@benjamn (Ben Newman) +@bmeck (Bradley Farias) +@weswigham (Wesley Wigham) @robpalme (Rob Palmer) ## Agenda From 811e3a38f059e752f2110a4b9643571cfcde1580 Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Tue, 3 Apr 2018 00:47:54 -0400 Subject: [PATCH 029/226] doc: clean up rules around quorum --- GOVERNANCE.md | 17 +++++++---------- 1 file changed, 7 insertions(+), 10 deletions(-) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index ecb82fb..658eefa 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -39,6 +39,9 @@ cannot veto or remove items. The Team may invite persons or representatives from certain projects to participate in a non-voting capacity. +Decisions in meetings are made via the [Consensus Seeking Process](#Consensus-Seeking-Process) +and require a quorum of 50% of Active Members. + The moderator is responsible for summarizing the discussion of each agenda item and sends it as a pull request after the meeting. @@ -55,10 +58,8 @@ consensus. If an agenda item cannot reach a consensus, a Team member can call for either a closing vote or a vote to table the issue to the next meeting. The call for a vote must be seconded by a majority of the Team -or else the discussion will continue. Simple majority wins. - -Note that some changes to Team membership require unanimous consensus. See -"Team Membership" above. +or else the discussion will continue. Simple majority wins. Only Active +Members participate in a vote. ### Merging PRs into this Repository @@ -66,12 +67,8 @@ This section does not apply to [the Node.js core repository](https://github.com/ It only applies to [the Modules repository](https://github.com/nodejs/modules). Pull requests must reach consensus in a meeting in order to be merged into this -repository. Merging of pull requests must be decided during a meeting that has a -minimal quorum of 50% of all active members. Members with observer status are -not considered active members for the purposes of reaching quorum. A pull -request that is is unable to reach quorum due to lack of consensus or quorum -must not be merged into this repository. Pull requests that fail to be merged -will be addressed on a case by case basis. +repository. A pull request that is is unable to reach consensus cannot be merged +into this repository. #### Errata and Editorial Changes From b196188386391fb9b0bcc737270de1b9642df090 Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Tue, 3 Apr 2018 00:32:55 -0400 Subject: [PATCH 030/226] doc: update membership rules * Introduce Membership Types - Active Member - Observer * Define roles * Define process for applying for membership * Define process for changing membership status --- GOVERNANCE.md | 54 ++++++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 45 insertions(+), 9 deletions(-) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 658eefa..3d68e6e 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -1,16 +1,52 @@ ### Modules Team For the current list of Team members, see the project -[README.md](./README.md#members). +[README.md](./README.md). -### Collaborators +### Members The [nodejs/modules](https://github.com/nodejs/modules) GitHub -repository is maintained by the Team and additional Collaborators who are added -by the Team on an ongoing basis. +repository is maintained by the Team and additional Members who are +added on an ongoing basis. -Individuals making significant and valuable contributions are made -Collaborators and given commit-access to the project. +There are two types of Members: + +#### Active Members + +* Invited to all meetings +* Can participate in [consensus seeking process](#consensus-seeking-process) +* Counted towards quorum in [Team Meetings](#team-meetings) +* Participates in voting + +#### Observers + +* Invited to all meetings +* Can participate in [consensus seeking process](#consensus-seeking-process) +* Not counted towards quorum in [Team Meetings](#team-meetings) +* Cannot participate in voting + +## Team Membership + +Team Membership is not time-limited. There is no fixed size of the Team. + +There is no specific set of requirements or qualifications for Team Membership beyond these rules. + +Changes to Team membership should be proposed with a pull-request and labelled `modules-agenda` +to be included in the next [team meeting](#team-meetings). Decisions are made via the +[Consensus Seeking Process](#consensus-seeking-process). + +If a Team member is unable to attend a meeting where a planned membership decision is being made, +then their consent is assumed. + +New Members to the team are initially accepted as Observers. + +Observers can request to be made Active Members following the above process. + +Active Members requesting to be made Observers following the above process are automatically approved +by the Team and do not require consensus. + +Any Member requesting to be removed from the group following the above process are automatically approved +by the Team and do not require consensus. ### Team Meetings @@ -56,8 +92,8 @@ will ask "Does anyone object?" as a final call for dissent from the consensus. If an agenda item cannot reach a consensus, a Team member can call for -either a closing vote or a vote to table the issue to the next -meeting. The call for a vote must be seconded by a majority of the Team +the item to be decided by a vote or to table the issue to the next +meeting. In both cases the decision must be seconded by a majority of the Team or else the discussion will continue. Simple majority wins. Only Active Members participate in a vote. @@ -67,7 +103,7 @@ This section does not apply to [the Node.js core repository](https://github.com/ It only applies to [the Modules repository](https://github.com/nodejs/modules). Pull requests must reach consensus in a meeting in order to be merged into this -repository. A pull request that is is unable to reach consensus cannot be merged +repository. A pull request that is unable to reach consensus cannot be merged into this repository. #### Errata and Editorial Changes From 99ae0e13c0fdb34d5c9e25c06d73a08cde74faef Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Tue, 3 Apr 2018 01:50:36 -0400 Subject: [PATCH 031/226] doc: fix headings in GOVERNANCE.md --- GOVERNANCE.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 3d68e6e..a5bc53e 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -1,9 +1,9 @@ -### Modules Team +# Modules Team For the current list of Team members, see the project [README.md](./README.md). -### Members +## Members The [nodejs/modules](https://github.com/nodejs/modules) GitHub repository is maintained by the Team and additional Members who are @@ -11,14 +11,14 @@ added on an ongoing basis. There are two types of Members: -#### Active Members +### Active Members * Invited to all meetings * Can participate in [consensus seeking process](#consensus-seeking-process) * Counted towards quorum in [Team Meetings](#team-meetings) * Participates in voting -#### Observers +### Observers * Invited to all meetings * Can participate in [consensus seeking process](#consensus-seeking-process) @@ -48,7 +48,7 @@ by the Team and do not require consensus. Any Member requesting to be removed from the group following the above process are automatically approved by the Team and do not require consensus. -### Team Meetings +## Team Meetings The Team meets bi-weekly on Zoom.us. A designated moderator approved by the Team runs the meeting. Each meeting should be @@ -81,7 +81,7 @@ and require a quorum of 50% of Active Members. The moderator is responsible for summarizing the discussion of each agenda item and sends it as a pull request after the meeting. -### Consensus Seeking Process +## Consensus Seeking Process The Team follows a [Consensus Seeking](http://en.wikipedia.org/wiki/Consensus-seeking_decision-making) @@ -97,7 +97,7 @@ meeting. In both cases the decision must be seconded by a majority of the Team or else the discussion will continue. Simple majority wins. Only Active Members participate in a vote. -### Merging PRs into this Repository +## Merging PRs into this Repository This section does not apply to [the Node.js core repository](https://github.com/nodejs/node). It only applies to [the Modules repository](https://github.com/nodejs/modules). @@ -106,7 +106,7 @@ Pull requests must reach consensus in a meeting in order to be merged into this repository. A pull request that is unable to reach consensus cannot be merged into this repository. -#### Errata and Editorial Changes +### Errata and Editorial Changes A special exception is made for pull requests seeking to fix errata or perform editorial changes to this repository. Errata or editorial pull requests may be From 64295e51d84883540154481405d7daf9f371e7d4 Mon Sep 17 00:00:00 2001 From: Jeremiah Senkpiel Date: Wed, 25 Apr 2018 15:19:55 -0400 Subject: [PATCH 032/226] governance: introduce PR exemptions for minutes This changes the special PR merging exemption for Errata and Editorial changes to be a general "Special Exemptions to the PR landing process", which has been updated to include meeting minutes. This is done so as to not consume time in meetings approving minutes. PR-URL: https://github.com/nodejs/modules/pull/72 --- GOVERNANCE.md | 37 ++++++++++++++++++++++--------------- 1 file changed, 22 insertions(+), 15 deletions(-) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index a5bc53e..369ac6d 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -102,21 +102,28 @@ Members participate in a vote. This section does not apply to [the Node.js core repository](https://github.com/nodejs/node). It only applies to [the Modules repository](https://github.com/nodejs/modules). -Pull requests must reach consensus in a meeting in order to be merged into this -repository. A pull request that is unable to reach consensus cannot be merged -into this repository. - -### Errata and Editorial Changes - -A special exception is made for pull requests seeking to fix errata or perform -editorial changes to this repository. Errata or editorial pull requests may be -merged without being presented at a meeting if a reasonable time is given for -review and there no dissent. The time period seen as reasonable for review -varies on a case by case basis as determined by the author. A member may -request a specific time period for review of an errata or editorial pull request -not to exceed the next meeting date. If a time for review is requested, members -must wait for that time period to pass or review be completed prior to that -time. +Pull requests not included under the _special exemptions_ section below must +reach consensus in a meeting in order to be merged into this repository. A pull +request that is is unable to reach consensus cannot be merged into this +repository. + + +### Special Exemptions to the PR landing process + +Special exception is made for pull requests seeking to make any of the following +changes to this repository: + +- Errata fixes. +- Editorial changes. +- Meeting minutes. + +These pull requests may be merged without being presented at a meeting if a +reasonable time is given for review and there no dissent. The time period seen +as reasonable for review varies on a case by case basis as determined by the +author. A member may request a specific time period for review of such a pull +request not to exceed the next meeting date. If a time for review is requested, +members must wait for that time period to pass or review be completed prior to +that time. ## Developer's Certificate of Origin 1.1 From 2e250001a4e729724fa8a9760bdad6a48ccc559a Mon Sep 17 00:00:00 2001 From: Jeremiah Senkpiel Date: Wed, 25 Apr 2018 15:29:57 -0400 Subject: [PATCH 033/226] governance: add a PR exemption for ncu-sync Add updating the team lists in the readme via ncu-sync to the list of special exemptions for landing PRs. PR-URL: https://github.com/nodejs/modules/pull/72 --- GOVERNANCE.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 369ac6d..b741916 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -107,7 +107,6 @@ reach consensus in a meeting in order to be merged into this repository. A pull request that is is unable to reach consensus cannot be merged into this repository. - ### Special Exemptions to the PR landing process Special exception is made for pull requests seeking to make any of the following @@ -116,6 +115,7 @@ changes to this repository: - Errata fixes. - Editorial changes. - Meeting minutes. +- Updates to the team lists via the `ncu-sync` tool. These pull requests may be merged without being presented at a meeting if a reasonable time is given for review and there no dissent. The time period seen From 42a86efd8f9d4ed272eedb1a00f5c20cce89ca51 Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Fri, 27 Apr 2018 13:55:53 -0400 Subject: [PATCH 034/226] doc: add 2018-04-25 notes --- doc/meetings/2018-04-25.md | 103 +++++++++++++++++++++++++++++++++++++ 1 file changed, 103 insertions(+) create mode 100644 doc/meetings/2018-04-25.md diff --git a/doc/meetings/2018-04-25.md b/doc/meetings/2018-04-25.md new file mode 100644 index 0000000..e3609bf --- /dev/null +++ b/doc/meetings/2018-04-25.md @@ -0,0 +1,103 @@ +# Node.js Foundation Modules Team Meeting 2018-04-11 + +* **Recording**: https://www.youtube.com/watch?v=Qbgryil1hEY +* **GitHub Issue**: https://github.com/nodejs/modules/issues/71 +* **Minutes Google Doc**: https://docs.google.com/document/d/1bSH1eP_FFigXgsH9nPOhZUkrG51OzoIeNoZYReqlU8Y + +## Present + +@DanielRosenwasser - Daniel Rosenwasser +@weswigham - Wesley Wigham +@jdalton - John-David Dalton +@devsnek - Gus Caplan +@ljharb - Jordan Harband +@benjamingr - Benjamin Gruenbaum +@mduleone - Matt DuLeone +@Fishrock123 - Jeremiah Senkpiel +@tbjers - Torgny Bjers +@mhdawson - Michael Dawson +@MylesBorins - Myles Borins +@targos - Michael Zasso +@ceejbot C J Silverio +@smotaal - Saleh A Motaal +@jdalton – John-David Dalton +@giltayar - Gil Tayar +@guybedford - Guy Bedford +@xtuc - Sven Sauleau +@inidaname - Hassan Sani +@robpalme - Rob Palmer + +## Agenda + +Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. + +### Approving PRs (5 Minute Time Box) + +* doc: update membership list with ncu-team sync [#66](https://github.com/nodejs/modules/pull/66) + * Objections? + * None; rebased and merged + * Myles will take action item here + +* doc: add meeting notes for 2018-04-11 [#64](https://github.com/nodejs/modules/pull/64) + * No objections +* doc: add meeting notes for 2018-03-28 [#53](https://github.com/nodejs/modules/pull/53) + * Objections to landing based on formatting. + * Will land once formatting is fixed (no objections). + +* doc: add meeting notes for 2018-03-14 [#50](https://github.com/nodejs/modules/pull/50) + +* Expand and Refine Membership rules [#59](https://github.com/nodejs/modules/pull/59) + * Closes: Membership requirements [#43](https://github.com/nodejs/modules/issues/43) + * Makes an explicit definition between observers and active members + * Observers are not counted towards quorum requirements when seeking consensus + * Observers are still able to reject, but don't have a vote when seeking consensus towards quorum + * Objections? + * None. + +### Approving Observers (3 minute timebox) + +* Add Geoffrey (@GeoffreyBooth) as an observer [#56](https://github.com/nodejs/modules/issues/56) and [#63](https://github.com/nodejs/modules/pull/63) + * No objections +* Add Sven as an observer (@xtuc) [#65](https://github.com/nodejs/modules/pull/65) + * No objections +* Can I observe (@smotaal) [#68](https://github.com/nodejs/modules/issues/68) + * No objections + +### Discussion + +* Use Cases and Features [#55](https://github.com/nodejs/modules/issues/55) + - 40 minute time box + - Use Cases Doc: https://docs.google.com/document/d/10BBsIqdAXB9JR2KUzQGYbCiVugYBnxE4REBakX29yyo/edit + - JDalton: + - Last week we transitioned from reviewing use-cases to extracting features from them. + - Have tried to take a "yes, *and*" approach; no feature blocking + - More use-cases added since + - Geoffrey: added 36-38 + - (36) Users compile from CoffeeScript, some modules use CJS, some use ESM, need to interoperate among tests + - Side note: any time CoffeeScript is mentioned, feel free to substitute in something like "Babel". Same concepts apply + - (37) CoffeeScript has a tool called `coffee` that runs CoffeeScript code the same way `node` runs JavaScript code; however, `coffee` has no way of knowing whether a module has been written as an ES Module or a CommonJS module. + - (38) Want to be able to just be able to eval some code and have it work the same way async/await just started working when it was added to the language. + - Wesley Wigham + - Want to be able to change as little code as possible when updating it; same way that when touching a file, a user might want to move from constructor functions to classes, or promises to async functions + - Transparent fine-grained bidirectional interop with minimal required changes + - Guy Bedford + - (22) People are going to want to run this code in the browser as well; they will need to have some guidance and a way to build for the browser and Node that will run with as few edge-cases as possible? + - Whatever ends up happening, semantics should be consistent in the browser and via bundled code shipped to the browser. + - Saleh: having to use "browser-compatible paths" has been a general pain-point + (meant `import path from ‘path’` is an illegal specifier for browsers - alternatives?) + - Package name maps may actually address this issue. + - Rob Palmer + - (22) People don't like writing long sequences of `../../../[...]`. + - JDD: Probably fits under specifier resolution; maybe specifier resolution customization. + - (24) Also falls under the umbrella from custom specifier resolution + - Assertion: this should all work without a build tool. + - (25) Package encapsulation - ensuring only explicit named entrypoints/file can be importer by code outside the package + - (26) Would like to have an alternative resolution strategy; potentially a resolver plugin. + - (28) Want to be able to import dependencies and target the web without using any build tools + - (29) consistent understanding between development tools (IDEs, build tools, etc.) + - Could imagine that the resolution algorithm could be based around a plugin system + - (30) JDD: still belives this relates to resolution customization + - (31) Likely relates to transparent inteorp + - (33) Need to wait on Justin to confirm what he has in mind. + + - Features Doc: https://docs.google.com/document/d/1HuH5E1d_mNuziBxPDRZVjpdfmUPhqVg0MUUcYDnqwn8/edit#heading=h.sm27azjyrwql From 0ba4630e3c78382b23a2a8767b36be2308bc5266 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Micha=C3=ABl=20Zasso?= Date: Sat, 28 Apr 2018 00:23:49 +0200 Subject: [PATCH 035/226] minor fixes --- doc/meetings/2018-04-25.md | 40 +++++++++++++++++++------------------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/doc/meetings/2018-04-25.md b/doc/meetings/2018-04-25.md index e3609bf..30b2c05 100644 --- a/doc/meetings/2018-04-25.md +++ b/doc/meetings/2018-04-25.md @@ -1,4 +1,4 @@ -# Node.js Foundation Modules Team Meeting 2018-04-11 +# Node.js Foundation Modules Team Meeting 2018-04-25 * **Recording**: https://www.youtube.com/watch?v=Qbgryil1hEY * **GitHub Issue**: https://github.com/nodejs/modules/issues/71 @@ -6,25 +6,25 @@ ## Present -@DanielRosenwasser - Daniel Rosenwasser -@weswigham - Wesley Wigham -@jdalton - John-David Dalton -@devsnek - Gus Caplan -@ljharb - Jordan Harband -@benjamingr - Benjamin Gruenbaum -@mduleone - Matt DuLeone -@Fishrock123 - Jeremiah Senkpiel -@tbjers - Torgny Bjers -@mhdawson - Michael Dawson -@MylesBorins - Myles Borins -@targos - Michael Zasso -@ceejbot C J Silverio -@smotaal - Saleh A Motaal -@jdalton – John-David Dalton -@giltayar - Gil Tayar -@guybedford - Guy Bedford -@xtuc - Sven Sauleau -@inidaname - Hassan Sani +@DanielRosenwasser - Daniel Rosenwasser +@weswigham - Wesley Wigham +@jdalton - John-David Dalton +@devsnek - Gus Caplan +@ljharb - Jordan Harband +@benjamingr - Benjamin Gruenbaum +@mduleone - Matt DuLeone +@Fishrock123 - Jeremiah Senkpiel +@tbjers - Torgny Bjers +@mhdawson - Michael Dawson +@MylesBorins - Myles Borins +@targos - Michael Zasso +@ceejbot C J Silverio +@smotaal - Saleh A Motaal +@jdalton – John-David Dalton +@giltayar - Gil Tayar +@guybedford - Guy Bedford +@xtuc - Sven Sauleau +@inidaname - Hassan Sani @robpalme - Rob Palmer ## Agenda From 075ec4ad09027b932c81d3d835a8f49d1cfa1d61 Mon Sep 17 00:00:00 2001 From: Geoffrey Booth Date: Mon, 30 Apr 2018 00:38:24 -0700 Subject: [PATCH 036/226] Geoffrey was here! --- doc/meetings/2018-04-25.md | 1 + 1 file changed, 1 insertion(+) diff --git a/doc/meetings/2018-04-25.md b/doc/meetings/2018-04-25.md index 30b2c05..b52a5b7 100644 --- a/doc/meetings/2018-04-25.md +++ b/doc/meetings/2018-04-25.md @@ -26,6 +26,7 @@ @xtuc - Sven Sauleau @inidaname - Hassan Sani @robpalme - Rob Palmer +@GeoffreyBooth - Geoffrey Booth ## Agenda From d76e600ff90cbc68a92632bed512602b0248c124 Mon Sep 17 00:00:00 2001 From: tzmanics Date: Fri, 4 May 2018 17:09:17 -0400 Subject: [PATCH 037/226] Add tzmanics as observer --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index d02b83a..5362137 100644 --- a/README.md +++ b/README.md @@ -66,5 +66,6 @@ Work includes: - [@WebReflection](https://github.com/WebReflection) - Andrea Giammarchi - [@yosuke-furukawa](https://github.com/yosuke-furukawa) - Yosuke Furukawa - [@zackschuster](https://github.com/zackschuster) - Zack Schuster +- [@tzmanics](https://github.com/tzmanics) - Tara Z. Manicsic From ea14c9d2829d8c47275bbb1ea229b03c77b01673 Mon Sep 17 00:00:00 2001 From: Sven SAULEAU Date: Sat, 28 Apr 2018 10:39:15 +0200 Subject: [PATCH 038/226] refactor: change participant list --- doc/meetings/2018-02-14.md | 38 ++++++++++++++--------------- doc/meetings/2018-02-28.md | 50 +++++++++++++++++++------------------- doc/meetings/2018-03-14.md | 44 ++++++++++++++++----------------- doc/meetings/2018-03-28.md | 30 +++++++++++------------ doc/meetings/2018-04-11.md | 32 ++++++++++++------------ 5 files changed, 97 insertions(+), 97 deletions(-) diff --git a/doc/meetings/2018-02-14.md b/doc/meetings/2018-02-14.md index 8bc5944..0b9af95 100644 --- a/doc/meetings/2018-02-14.md +++ b/doc/meetings/2018-02-14.md @@ -8,25 +8,25 @@ ## Present -Benjamin Gruenbaum (@benjamingr) -Bradley Meck (@bmeck) -C J Silverio @ceejbot -Daniel Rosenwasser (@DanielRosenwasser) -Gus Caplan (@devsnek) -Jeremiah Senkpiel (@fishrock123) -Gil Tayar (@giltayar) -Guy Bedford (@guybedford) -Rebecca Turner (@iarna) -James M Snell (@jasnell) -John-David Dalton (@jdalton) -Lin Clark (@linclark) -Wassim Chegham (@manekinekko) -Matt DuLeone (@mduleone) -Michael Dawson (@mhdawson) -Myles Borins (@mylesborins) -Andrea Giammarchi (@WebReflection) -Wesley Wigham (@weswigham) -Zack Schuster (@zackschuster) +- Andrea Giammarchi (@WebReflection) +- Benjamin Gruenbaum (@benjamingr) +- Bradley Meck (@bmeck) +- C J Silverio (@ceejbot) +- Daniel Rosenwasser (@DanielRosenwasser) +- Gil Tayar (@giltayar) +- Gus Caplan (@devsnek) +- Guy Bedford (@guybedford) +- James M Snell (@jasnell) +- Jeremiah Senkpiel (@fishrock123) +- John-David Dalton (@jdalton) +- Lin Clark (@linclark) +- Matt DuLeone (@mduleone) +- Michael Dawson (@mhdawson) +- Myles Borins (@mylesborins) +- Rebecca Turner (@iarna) +- Wassim Chegham (@manekinekko) +- Wesley Wigham (@weswigham) +- Zack Schuster (@zackschuster) ## Agenda diff --git a/doc/meetings/2018-02-28.md b/doc/meetings/2018-02-28.md index 1b8e2b2..c863c3c 100644 --- a/doc/meetings/2018-02-28.md +++ b/doc/meetings/2018-02-28.md @@ -8,31 +8,31 @@ ## Present -Myles Borins (@MylesBorins) -Wesley Wigham (@weswigham) -Bradley Farias (@bmeck) -C J Silverio (@ceejbot) -Torgny Bjers (@tbjers) -Dan DuLeone (@dduleone) -Lin Clark (@linclark) -Gil Tayar (@giltayar) -Gus Caplan (@devsnek) -Guy Bedford (@guybedford) -Rebecca Turner (@iarna) -Hassan Sani (@inidaname) -Matt DuLeone (@mduleone) -Chris Dickinson (@chrisdickinson) -Jeremiah Senkpiel (@Fishrock123) -Michael Zasso (@targos) -Benjamin Gruenbaum (@benjamingr) -Daniel Rosenwasser (@DanielRosenwasser) -Justin Fagnani (@justinfagnani) -Matteo Collina (@mcollina) -Ben Newman (@benjamn) -John-David Dalton (@jdalton) -Michael Dawson (@mhdawson) -Jan Krems (@jkrems) -Jordan Harband (@ljharb) +- Ben Newman (@benjamn) +- Benjamin Gruenbaum (@benjamingr) +- Bradley Farias (@bmeck) +- C J Silverio (@ceejbot) +- Chris Dickinson (@chrisdickinson) +- Dan DuLeone (@dduleone) +- Daniel Rosenwasser (@DanielRosenwasser) +- Gil Tayar (@giltayar) +- Gus Caplan (@devsnek) +- Guy Bedford (@guybedford) +- Hassan Sani (@inidaname) +- Jan Krems (@jkrems) +- Jeremiah Senkpiel (@Fishrock123) +- John-David Dalton (@jdalton) +- Jordan Harband (@ljharb) +- Justin Fagnani (@justinfagnani) +- Lin Clark (@linclark) +- Matt DuLeone (@mduleone) +- Matteo Collina (@mcollina) +- Michael Dawson (@mhdawson) +- Michael Zasso (@targos) +- Myles Borins (@MylesBorins) +- Rebecca Turner (@iarna) +- Torgny Bjers (@tbjers) +- Wesley Wigham (@weswigham) ## Agenda diff --git a/doc/meetings/2018-03-14.md b/doc/meetings/2018-03-14.md index 7e10c9e..bad5a3a 100644 --- a/doc/meetings/2018-03-14.md +++ b/doc/meetings/2018-03-14.md @@ -6,28 +6,28 @@ ## Present -Chris Dickinson (@chrisdickinson) -Myles Borins (@MylesBorins) -Wesley Wigham (@weswigham) -Michael Zasso (@targos) -Gus Caplan (@devsnek) -Gil Tayar (@giltayar) -C J Silverio (@ceejbot) -Torgny Bjers (@tbjers) -Matt DuLeone (@mduleone) -Benjamin Gruenbaum (@benajingr) -Daniel Rosenwasser (@DanielRosenwasser) -John-David Dalton (@jdalton) -Rebecca Turner (@iarna) -Lin Clark (@linclark) -Guy Bedford (@guybedford) -Bradley Farias (@bfarias) -Jordan Harband (@ljharb) -Hassan Sani (@inidaname) -Justin Fagnani (@justinfagnani) -Ben Newman (@benjamn) -Jeremiah Senkpiel (@Fishrock123) -Jan Olaf Krems (@jkrems) +- Ben Newman (@benjamn) +- Benjamin Gruenbaum (@benajingr) +- Bradley Farias (@bfarias) +- C J Silverio (@ceejbot) +- Chris Dickinson (@chrisdickinson) +- Daniel Rosenwasser (@DanielRosenwasser) +- Gil Tayar (@giltayar) +- Gus Caplan (@devsnek) +- Guy Bedford (@guybedford) +- Hassan Sani (@inidaname) +- Jan Olaf Krems (@jkrems) +- Jeremiah Senkpiel (@Fishrock123) +- John-David Dalton (@jdalton) +- Jordan Harband (@ljharb) +- Justin Fagnani (@justinfagnani) +- Lin Clark (@linclark) +- Matt DuLeone (@mduleone) +- Michael Zasso (@targos) +- Myles Borins (@MylesBorins) +- Rebecca Turner (@iarna) +- Torgny Bjers (@tbjers) +- Wesley Wigham (@weswigham) ## Agenda diff --git a/doc/meetings/2018-03-28.md b/doc/meetings/2018-03-28.md index 604b19d..9ea010b 100644 --- a/doc/meetings/2018-03-28.md +++ b/doc/meetings/2018-03-28.md @@ -7,21 +7,21 @@ ## Present -@MylesBorins (Myles Borins) -@TimothyGu (Timothy Gu) -@ceejbot (C J Silverio) -@iarna (Rebecca Turner) -@justinfagnani (Justin Fagnani) -@linclark (Lin Clark) -@tbjers (Torgny Bjers) -@inidaname (Hassan Sani) -@jdalton (John-David Dalton) -@devsnek (Gus Caplan) -@manekinekko (Wassim Chegham) -@benjamn (Ben Newman) -@bmeck (Bradley Farias) -@weswigham (Wesley Wigham) -@robpalme (Rob Palmer) +- Ben Newman (@benjamn) +- Bradley Farias (@bmeck) +- C J Silverio (@ceejbot) +- Gus Caplan (@devsnek) +- Hassan Sani (@inidaname) +- John-David Dalton (@jdalton) +- Justin Fagnani (@justinfagnani) +- Lin Clark (@linclark) +- Myles Borins (@MylesBorins) +- Rebecca Turner (@iarna) +- Rob Palmer (@robpalme) +- Timothy Gu (@TimothyGu) +- Torgny Bjers (@tbjers) +- Wassim Chegham (@manekinekko) +- Wesley Wigham (@weswigham) ## Agenda diff --git a/doc/meetings/2018-04-11.md b/doc/meetings/2018-04-11.md index ffe33c9..7e0c2fe 100644 --- a/doc/meetings/2018-04-11.md +++ b/doc/meetings/2018-04-11.md @@ -6,22 +6,22 @@ ## Present -@benjamingr - Benjamin Gruenbaum -@MylesBorins - Myles Borins -@mhdawson - Michael Dawson -@mduleone - Matt DuLeone -@tbjers - Torgny Bjers -@bmeck - Bradley Farias -@guybedford - Guy Bedford -@devsnek - Gus Caplan -@robpalme - Rob Palmer -@jdalton - John-David Dalton -@weswigham - Wesley Wigham -@targos - Michael Zasso -@iarna - Rebecca Turner -@ljharb - Jordan Harband -@benjamn - Ben Newman -@fishrock Jeremiah Senkpiel +- Ben Newman (@benjamn) +- Benjamin Gruenbaum (@benjamingr) +- Bradley Farias (@bmeck) +- Gus Caplan (@devsnek) +- Guy Bedford (@guybedford) +- Jeremiah Senkpiel (@fishrock) +- John-David Dalton (@jdalton) +- Jordan Harband (@ljharb) +- Matt DuLeone (@mduleone) +- Michael Dawson (@mhdawson) +- Michael Zasso (@targos) +- Myles Borins (@MylesBorins) +- Rebecca Turner (@iarna) +- Rob Palmer (@robpalme) +- Torgny Bjers (@tbjers) +- Wesley Wigham (@weswigham) ## Agenda From ccd8def39aac2e3c2e643bd57e9888e9f9c795cc Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Tue, 8 May 2018 13:55:50 -0700 Subject: [PATCH 039/226] doc: update membership list with ncu-team sync --- README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README.md b/README.md index d02b83a..b56c517 100644 --- a/README.md +++ b/README.md @@ -57,6 +57,7 @@ Work includes: - [@devamaz](https://github.com/devamaz) - Ahmad Abdul-Aziz - [@eugeneo](https://github.com/eugeneo) - Eugene Ostroukhov - [@evanplaice](https://github.com/evanplaice) - Evan Plaice +- [@GeoffreyBooth](https://github.com/GeoffreyBooth) - Geoffrey Booth - [@hiroppy](https://github.com/hiroppy) - Yuta Hiroto - [@jasnell](https://github.com/jasnell) - James M Snell - [@refack](https://github.com/refack) - Refael Ackermann @@ -64,6 +65,7 @@ Work includes: - [@tbranyen](https://github.com/tbranyen) - Tim Branyen - [@TheLarkInn](https://github.com/TheLarkInn) - Sean Larkin - [@WebReflection](https://github.com/WebReflection) - Andrea Giammarchi +- [@xtuc](https://github.com/xtuc) - Sven SAULEAU - [@yosuke-furukawa](https://github.com/yosuke-furukawa) - Yosuke Furukawa - [@zackschuster](https://github.com/zackschuster) - Zack Schuster From 831f574dd599f7a582b7c3ddb1d977e5ea5978f6 Mon Sep 17 00:00:00 2001 From: Sven SAULEAU Date: Wed, 9 May 2018 12:12:19 +0200 Subject: [PATCH 040/226] docs: update participant list --- doc/meetings/2018-04-25.md | 42 +++++++++++++++++++------------------- 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/doc/meetings/2018-04-25.md b/doc/meetings/2018-04-25.md index b52a5b7..9c8b237 100644 --- a/doc/meetings/2018-04-25.md +++ b/doc/meetings/2018-04-25.md @@ -6,27 +6,27 @@ ## Present -@DanielRosenwasser - Daniel Rosenwasser -@weswigham - Wesley Wigham -@jdalton - John-David Dalton -@devsnek - Gus Caplan -@ljharb - Jordan Harband -@benjamingr - Benjamin Gruenbaum -@mduleone - Matt DuLeone -@Fishrock123 - Jeremiah Senkpiel -@tbjers - Torgny Bjers -@mhdawson - Michael Dawson -@MylesBorins - Myles Borins -@targos - Michael Zasso -@ceejbot C J Silverio -@smotaal - Saleh A Motaal -@jdalton – John-David Dalton -@giltayar - Gil Tayar -@guybedford - Guy Bedford -@xtuc - Sven Sauleau -@inidaname - Hassan Sani -@robpalme - Rob Palmer -@GeoffreyBooth - Geoffrey Booth +- Benjamin Gruenbaum (@benjamingr) +- C J Silverio (@ceejbot) +- Daniel Rosenwasser (@DanielRosenwasser) +- Geoffrey Booth(@GeoffreyBooth) +- Gil Tayar (@giltayar) +- Gus Caplan (@devsnek) +- Guy Bedford (@guybedford) +- Hassan Sani (@inidaname) +- Jeremiah Senkpiel (@Fishrock123) +- John-David Dalton (@jdalton) +- Jordan Harband (@ljharb) +- Matt DuLeone (@mduleone) +- Michael Dawson (@mhdawson) +- Michael Zasso (@targos) +- Myles Borins (@MylesBorins) +- Rob Palmer(@robpalme) +- Saleh A Motaal (@smotaal) +- Sven Sauleau (@xtuc) +- Torgny Bjers (@tbjers) +- Wesley Wigham (@weswigham) +– John-David Dalton (@jdalton) ## Agenda From 68e0d4030088b7709198d328aada4ef92f6628f1 Mon Sep 17 00:00:00 2001 From: Sven SAULEAU Date: Wed, 9 May 2018 21:05:33 +0200 Subject: [PATCH 041/226] fix: ordering and duplicate --- doc/meetings/2018-04-25.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/meetings/2018-04-25.md b/doc/meetings/2018-04-25.md index 9c8b237..53d0af0 100644 --- a/doc/meetings/2018-04-25.md +++ b/doc/meetings/2018-04-25.md @@ -26,7 +26,7 @@ - Sven Sauleau (@xtuc) - Torgny Bjers (@tbjers) - Wesley Wigham (@weswigham) -– John-David Dalton (@jdalton) + ## Agenda From 4afdd941b13c3bc2312aa135198304ea423666db Mon Sep 17 00:00:00 2001 From: Timothy Gu Date: Fri, 18 May 2018 17:56:25 -0700 Subject: [PATCH 042/226] Move @TimothyGu to observers --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 0e449e4..cde7b5c 100644 --- a/README.md +++ b/README.md @@ -42,7 +42,6 @@ Work includes: - [@robpalme](https://github.com/robpalme) - Rob Palmer - [@targos](https://github.com/targos) - Michaël Zasso - [@tbjers](https://github.com/tbjers) - Torgny Bjers -- [@TimothyGu](https://github.com/TimothyGu) - Timothy Gu - [@weswigham](https://github.com/weswigham) - Wesley Wigham - [@XadillaX](https://github.com/XadillaX) - Khaidi Chu @@ -64,6 +63,7 @@ Work includes: - [@robwormald](https://github.com/robwormald) - Rob Wormald - [@tbranyen](https://github.com/tbranyen) - Tim Branyen - [@TheLarkInn](https://github.com/TheLarkInn) - Sean Larkin +- [@TimothyGu](https://github.com/TimothyGu) - Timothy Gu - [@WebReflection](https://github.com/WebReflection) - Andrea Giammarchi - [@xtuc](https://github.com/xtuc) - Sven SAULEAU - [@yosuke-furukawa](https://github.com/yosuke-furukawa) - Yosuke Furukawa From 0b68104859ca395f99580bf14f1fa8adad7b21ba Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Wed, 9 May 2018 13:17:22 -0700 Subject: [PATCH 043/226] doc: 2018-05-09 meeting notes --- doc/meetings/2018-05-09.md | 44 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) create mode 100644 doc/meetings/2018-05-09.md diff --git a/doc/meetings/2018-05-09.md b/doc/meetings/2018-05-09.md new file mode 100644 index 0000000..88f887c --- /dev/null +++ b/doc/meetings/2018-05-09.md @@ -0,0 +1,44 @@ +# Node.js Foundation Modules Team Meeting 2018-05-09 + +* **Recording**: https://www.youtube.com/watch?v=4vOltZBEFvM +* **GitHub Issue**: https://github.com/nodejs/modules/issues/78 +* **Minutes Google Doc**: https://docs.google.com/document/d/1o6VUMBgZxS1bwmj2BahiGYxZwGqLXudABhbvIkDduXw/edit + +## Present + +@jdalton (John-David Dalton) +@mhdawson (Michael Dawson) +@iarna (Rebecca Turner) +@fishrock123 (Jeremiah Senkpiel) +@robpalme (Rob Palmer) +@xtuc (Sven Sauleau) +@ljharb (Jordan Harband) +@guybedford (Guy Bedford) +@bmeck (Bradley Farias) +@geoffreyBooth (Geoffrey Booth) +@inidaname (Hassan Sani) +@weswigham (Wesley Wigham) + +## Agenda + +Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. + +### Discussion + +* Use Cases (Tracking Issue) [#55](https://github.com/nodejs/modules/issues/55) + +* Modules team: @nodejs/modules + - 55 minute timebox + +### Approving PRs (4 Minute Time Box) + +* governance: introduce PR exemptions for minutes [#72](https://github.com/nodejs/modules/pull/72) +* doc: add 2018-04-25 notes [#73](https://github.com/nodejs/modules/pull/73) + +### Approving Observers (1 minute timebox) + +*add tzmanics as observer (@tzmanics) [#76](https://github.com/nodejs/modules/pull/76) + +### Use Cases (Tracking Issue) #55 +55 minute timebox + From badf2e60132d01ddec3388c31d71949d7e24f9c4 Mon Sep 17 00:00:00 2001 From: Jordan Harband Date: Wed, 9 May 2018 14:07:01 -0700 Subject: [PATCH 044/226] Add fs/promises item --- doc/meetings/2018-05-09.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/meetings/2018-05-09.md b/doc/meetings/2018-05-09.md index 88f887c..57565c6 100644 --- a/doc/meetings/2018-05-09.md +++ b/doc/meetings/2018-05-09.md @@ -25,6 +25,8 @@ Extracted from **modules-agenda** labelled issues and pull requests from the **n ### Discussion +* RFC on [ways to prevent new node core modules from conflicting with npm](https://github.com/nodejs/TSC/issues/389) + * Use Cases (Tracking Issue) [#55](https://github.com/nodejs/modules/issues/55) * Modules team: @nodejs/modules From 87632c8437db94774afdf8b8e8ed0a0347ffa660 Mon Sep 17 00:00:00 2001 From: John-David Dalton Date: Tue, 15 May 2018 12:55:48 -0700 Subject: [PATCH 045/226] Add meeting notes. --- doc/meetings/2018-05-09.md | 100 ++++++++++++++++++++++++++++++++----- 1 file changed, 88 insertions(+), 12 deletions(-) diff --git a/doc/meetings/2018-05-09.md b/doc/meetings/2018-05-09.md index 57565c6..a469aff 100644 --- a/doc/meetings/2018-05-09.md +++ b/doc/meetings/2018-05-09.md @@ -23,24 +23,100 @@ Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. -### Discussion - -* RFC on [ways to prevent new node core modules from conflicting with npm](https://github.com/nodejs/TSC/issues/389) - -* Use Cases (Tracking Issue) [#55](https://github.com/nodejs/modules/issues/55) - -* Modules team: @nodejs/modules - - 55 minute timebox - ### Approving PRs (4 Minute Time Box) - * governance: introduce PR exemptions for minutes [#72](https://github.com/nodejs/modules/pull/72) + * No objections * doc: add 2018-04-25 notes [#73](https://github.com/nodejs/modules/pull/73) + * No objections ### Approving Observers (1 minute timebox) *add tzmanics as observer (@tzmanics) [#76](https://github.com/nodejs/modules/pull/76) + * No objections + +### Discussion -### Use Cases (Tracking Issue) #55 -55 minute timebox +* Use Cases (Tracking Issue) [#55](https://github.com/nodejs/modules/issues/55) + +* Modules team: @nodejs/modules + - Opening comments + - John-David Dalton (JDD): + - Node 10+ released with `util.types.isModuleNamespaceObject` + - [PR #20403](https://github.com/nodejs/node/pull/20403) simplified now that + [V8 bug](https://bugs.chromium.org/p/v8/issues/detail?id=5773) is fixed + - On the user-land front JDD is experimenting with getting APM packages and + module mocking working. + - Jordan Harband: + - Node 10 introduced a new core module, `fs/promises`, and Node 10.1.0 + moved it to `fs.promises`. Can we figure out a way for core modules to + not conflict with bare packages in npm? The rough consenses was that + after `http2` they won't add new core modules without coming up with a + way to avoid clobbering bare npm packages. Maybe a special Node namespace. + Ideas welcomed. + - RFC on [ways to prevent new node core modules from conflicting with npm](https://github.com/nodejs/TSC/issues/389) + - Michael Dawson: + - If the group thinks there is/ or is-not a linkage to ESM please chime in + to provide feedback. + - Use case review (55 minute timebox) + - Geoffrey Booth + - Use case #40. The average user sees that Node added support for + import/export syntax so they should be able to drop Babel trasnforms for + import/export and it just works. For users the feature is the syntax. + - JDD + - Sounds like transparent migration + - Geoffrey Booth + - Use case #41. Ensure CJS is continued to be supported without refactoring. + - Jeremiah + - We have a some cases of things doable in CJS that isn't doable in ESM + - Bradley Farias + - Takes issue with wording the feature as "synchronous" and would rather + name it "conditional". + - JDD + - Added conditional imports to the feature doc + - Added synchronous imports to the features doc (Jordan Harband created a use case for it) + - Geoffrey Booth + - Use case #47 - + - Importing a JSON file + - JDD + - We should look up feature for WASM, HTML import feature... (TODO: JDD) + - Wesley Wigham + - TypeScript use case #42 + - Bradley Farias, JDD, and Rebecca Turner + - Requests more info (Wes expanded https://github.com/nodejs/modules/issues/80) + - Rebecca Turner + - We may have quorum if we can count those that cast their votes + before the meeting. + - _Resolved pending PRs and Observer approvals_ + - Bradley Farias + - Gus Caplan has a concern about dynamic imports and thenable results. + - Guy Bedford + - The `vm.Module` API breaks down with a dynamic import that returns a thenable + result. Gus' proposal is to add a symbol that will treat the "thenable" as + a plain object. (https://github.com/devsnek/proposal-symbol-thenable) + - Rob Palmer + - When the topic has come up before there has been strong views from + Domenic Denicola (Google) who wants a solution that can apply for Promises + in general and not namespace objects. + - Geoffrey Booth + - What are next steps? + - JDD + - We should start discussion issues on specific features. + - We have ~17 features to choose from. Pick one that you're passionate + about. We'll tag them as discussion. + - Geoffrey Booth + - Continue the yes-and mindset? + - JDD + - Yes. Try to be open minded and yes-and. Since we are fleshing things out + you will come into a discussion where "as things are now XYZ is not doable". + I encourage folks to think about what would need to be changed or tweaked + to enable a feature for a givien use case. So people know where the + roadblocks are going to be. + - Bradley Farias + - I 2nd that. + - We shouldn't limit ourselves to just tweaking an implementation. + - We're still behind an experimental flag. We can scrap large chunks + if needed. + - JDD + - Try to enable and empower. + - Start those discussion threads. From cc6457957eeb0d74889eae962bb0e2381fff3bfd Mon Sep 17 00:00:00 2001 From: Gus Caplan Date: Wed, 16 May 2018 17:27:18 -0500 Subject: [PATCH 046/226] add missing space --- doc/meetings/2018-05-09.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/meetings/2018-05-09.md b/doc/meetings/2018-05-09.md index a469aff..2474529 100644 --- a/doc/meetings/2018-05-09.md +++ b/doc/meetings/2018-05-09.md @@ -31,7 +31,7 @@ Extracted from **modules-agenda** labelled issues and pull requests from the **n ### Approving Observers (1 minute timebox) -*add tzmanics as observer (@tzmanics) [#76](https://github.com/nodejs/modules/pull/76) +* add tzmanics as observer (@tzmanics) [#76](https://github.com/nodejs/modules/pull/76) * No objections ### Discussion From 68b95ed5e5a24e7aa2ce1cb954a59df89abf4f33 Mon Sep 17 00:00:00 2001 From: Sven SAULEAU Date: Sat, 19 May 2018 11:16:51 +0200 Subject: [PATCH 047/226] Update 2018-05-09.md --- doc/meetings/2018-05-09.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/doc/meetings/2018-05-09.md b/doc/meetings/2018-05-09.md index 2474529..da5a435 100644 --- a/doc/meetings/2018-05-09.md +++ b/doc/meetings/2018-05-09.md @@ -6,18 +6,18 @@ ## Present -@jdalton (John-David Dalton) -@mhdawson (Michael Dawson) -@iarna (Rebecca Turner) -@fishrock123 (Jeremiah Senkpiel) -@robpalme (Rob Palmer) -@xtuc (Sven Sauleau) -@ljharb (Jordan Harband) -@guybedford (Guy Bedford) -@bmeck (Bradley Farias) -@geoffreyBooth (Geoffrey Booth) -@inidaname (Hassan Sani) -@weswigham (Wesley Wigham) +- Bradley Farias (@bmeck) +- Geoffrey Booth (@geoffreyBooth) +- Guy Bedford (@guybedford) +- Hassan Sani (@inidaname) +- Jeremiah Senkpiel (@fishrock123) +- John-David Dalton (@jdalton) +- Jordan Harband (@ljharb) +- Michael Dawson (@mhdawson) +- Rebecca Turner (@iarna) +- Rob Palmer (@robpalme) +- Sven Sauleau (@xtuc) +- Wesley Wigham (@weswigham) ## Agenda From e981519e5114497c316a3608fba0d6ea7e387aa2 Mon Sep 17 00:00:00 2001 From: John-David Dalton Date: Fri, 18 May 2018 17:07:43 -0700 Subject: [PATCH 048/226] Move Geoffrey Booth to member. --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index cde7b5c..f725599 100644 --- a/README.md +++ b/README.md @@ -25,6 +25,7 @@ Work includes: - [@DanielRosenwasser](https://github.com/DanielRosenwasser) - Daniel Rosenwasser - [@devsnek](https://github.com/devsnek) - Gus Caplan - [@Fishrock123](https://github.com/Fishrock123) - Jeremiah Senkpiel +- [@GeoffreyBooth](https://github.com/GeoffreyBooth) - Geoffrey Booth - [@giltayar](https://github.com/giltayar) - Gil Tayar - [@guybedford](https://github.com/guybedford) - Guy Bedford - [@iarna](https://github.com/iarna) - Rebecca Turner @@ -53,10 +54,9 @@ Work includes: - [@bmeurer](https://github.com/bmeurer) - Benedikt Meurer - [@dduleone](https://github.com/dduleone) - Dan DuLeone -- [@devamaz](https://github.com/devamaz) - Ahmad Abdul-Aziz +- [@devamaz](https://github.com/devamaz) - Ahmad Abdul-Aziz - [@eugeneo](https://github.com/eugeneo) - Eugene Ostroukhov - [@evanplaice](https://github.com/evanplaice) - Evan Plaice -- [@GeoffreyBooth](https://github.com/GeoffreyBooth) - Geoffrey Booth - [@hiroppy](https://github.com/hiroppy) - Yuta Hiroto - [@jasnell](https://github.com/jasnell) - James M Snell - [@refack](https://github.com/refack) - Refael Ackermann From 4461feb98081adfa1ed1dafa3f6372beef9940bf Mon Sep 17 00:00:00 2001 From: John-David Dalton Date: Fri, 18 May 2018 17:04:59 -0700 Subject: [PATCH 049/226] Add Kevin Smith as an observer. --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index f725599..84bb389 100644 --- a/README.md +++ b/README.md @@ -69,5 +69,6 @@ Work includes: - [@yosuke-furukawa](https://github.com/yosuke-furukawa) - Yosuke Furukawa - [@zackschuster](https://github.com/zackschuster) - Zack Schuster - [@tzmanics](https://github.com/tzmanics) - Tara Z. Manicsic +- [@zenparsing](https://github.com/zenparsing) - Kevin Smith From 81c8cccc36557e68ef1c53e0b15159fb60121634 Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Tue, 5 Jun 2018 16:40:02 +0200 Subject: [PATCH 050/226] doc: 5-23 meeting notes --- doc/meetings/2018-05-23.md | 70 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 70 insertions(+) create mode 100644 doc/meetings/2018-05-23.md diff --git a/doc/meetings/2018-05-23.md b/doc/meetings/2018-05-23.md new file mode 100644 index 0000000..a3cfe0a --- /dev/null +++ b/doc/meetings/2018-05-23.md @@ -0,0 +1,70 @@ +# Node.js Foundation Modules Team Meeting 2018-05-23 + +* **Recording**: https://www.youtube.com/watch?v=J329JT8FRRg +* **GitHub Issue**: https://github.com/nodejs/modules/issues/117 +* **Minutes Google Doc**: https://docs.google.com/document/d/1hVk9omD3soHU5Dg4RjP92zXuf6DRzOpWKJRoIK2AVyo/edit + +## Present + +- Benjamin Gruenbaum (@benjamingr) +- Bradley Farias (@bmeck) +- Geoffrey Booth (@GeoffreyBooth) +- Gus Caplan (@devsnek) +- Guy Bedford (@guybedford) +- Jan Krems (@jkrems) +- John-David Dalton (@jdalton) +- Jordan Harband (@ljharb) +- Hassan Sani (@inidaname) +- Matt DuLeone (@mduleone) +- Michael Zasso (@targos) +- Myles Borins (@mylesborins) +- Rob Palmer (@robpalme) +- Saleh Abdel Motaal (@smotaal) +- Wassim Chegham (@manekinekko) +- Wesley Wigham (@weswigham) +- Torgny Bjers (@tbjers) + +## Agenda + +Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. + +### Approving PRs (2 minute timebox) + +* Move Geoffrey Booth to member. [#89](https://github.com/nodejs/modules/pull/89) + - no objections +* Add Kevin Smith as an observer. [#88](https://github.com/nodejs/modules/pull/88) + - no objections +### Discussion (55 minute timebox) + +* Initiative: Terminology / Historical Decisions documents [#119](https://github.com/nodejs/modules/issues/119) + - 5 minute timebox + - saleh will kick off a document + +* Developer Survey [#85](https://github.com/nodejs/modules/issues/85) + - 5 minute timebox + + - guy: what objectives do we have in mind? + - jdd: node foundation or js foundation could promote + - brad: it is going to be very hard to avoid bias + - brad: how do we set proper expectations + - myles: avoid setting expectations by not making leading questions + - Hassan: MO Developer Survey will provide us a platform to elaborate more on how user will really work with Modules. + +* Topics to discuss with TC39 [#84](https://github.com/nodejs/modules/issues/84) + - 5 minute timebox + - jdd: builtins? + - brad: there is a new proposal going on that might help with this + +* Feature: Transparent interoperability for ESM importing CommonJS [#100](https://github.com/nodejs/modules/issues/100) and transparent-or-not interop [#90](https://github.com/nodejs/modules/issues/90) + - 15 minute timebox + - This is a really big issue to discuss + - geoff: maybe we should split it up + - myles: objections, there is a plethora of issues already open and this is really hard to keep track of + - saleh: having everything as an issue and multiple discussion under multiple features is confusing (recommend using Milestones or creating separate repo like nodejs/modules-features as long as the topics unfold in a manageable manner) + - guy: so many implications of implementation decisions. Workflows vs bundlers vs npm… all of this needs to be kept in mind. Fleshing out those stories for coherent features can make sense. Risk of creating island and forcing vision + - geoff: perhaps we can avoid talking about implementation of a feature. + - myles: the current pace is just not tenable to keep up with + - ongoing discussion about how to define transparent interop + - brad + rob to work on + + From ad7387fdc9d477656e36302d0329437d5edeb254 Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Mon, 11 Jun 2018 12:25:18 -0400 Subject: [PATCH 051/226] governance: s/pull request/issue for new members Our current process for opening a PR to request membership was implemented before we started using ncu-sync to keep the membership list up to date. With this is mind I think it makes more sense to have new members make a request to join via issue rather than PR. --- GOVERNANCE.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index b741916..5f95868 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -31,7 +31,7 @@ Team Membership is not time-limited. There is no fixed size of the Team. There is no specific set of requirements or qualifications for Team Membership beyond these rules. -Changes to Team membership should be proposed with a pull-request and labelled `modules-agenda` +Changes to Team membership should be proposed with an issue and labelled `modules-agenda` to be included in the next [team meeting](#team-meetings). Decisions are made via the [Consensus Seeking Process](#consensus-seeking-process). From 5e7caf02b779c9ec7f62f4a2c9c0b57292d0a8f8 Mon Sep 17 00:00:00 2001 From: Geoffrey Booth Date: Sun, 17 Jun 2018 23:12:17 -0700 Subject: [PATCH 052/226] Add features list to README --- README.md | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/README.md b/README.md index 84bb389..ae324be 100644 --- a/README.md +++ b/README.md @@ -13,6 +13,43 @@ Work includes: * Node.js and Browser interoperability * VM Modules implementation +## Features + +Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUzQGYbCiVugYBnxE4REBakX29yyo/edit) ([#55](https://github.com/nodejs/modules/issues/55)), our implementation aims to support the following features: + +- Spec compliance ([#132](https://github.com/nodejs/modules/issues/132)) +- Browser equivalence ([#133](https://github.com/nodejs/modules/issues/133)) +- No refactoring ([#87](https://github.com/nodejs/modules/issues/87)) +- Pluggable Loaders to support multiple use cases ([#82](https://github.com/nodejs/modules/issues/82)) +- Named exports when importing CJS ([#81](https://github.com/nodejs/modules/issues/81)) +- Dual-goal packages ([#93](https://github.com/nodejs/modules/issues/93)) +- Multi-mode packages ([#94](https://github.com/nodejs/modules/issues/94)) +- Code coverage/instrumentation ([#95](https://github.com/nodejs/modules/issues/95)) +- Runtime loaders, transpilation at import time ([#96](https://github.com/nodejs/modules/issues/96)) +- Arbitrary sources for module source text ([#97](https://github.com/nodejs/modules/issues/97)) +- Mock modules (injection) ([#98](https://github.com/nodejs/modules/issues/98)) +- Mixed module types within app/module; gradual migration from CommonJS to ESM ([#99](https://github.com/nodejs/modules/issues/99)) +- Transparent interoperability for ESM importing CommonJS ([#100](https://github.com/nodejs/modules/issues/100)) +- Polyfillability ([#101](https://github.com/nodejs/modules/issues/101)) +- Tree shaking ([#102](https://github.com/nodejs/modules/issues/102)) +- File / path / URL resolving ([#103](https://github.com/nodejs/modules/issues/103)) +- Retrievable module metadata ([#104](https://github.com/nodejs/modules/issues/104)) +- Transparent migration ([#105](https://github.com/nodejs/modules/issues/105)) +- WASM modules ([#106](https://github.com/nodejs/modules/issues/106)) +- Browser and Node compatibility without building ([#107](https://github.com/nodejs/modules/issues/107)) +- Browser-compatible build that includes CommonJS ([#108](https://github.com/nodejs/modules/issues/108)) +- Browser-compatible specifier resolution ([#109](https://github.com/nodejs/modules/issues/109)) +- Specifier resolution customization ([#110](https://github.com/nodejs/modules/issues/110)) +- Package encapsulation ([#111](https://github.com/nodejs/modules/issues/111)) +- Don’t break CommonJS ([#112](https://github.com/nodejs/modules/issues/112)) +- Conditional imports ([#113](https://github.com/nodejs/modules/issues/113)) +- Import JSON without needing asynchronous syntax ([#114](https://github.com/nodejs/modules/issues/114)) +- Importing non-JavaScript files ([#115](https://github.com/nodejs/modules/issues/115)) +- Import CommonJS without needing asynchronous syntax ([#116](https://github.com/nodejs/modules/issues/116)) +- NodeJS contextual pathing use cases ([#121](https://github.com/nodejs/modules/issues/121)) +- Load ESM over https ([#127](https://github.com/nodejs/modules/issues/127)) + + ## Members From 45b011e86fd831fb7ef2fd54a30f9a0e7716d546 Mon Sep 17 00:00:00 2001 From: Geoffrey Booth Date: Wed, 20 Jun 2018 09:32:43 -0700 Subject: [PATCH 053/226] Add subject-to-change language --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index ae324be..03640df 100644 --- a/README.md +++ b/README.md @@ -15,7 +15,7 @@ Work includes: ## Features -Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUzQGYbCiVugYBnxE4REBakX29yyo/edit) ([#55](https://github.com/nodejs/modules/issues/55)), our implementation aims to support the following features: +Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUzQGYbCiVugYBnxE4REBakX29yyo/edit) ([#55](https://github.com/nodejs/modules/issues/55)), our implementation aims to support the following features (subject to change): - Spec compliance ([#132](https://github.com/nodejs/modules/issues/132)) - Browser equivalence ([#133](https://github.com/nodejs/modules/issues/133)) From a98d607d2542afdbcfd3104e08a9ad00c0117da2 Mon Sep 17 00:00:00 2001 From: Geoffrey Booth Date: Wed, 20 Jun 2018 12:12:33 -0700 Subject: [PATCH 054/226] Remove import-over-https feature --- README.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/README.md b/README.md index 03640df..a974a05 100644 --- a/README.md +++ b/README.md @@ -47,8 +47,6 @@ Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUz - Importing non-JavaScript files ([#115](https://github.com/nodejs/modules/issues/115)) - Import CommonJS without needing asynchronous syntax ([#116](https://github.com/nodejs/modules/issues/116)) - NodeJS contextual pathing use cases ([#121](https://github.com/nodejs/modules/issues/121)) -- Load ESM over https ([#127](https://github.com/nodejs/modules/issues/127)) - ## Members From 5b26f3f404b1e1bc40943507aa8faeaf9b492548 Mon Sep 17 00:00:00 2001 From: Sven Sauleau Date: Mon, 2 Jul 2018 07:40:32 +0200 Subject: [PATCH 055/226] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index a974a05..9815681 100644 --- a/README.md +++ b/README.md @@ -100,7 +100,7 @@ Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUz - [@TheLarkInn](https://github.com/TheLarkInn) - Sean Larkin - [@TimothyGu](https://github.com/TimothyGu) - Timothy Gu - [@WebReflection](https://github.com/WebReflection) - Andrea Giammarchi -- [@xtuc](https://github.com/xtuc) - Sven SAULEAU +- [@xtuc](https://github.com/xtuc) - Sven Sauleau - [@yosuke-furukawa](https://github.com/yosuke-furukawa) - Yosuke Furukawa - [@zackschuster](https://github.com/zackschuster) - Zack Schuster - [@tzmanics](https://github.com/tzmanics) - Tara Z. Manicsic From 0d0b9e44546b335b8436e8c356d2302b29ea9017 Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Mon, 9 Jul 2018 13:26:07 -0400 Subject: [PATCH 056/226] doc: june meetings --- doc/meetings/2018-06-06.md | 53 ++++++++++++++++++++++ doc/meetings/2018-06-20.md | 93 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 146 insertions(+) create mode 100644 doc/meetings/2018-06-06.md create mode 100644 doc/meetings/2018-06-20.md diff --git a/doc/meetings/2018-06-06.md b/doc/meetings/2018-06-06.md new file mode 100644 index 0000000..a745034 --- /dev/null +++ b/doc/meetings/2018-06-06.md @@ -0,0 +1,53 @@ +# Node.js Foundation Modules Team Meeting 2018-06-06 + +* **Recording**: https://www.youtube.com/watch?v=e8CovmklaKA +* **GitHub Issue**: https://github.com/nodejs/modules/issues/124 +* **Minutes Google Doc**: https://docs.google.com/document/d/1UKbxxr35YTlaiu6h6xYSCweWOhTZExLHPUJn8-tZSXs/edit + +## Present + +- @DanielRosenwasser (Daniel Rosenwasser) +- @mduleone (Matt DuLeone) +- @weswigham (Wesley Wigham) +- @mhdawson (Michael Dawson) +- @targos (Michaël Zasso) +- @xtuc (Sven Sauleau) +- @jdalton (John-David Dalton) +- @bmeck (Bradley Farias) +- @guybedford (Guy Bedford) +- @GeoffreyBooth (Geoffrey Booth) +- @giltayar (Gil Tayar) +- @benjamn (Ben Newman) +- @jankrems (Jan Krems) +- @inidaname (Hassan Sani) + +## Agenda + +Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. + +### nodejs/node + +* loader: warn when the user imports a module with a thenable namespace [#20951](https://github.com/nodejs/node/pull/20951) + +### nodejs/modules + +* Thinking about deadlines [#123](https://github.com/nodejs/modules/issues/123) +* Initiative: Terminology / Historical Decisions documents [#119](https://github.com/nodejs/modules/issues/119) +* Feature: Transparent interoperability for ESM importing CommonJS [#100](https://github.com/nodejs/modules/issues/100) +* transparent-or-not interop [#90](https://github.com/nodejs/modules/issues/90) + +* Developer Survey [#85](https://github.com/nodejs/modules/issues/85) + * request to put out developer survey to confirm what we believe developer + opinions are. +* Use Cases (Tracking Issue) [#55](https://github.com/nodejs/modules/issues/55) + +## 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: Will be added a few minutes before meeting starts +* For those who just want to watch: +* youtube admin page: https://www.youtube.com/my_live_events?filter=scheduled + diff --git a/doc/meetings/2018-06-20.md b/doc/meetings/2018-06-20.md new file mode 100644 index 0000000..eefcf0d --- /dev/null +++ b/doc/meetings/2018-06-20.md @@ -0,0 +1,93 @@ +# Node.js Foundation Modules Team Meeting 2018-06-20 + +* **Recording**: https://www.youtube.com/watch?v=RIdJMD42ZGs +* **GitHub Issue**: https://github.com/nodejs/modules/issues/124 +* **Minutes Google Doc**: https://docs.google.com/document/d/1UKbxxr35YTlaiu6h6xYSCweWOhTZExLHPUJn8-tZSXs/edit + +## Present + +- Michael Dawson (@mhdawson) +- Daniel Rosenwasser (@DanielRosenwasser) +- Jan Krems (@jkrems) +- Wesley Wigham (@weswigham) +- Myles Borins (@MylesBorins) +- Matt DuLeone (@mduleone) +- Gus Caplan (@devsnek) +- John-David Dalton (@jdalton) +- Gil Tayar (@giltayar) +- Saleh Abdel Motaal (@smotaal) +- Geoffrey Booth (@GeoffreyBooth) +- Guy Bedford (@guybedford) +- Michael Zasso (@targos) +- Sven Sauleau (@xtuc) +- Hassan Sani (@inidaname) +- Torgny Bjers (@tbjers) + +## Agenda + +This meeting is to discuss transparent interop with the goal of informing and coming to a decision on if-any-transparent interop should be possible _(by default, or by loader, or by otherwise)_. Please keep in mind transparent interop is a large umbrella. We should clarify and make clear distinctions about what we are discussing _(one sided, two sided, etc.)_. + +Other Items: + +* governance: s/pull request/issue for new members ([#128](https://github.com/nodejs/modules/pulls/128)) +* Pull request opened for import.meta.require on core ([#130](https://github.com/nodejs/modules/pulls/130)) +* Have presentation on loaders. ([#128](https://github.com/nodejs/modules/pulls/128)) +* Add features list to README ([#128](https://github.com/nodejs/modules/pulls/134)) + +## Invited + +* Modules team: @nodejs/modules + +* We have quorum +* Landed [#128](https://github.com/nodejs/modules/pulls/128) (landed) +* Deferred discussing (#130) until the end of the meeting +* Defer presentation on loaders ([#135](https://github.com/nodejs/modules/issues/135)) +* Add features list to README [#134](https://github.com/nodejs/modules/pulls/134) (landed) + - Used to close a large portion of the open feature issues and move them into a single place +* Transparent interop discussion + - Jordan: The discussion of transparent interop often falls to (one-way: importing CJS in ESM) and discussing if it should support named exports by default or a loader. + - Jeremiah: Are we talking about resolving to ESM in `require` via promise? + - Jordan: Let’s defer that until we agree if `require` ESM is a thing we want to do + - Gil: We have `require` for ESM by way of dynamic import() + - Gil: I think we can’t have synchronous import via `require` since the current Node implementation is async and may lock-in to async with top-level await. + - Bradley: I like Jordan’s idea to defer talking about `require` and ESM + - Bradley: Must allow static import to load CJS for significant execution order (state, etc.) + - Myles: What are the goals of transparent interop? Bradley mentioned a goal of maintaining the ability to have execution order. Jordan has mentioned a goal that transitioning between ecosystems. Let’s brainstorm them. We can talk about the risks too. + - Wes: The ability to have some overlap between the APIs a CJS and ESM module can expose (Easier to migrate to ESM). + - Jeremiah: I would like to mitigate as much as possible either CJS or ESM being treated as second class to the other. + - Gil: Currently we can’t be truly transparent because named exports may change execution order + - Saleh: Some clarity on the migration. For example, are we shifting users from CJS to ESM? We should have a predictable path forward and clarity of milestones. I believe we should encourage users to migrate to ESM. + - Bradley: I have to comments. RE Gil: I think named exports is an anti-goal. I want to defer named exports since it’s a breaking change. + - Guy: RE Gil: I don’t think it’s valid. It’s possible to have goals that are inconsistent with each other. It’s about trade-offs. Named exports and execution interleaving may work out. Do we have an update on execution order an named exports? + - Myles: Nothing to update on that front. + - Wes: 2nd’ing Bradley. With CJS -> default is a valid upgrade path, though the larger the overlap the easier the transition. + - Daniel: Users want an easy transition. + - Myles: I want to list some anti-goals. + - Confusing errors (named exports) + - Hard to teach + - We should be cautious introducing a goal that is not supported by the web by default + - Bradley: Clarify anti-goal, goal, pro/con. + - Jordan: +1 and expand on Guy, Wes, Bradley. When I say transparent interop I’m not talking about strict-transparent interop. For me default transparent interop is in service of transition. In 5-10yrs ESM is the default module system. Some level of transparent interop is valuable. Without it I fear people won’t migrate. I think the more we can make the transition smooth the better (for CJS and ESM users) + - Jeremiah: I’d like to add to add to the difficult to teach anti-goal. Having `require` return a promise would be confusing to new users. + - Gil: If we remove transparent interop then .mjs appeal is diminished + - Jordan: With or without transparent interop .mjs is required for ESM by default + - Gil: Making the transition from .js to .js is easier than .js to .mjs + - Jeremiah: Can we come to a shared understanding that perfect transparent interop is not possible? + - Geoffrey: I would like to prioritize avoiding .mjs. We should discuss what the tradeoffs are for dropping it. + - Myles: One of the reasons we need .mjs is because there’s no in source way to detect it. + - Geoffrey: I understand that but the npm proposal shows we can have a way forward. + - Bradley: We should table the extension talk + - Guy: .mjs is useful to solve many transparent interop problems + - Jordan: Could we defer the extension so we can discuss do we want some level of transparent interop at all and if we want it by default + - Geoffrey: I like the loader centric approach to things presented by Myles. I think Node should ship ESM as the default and if you want to load CJS then you’d need to load a CJS loader (or various loaders to gauge the level of transparent interop). The basic CJS loader should be maintained by core. It’s a way of splitting the difference between supporting it by default and not having it in core. + - Bradley: I want to push the topic of loaders out (since we don’t know what they are). I want to raise a concern with the idea is that we ship only ESM in Node. If we migrate to ESM as the default that means no CJS files can be run. It’s a large breaking change so is a support burden. + - Geoffrey: This would only be if the entry point is ESM so the rest would be ESM and you’d need loaders to support CJS. If the entry is CJS then it would behave as it does today. + - Jan: As a quick note having a loader flag works OK if you have your average npm start server but doesn’t work well for CLI tools (!# arguments don’t work). + - Myles: Would dynamically be able to call loaders (at runtime) help? + - Jan: Yes. + - Myles: Is it too soon to dig into transparent interop until we define loaders better? + - Bradley: I would discourage that approach. The ability of loaders is very limited. We should be careful loaders because we have to ship and support these things. Our default implementation should be suitable for the average user without loaders. + - Kevin: Goal 1: A choice of module system of a package does not enforce a choice of module system on another package. Goal 2: We need to not require a package author ship 2 versions of their code. + - Myles: Next meeting we should start with loaders for the first half and then interop for the second. + - Geoffrey: Can we also talk about the implementations forks are working on? + - Myles: Yep! The agenda is editable. From 14329f92cf25d401344e93a9a6f8828d9011e82c Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Tue, 17 Jul 2018 17:04:00 -0700 Subject: [PATCH 057/226] doc: july 11 2018 meeting notes --- doc/meetings/2018-07-11.md | 104 +++++++++++++++++++++++++++++++++++++ 1 file changed, 104 insertions(+) create mode 100644 doc/meetings/2018-07-11.md diff --git a/doc/meetings/2018-07-11.md b/doc/meetings/2018-07-11.md new file mode 100644 index 0000000..6fa4312 --- /dev/null +++ b/doc/meetings/2018-07-11.md @@ -0,0 +1,104 @@ +# Node.js Foundation Modules Team Meeting 2018-07-11 + +* **Recording**: https://www.youtube.com/watch?v=2iNkMhlnYyk +* **GitHub Issue**: https://github.com/nodejs/modules/issues/148 +* **Minutes Google Doc**: https://docs.google.com/document/d/1m1yCbb5A6t8KGy9Ov33I7YNKR_fxMPCIJLC3HymGLS8/edit + +## Present + +- Bradley Farias (@bmeck) +- Geoffrey Booth (@GeoffreyBooth) +- Gus Caplan (@devsnek) +- Guy Bedford (@guybedford) +- Hassan Sani (@inidaname) +- Jan Krems (@jkrems) +- John-David Dalton (@jdalton) +- Jordan Harband (@ljharb) +- Michael Dawson (@mhdawson) +- Michael Zasso (@targos) +- Myles Borins (@mylesborins) +- Saleh Abdel Motaal (@SMotaal) + +## Agenda + +Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. + +### Approving PRs + +None this week + +### Update on Progress ( 10 minute Timebox) + +* Have presentation on loaders. [#135](https://github.com/nodejs/modules/issues/135) + - 3 minute Timebox + - not scheduled yet, might need dedicated time slot + - confusion around loaders & their terminology, presentation meant to clarify the basic concepts and develop a shared language + - prob. 45, could be 30 minutes + - conclusion: put it on for next week +* Initiative: Terminology / Historical Decisions documents [#119](https://github.com/nodejs/modules/issues/119) + - 3 minute Timebox + - looking for additional participation + - initial attempt / draft has been developed but needs more work + - Saleh happy to keep driving it but wants input on the actual content to ensure it’s correct + - issue has been stagnant and progress has been lacking + - no volunteers right now + - myles pretty busy for next week, might be able to jump in afterwards +* Developer Survey [#85](https://github.com/nodejs/modules/issues/85) + - 3 minute Timebox + - open question: should we do an open survey or rather focus on specific stakeholders like bundlers and other ecosystem tools + - could be an important input channel for future discussions + +### Discussion (45 Minutes) + + +* Thinking about deadlines [#123](https://github.com/nodejs/modules/issues/123) + - 10 minute Timebox + - question: what are other members of the WG thinking about the proposed deadlines? + - [bradley] current deadlines aren’t realistic, especially the actual dates. Due to expanded scopes and ongoing discussions, we move the end date back + - [ljharb] our goal shouldn’t be to shipping soon or fast but to make sure that we ship the right thing. We do need to decide on what our first implementation should be and what our constraints should be. Discussion around specific dates is premature + - [jan] we should have milestones at least and we also need to update the community / ecosystem on timing expectations + - [saleh] bigger problem: we’re trying to fit something into the wrong hole. The standard should recognize the trend that we need to separate between the browser and node. Afterwards we can solve building on top of that better standard. In the end our solution has to be biased against *someone* out in the community + - [guy] agreed: we have to be goal oriented, have deliverables, have public status. E.g. What is the status of base-level implementation? W/o further information, community will make assumptions. Talk about phases (initial, loader support, …) and in what order they will come + - [geoffrey] The docs & public info made it look like modules are imminent. Might want to communicate that it isn’t. + - [ljharb] does --experimental-* not help? + - [geoffrey] not in practice, people are used to adding those kinds of flags + - [ljharb] we need to have better education about flag meaning + - [bradley] every time we press ahead with “minimal implementations”, the more work we create in digging into them and picking them apart. Instead we should make choices about trade-offs + - [myles] purpose was not to set explicit deadlines or rushing things. It was more about developing a mental model of how much time various phases take and what might happen when + +* Pull request opened for import.meta.require on core [#130](https://github.com/nodejs/modules/issues/130) + - 10 minute Timebox + - alternative suggestion by myles for doing interop + - [brad] it’s premature to land the PR, there’s an entire different thread (do early errors instead?). There is a moratorium on new features + - [myles] purpose right now is to discuss it + - [brad] first: loader ambiguity. Can a loader determine the format of a certain file? Risk of creating multiple instances of a singleton modules. One in cjs, one in esm. + - [brad] up-babel - takes CJS, turns it into ESM. it has to guess which version of import to use + - [myles] is this only for combination of transparent and import.meta.require + - [brad] no, transparent interop alleviates it. Meta.require makes it look simpler but leads to weird behavior like duplicate singletons + - [saleh] thinking about import.resolve - if there’s import.meta.resolve, you don’t need meta.require because you can always dynamic import. Do others think that would alleviate the concerns? If you can’t resolve something, you won’t require it. Meta.require is not something I’d encourage. Dynamic import using transparent interop to return exports object + - [jan] where does the duplicate imports come from? + - [brad] for example from import(‘x’)/require(‘x’) loading different copies of the source. There is a migration problem + - [jan] isn’t that already a problem with ‘x.mjs’ and ‘x.js’ and import(‘./x’) / require(‘./x’) + - [brad] no, this adds new issues, beyond that + +* Package-Name-Maps a proposal for bare imports in browsers [#51](https://github.com/nodejs/modules/issues/51) + - 10 minute Timebox + - [brad] no matter what we do - we’ll never have 100% web compat. Forcing us into package-name-maps makes us highly dependent on what whatwg decides. We shouldn’t be beholden to choices made for package-name-maps. Matching the web: good. But necessarily through p-n-m + - [ljharb] didn’t look too deeply into p-n-m proposal. Like the idea of having npm generate the map, being able to just use the files in a browser without mutating import paths. Not good for node to use a literal on-disk static mapping file. In favor of keeping directory searching etc. + - [guy] clarify: when thinking about maps & compat. Relative imports w/ file extensions is where compat becomes a hard choice (requires removing the ability to insert extensions) + - [kevin] we shouldn’t try to fix things that aren’t broken. Examples: Node’s resolution mechanism, integration with npm for installing dependencies. No need to rewrite because there’s a proposal to solve a similar problem in the browser + - [geoffrey] if we want an incompatible module system, we already have CJS. understand concerns about being beholden to browser decisions. But users should be able to write code that runs in both big JS systems. Lot of value in consistent behavior, even if the spec doesn’t *require* it and it might prevent some nice features + - [brad] counterpoint to “we can’t have the cake and eat it too”. Node resolution algo has advantages. See: angular app that needed to change for minimal impl. Tools are already required for code the ecosystem is writing. There’s a strange thing: why propose things that require tools and then require not using tools? + - [ljharb] web compat is a big goal, but it’s not the whole story. Even without web compat it’s an important feature to be added to node. Might require tools for use in browser + - [geoffrey] examples for maps are pretty short simple files. For things like jquery they can easily be written by hand. There are use cases where people won’t need a build tool in all cases. You can create package.json by hand just like you can create a *map by hand + - [gus (in chat)] that map isn’t so simple, it has to hold **all** the bare specifiers an application uses, not just the ones your top-level code uses. + - [saleh] haven’t looked at details yet. Have used TS path mapping recently: relating a name to a path which is then used to resolve imports. We should all get more familiar with the challenges *maps might bring. Should talk about more details in the future - dedicated issue for discussion? + - [myles] important: what kind of user experience do we want to have? Design to be forward-thinking. Might be CJS patterns - or new patterns. Re maps: no direct support necessarily but resolution algo compatible with them. When talking about browsers: lots of talk about browsers as leaders who not listen and node as follower. We should shift that relationship to be more of a partnership. Participation in those conversations is important + - [jan] more features means more complexity. And those complexities tend to stack up. Removing features & complexities from the old system and not bringing it into the new one can be an opportunity. + - [brad] already problems with things like redirects breaking import.meta.url which is an open issue. Using name maps still allows all kinds of complexity! + - [guy] PR 3172 file extension - how does that enable package map compat? Should we have a vote? Should we add it to the agenda? + - [myles] as a group we have a lot of conversation and are being very thorough. But - how are we moving forward? We need to reach consensus. Challenge: as a group we might want to become chartered. Not being able to reach consensus might prevent that. We wouldn’t want to constantly escalate to voting and pushing to TSC. If it doesn’t seem like this group can get consensus in the future - what does this mean? How can we get there? + - [brad] BUT THERE’S HOPE! We’re here and talking about it. + +* transparent-or-not interop [#90](https://github.com/nodejs/modules/issues/90) + - Skipped this week due to time concerns From 69eb69461d1b949a33d1a1796a3e644ba1b9a57d Mon Sep 17 00:00:00 2001 From: Sendil Kumar N Date: Sat, 28 Jul 2018 01:47:16 +0200 Subject: [PATCH 058/226] Add Sendil Kumar as an observer MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit I am from Webpack and RustWasm team. 😄 --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 9815681..874fcff 100644 --- a/README.md +++ b/README.md @@ -97,6 +97,7 @@ Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUz - [@refack](https://github.com/refack) - Refael Ackermann - [@robwormald](https://github.com/robwormald) - Rob Wormald - [@tbranyen](https://github.com/tbranyen) - Tim Branyen +- [@sendilkumarn](https://github.com/sendilkumarn) - Sendil Kumar - [@TheLarkInn](https://github.com/TheLarkInn) - Sean Larkin - [@TimothyGu](https://github.com/TimothyGu) - Timothy Gu - [@WebReflection](https://github.com/WebReflection) - Andrea Giammarchi From adb6cc6587ae5a981f81b20bb054e01cd416d345 Mon Sep 17 00:00:00 2001 From: Sendil Kumar N Date: Sun, 29 Jul 2018 00:38:13 +0200 Subject: [PATCH 059/226] maintain alphabetical ordering --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 874fcff..ee52002 100644 --- a/README.md +++ b/README.md @@ -96,8 +96,8 @@ Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUz - [@jasnell](https://github.com/jasnell) - James M Snell - [@refack](https://github.com/refack) - Refael Ackermann - [@robwormald](https://github.com/robwormald) - Rob Wormald -- [@tbranyen](https://github.com/tbranyen) - Tim Branyen - [@sendilkumarn](https://github.com/sendilkumarn) - Sendil Kumar +- [@tbranyen](https://github.com/tbranyen) - Tim Branyen - [@TheLarkInn](https://github.com/TheLarkInn) - Sean Larkin - [@TimothyGu](https://github.com/TimothyGu) - Timothy Gu - [@WebReflection](https://github.com/WebReflection) - Andrea Giammarchi From 2bbdc4a3410aa6eb03c952e60842b3d2b1eb619a Mon Sep 17 00:00:00 2001 From: Guy Bedford Date: Wed, 18 Jul 2018 10:27:45 +0200 Subject: [PATCH 060/226] Feature terminology adjustments --- README.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/README.md b/README.md index ee52002..31fbd51 100644 --- a/README.md +++ b/README.md @@ -22,7 +22,6 @@ Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUz - No refactoring ([#87](https://github.com/nodejs/modules/issues/87)) - Pluggable Loaders to support multiple use cases ([#82](https://github.com/nodejs/modules/issues/82)) - Named exports when importing CJS ([#81](https://github.com/nodejs/modules/issues/81)) -- Dual-goal packages ([#93](https://github.com/nodejs/modules/issues/93)) - Multi-mode packages ([#94](https://github.com/nodejs/modules/issues/94)) - Code coverage/instrumentation ([#95](https://github.com/nodejs/modules/issues/95)) - Runtime loaders, transpilation at import time ([#96](https://github.com/nodejs/modules/issues/96)) @@ -34,7 +33,7 @@ Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUz - Tree shaking ([#102](https://github.com/nodejs/modules/issues/102)) - File / path / URL resolving ([#103](https://github.com/nodejs/modules/issues/103)) - Retrievable module metadata ([#104](https://github.com/nodejs/modules/issues/104)) -- Transparent migration ([#105](https://github.com/nodejs/modules/issues/105)) +- Consumer-agnostic imports ([#105](https://github.com/nodejs/modules/issues/105)) - WASM modules ([#106](https://github.com/nodejs/modules/issues/106)) - Browser and Node compatibility without building ([#107](https://github.com/nodejs/modules/issues/107)) - Browser-compatible build that includes CommonJS ([#108](https://github.com/nodejs/modules/issues/108)) From ffe05e5b7f7e4d94da9cac15fc8f3afbae840e23 Mon Sep 17 00:00:00 2001 From: Guy Bedford Date: Wed, 18 Jul 2018 10:37:56 +0200 Subject: [PATCH 061/226] Update README.md --- README.md | 1 - 1 file changed, 1 deletion(-) diff --git a/README.md b/README.md index 31fbd51..3662220 100644 --- a/README.md +++ b/README.md @@ -42,7 +42,6 @@ Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUz - Package encapsulation ([#111](https://github.com/nodejs/modules/issues/111)) - Don’t break CommonJS ([#112](https://github.com/nodejs/modules/issues/112)) - Conditional imports ([#113](https://github.com/nodejs/modules/issues/113)) -- Import JSON without needing asynchronous syntax ([#114](https://github.com/nodejs/modules/issues/114)) - Importing non-JavaScript files ([#115](https://github.com/nodejs/modules/issues/115)) - Import CommonJS without needing asynchronous syntax ([#116](https://github.com/nodejs/modules/issues/116)) - NodeJS contextual pathing use cases ([#121](https://github.com/nodejs/modules/issues/121)) From b5c5aae8b969fa8829735d116e49356e939b0d5d Mon Sep 17 00:00:00 2001 From: Guy Bedford Date: Wed, 18 Jul 2018 10:41:36 +0200 Subject: [PATCH 062/226] add recent feature proposals --- README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README.md b/README.md index 3662220..62d5bd7 100644 --- a/README.md +++ b/README.md @@ -45,6 +45,8 @@ Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUz - Importing non-JavaScript files ([#115](https://github.com/nodejs/modules/issues/115)) - Import CommonJS without needing asynchronous syntax ([#116](https://github.com/nodejs/modules/issues/116)) - NodeJS contextual pathing use cases ([#121](https://github.com/nodejs/modules/issues/121)) +- ESM in executable files ([#152](https://github.com/nodejs/modules/issues/152)) +- ESM in .js files ([#151](https://github.com/nodejs/modules/151)) ## Members From 2f11f5b267868e63ef30ed102eaa93ca62116edc Mon Sep 17 00:00:00 2001 From: Guy Bedford Date: Wed, 18 Jul 2018 10:44:28 +0200 Subject: [PATCH 063/226] Update README.md --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 62d5bd7..25cffdc 100644 --- a/README.md +++ b/README.md @@ -47,6 +47,7 @@ Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUz - NodeJS contextual pathing use cases ([#121](https://github.com/nodejs/modules/issues/121)) - ESM in executable files ([#152](https://github.com/nodejs/modules/issues/152)) - ESM in .js files ([#151](https://github.com/nodejs/modules/151)) +- Callable resolver ([#157](https://github.com/nodejs/modules/issues/157)) ## Members From 2ad095006af5168a80a0d57c7a63e0b25a128175 Mon Sep 17 00:00:00 2001 From: Guy Bedford Date: Wed, 18 Jul 2018 10:51:50 +0200 Subject: [PATCH 064/226] remove duplicate --- README.md | 1 - 1 file changed, 1 deletion(-) diff --git a/README.md b/README.md index 25cffdc..1b87968 100644 --- a/README.md +++ b/README.md @@ -32,7 +32,6 @@ Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUz - Polyfillability ([#101](https://github.com/nodejs/modules/issues/101)) - Tree shaking ([#102](https://github.com/nodejs/modules/issues/102)) - File / path / URL resolving ([#103](https://github.com/nodejs/modules/issues/103)) -- Retrievable module metadata ([#104](https://github.com/nodejs/modules/issues/104)) - Consumer-agnostic imports ([#105](https://github.com/nodejs/modules/issues/105)) - WASM modules ([#106](https://github.com/nodejs/modules/issues/106)) - Browser and Node compatibility without building ([#107](https://github.com/nodejs/modules/issues/107)) From 82f9a13f0afc9741b3c475fef87efd73e17bea09 Mon Sep 17 00:00:00 2001 From: Guy Bedford Date: Wed, 18 Jul 2018 11:36:34 +0200 Subject: [PATCH 065/226] transparent interop -> import interop --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 1b87968..4a42d73 100644 --- a/README.md +++ b/README.md @@ -28,7 +28,7 @@ Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUz - Arbitrary sources for module source text ([#97](https://github.com/nodejs/modules/issues/97)) - Mock modules (injection) ([#98](https://github.com/nodejs/modules/issues/98)) - Mixed module types within app/module; gradual migration from CommonJS to ESM ([#99](https://github.com/nodejs/modules/issues/99)) -- Transparent interoperability for ESM importing CommonJS ([#100](https://github.com/nodejs/modules/issues/100)) +- Import interoperability for ESM importing CommonJS ([#100](https://github.com/nodejs/modules/issues/100)) - Polyfillability ([#101](https://github.com/nodejs/modules/issues/101)) - Tree shaking ([#102](https://github.com/nodejs/modules/issues/102)) - File / path / URL resolving ([#103](https://github.com/nodejs/modules/issues/103)) From 9585a298480d1d2ea811edf12a85a174a795fba0 Mon Sep 17 00:00:00 2001 From: Guy Bedford Date: Wed, 18 Jul 2018 13:34:22 +0200 Subject: [PATCH 066/226] consumer-agnostic -> agnostic consumer --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 4a42d73..c733ba4 100644 --- a/README.md +++ b/README.md @@ -32,7 +32,7 @@ Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUz - Polyfillability ([#101](https://github.com/nodejs/modules/issues/101)) - Tree shaking ([#102](https://github.com/nodejs/modules/issues/102)) - File / path / URL resolving ([#103](https://github.com/nodejs/modules/issues/103)) -- Consumer-agnostic imports ([#105](https://github.com/nodejs/modules/issues/105)) +- Agnostic consumer imports ([#105](https://github.com/nodejs/modules/issues/105)) - WASM modules ([#106](https://github.com/nodejs/modules/issues/106)) - Browser and Node compatibility without building ([#107](https://github.com/nodejs/modules/issues/107)) - Browser-compatible build that includes CommonJS ([#108](https://github.com/nodejs/modules/issues/108)) From e9181f4afb1acad963a34a7cc0f4d14356f123f0 Mon Sep 17 00:00:00 2001 From: Guy Bedford Date: Wed, 18 Jul 2018 22:05:51 +0200 Subject: [PATCH 067/226] divide features into feature sections --- README.md | 50 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 50 insertions(+) diff --git a/README.md b/README.md index c733ba4..784f053 100644 --- a/README.md +++ b/README.md @@ -15,6 +15,56 @@ Work includes: ## Features +Based on these use cases (#55), our implementation aims to support the following features (subject to change): + +### Baseline Modules Implementation Features: +* Spec compliance (#132) +* Browser equivalence (#133) +* Don’t break CommonJS (#112) +* No refactoring (#87) + +#### Browser Interop: +* Browser and Node compatibility without building (#107) +* Browser-compatible specifier resolution (#109) +* Browser-compatible builds for ESM and CommonJS (#108) + +#### CommonJS Interop: +* Named exports when importing CJS (#81) +* Multi-mode packages (#94) +* Transparent interoperability for ESM importing CommonJS (#100) +* Consumer-agnostic imports (#105) +* Mixed module types within app/module; gradual migration from CommonJS to ESM (#99) +* ESM in .js files (#151) + +### Existing Node.js Features: + +* Importing non-JavaScript files (#115) +* NodeJS contextual pathing use cases (#121) +* ESM in executable files (#152) +* Callable resolver (#157) + +### Loader Features + +* Code coverage/instrumentation (#95) +* Pluggable Loaders to support multiple use cases (#82) +* Runtime loaders, transpilation at import time (#96) +* Arbitrary sources for module source text (#97) +* Mock modules (injection) (#98) +* Specifier resolution customization (#110) +* Package encapsulation (#111) +* Conditional imports (#113) + +### WASM Features: + +* WASM modules (#106) + +### Developer and Tooling Features: + +* File / path / URL resolving (#103) +* Import CommonJS without needing asynchronous syntax (#116) +* Tree shaking (#102) +* Polyfillability (#101) + Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUzQGYbCiVugYBnxE4REBakX29yyo/edit) ([#55](https://github.com/nodejs/modules/issues/55)), our implementation aims to support the following features (subject to change): - Spec compliance ([#132](https://github.com/nodejs/modules/issues/132)) From 41423737d3bea5abf118b60a6279e139d097af15 Mon Sep 17 00:00:00 2001 From: Guy Bedford Date: Wed, 18 Jul 2018 22:06:13 +0200 Subject: [PATCH 068/226] update listing --- README.md | 31 ------------------------------- 1 file changed, 31 deletions(-) diff --git a/README.md b/README.md index 784f053..4e46dbf 100644 --- a/README.md +++ b/README.md @@ -67,37 +67,6 @@ Based on these use cases (#55), our implementation aims to support the following Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUzQGYbCiVugYBnxE4REBakX29yyo/edit) ([#55](https://github.com/nodejs/modules/issues/55)), our implementation aims to support the following features (subject to change): -- Spec compliance ([#132](https://github.com/nodejs/modules/issues/132)) -- Browser equivalence ([#133](https://github.com/nodejs/modules/issues/133)) -- No refactoring ([#87](https://github.com/nodejs/modules/issues/87)) -- Pluggable Loaders to support multiple use cases ([#82](https://github.com/nodejs/modules/issues/82)) -- Named exports when importing CJS ([#81](https://github.com/nodejs/modules/issues/81)) -- Multi-mode packages ([#94](https://github.com/nodejs/modules/issues/94)) -- Code coverage/instrumentation ([#95](https://github.com/nodejs/modules/issues/95)) -- Runtime loaders, transpilation at import time ([#96](https://github.com/nodejs/modules/issues/96)) -- Arbitrary sources for module source text ([#97](https://github.com/nodejs/modules/issues/97)) -- Mock modules (injection) ([#98](https://github.com/nodejs/modules/issues/98)) -- Mixed module types within app/module; gradual migration from CommonJS to ESM ([#99](https://github.com/nodejs/modules/issues/99)) -- Import interoperability for ESM importing CommonJS ([#100](https://github.com/nodejs/modules/issues/100)) -- Polyfillability ([#101](https://github.com/nodejs/modules/issues/101)) -- Tree shaking ([#102](https://github.com/nodejs/modules/issues/102)) -- File / path / URL resolving ([#103](https://github.com/nodejs/modules/issues/103)) -- Agnostic consumer imports ([#105](https://github.com/nodejs/modules/issues/105)) -- WASM modules ([#106](https://github.com/nodejs/modules/issues/106)) -- Browser and Node compatibility without building ([#107](https://github.com/nodejs/modules/issues/107)) -- Browser-compatible build that includes CommonJS ([#108](https://github.com/nodejs/modules/issues/108)) -- Browser-compatible specifier resolution ([#109](https://github.com/nodejs/modules/issues/109)) -- Specifier resolution customization ([#110](https://github.com/nodejs/modules/issues/110)) -- Package encapsulation ([#111](https://github.com/nodejs/modules/issues/111)) -- Don’t break CommonJS ([#112](https://github.com/nodejs/modules/issues/112)) -- Conditional imports ([#113](https://github.com/nodejs/modules/issues/113)) -- Importing non-JavaScript files ([#115](https://github.com/nodejs/modules/issues/115)) -- Import CommonJS without needing asynchronous syntax ([#116](https://github.com/nodejs/modules/issues/116)) -- NodeJS contextual pathing use cases ([#121](https://github.com/nodejs/modules/issues/121)) -- ESM in executable files ([#152](https://github.com/nodejs/modules/issues/152)) -- ESM in .js files ([#151](https://github.com/nodejs/modules/151)) -- Callable resolver ([#157](https://github.com/nodejs/modules/issues/157)) - ## Members From c1f852f7aadff4b540a7c7198bbdd119522217d7 Mon Sep 17 00:00:00 2001 From: Guy Bedford Date: Wed, 18 Jul 2018 22:07:24 +0200 Subject: [PATCH 069/226] Node.js Features -> Node.js Utility Features --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 4e46dbf..d3fa4ea 100644 --- a/README.md +++ b/README.md @@ -36,7 +36,7 @@ Based on these use cases (#55), our implementation aims to support the following * Mixed module types within app/module; gradual migration from CommonJS to ESM (#99) * ESM in .js files (#151) -### Existing Node.js Features: +### Existing Node.js Utility Features: * Importing non-JavaScript files (#115) * NodeJS contextual pathing use cases (#121) From e85a963c1ebc030487cb8ca25df3b6615d38c31d Mon Sep 17 00:00:00 2001 From: Guy Bedford Date: Wed, 18 Jul 2018 22:16:09 +0200 Subject: [PATCH 070/226] update links --- README.md | 60 +++++++++++++++++++++++++++---------------------------- 1 file changed, 30 insertions(+), 30 deletions(-) diff --git a/README.md b/README.md index d3fa4ea..9743886 100644 --- a/README.md +++ b/README.md @@ -18,52 +18,52 @@ Work includes: Based on these use cases (#55), our implementation aims to support the following features (subject to change): ### Baseline Modules Implementation Features: -* Spec compliance (#132) -* Browser equivalence (#133) -* Don’t break CommonJS (#112) -* No refactoring (#87) +* Spec compliance ([#132](https://github.com/nodejs/modules/issues/132)) +* Browser equivalence ([#133](https://github.com/nodejs/modules/issues/133)) +* Don’t break CommonJS ([#112](https://github.com/nodejs/modules/issues/112)) +* No refactoring ([#87](https://github.com/nodejs/modules/issues/87)) #### Browser Interop: -* Browser and Node compatibility without building (#107) -* Browser-compatible specifier resolution (#109) -* Browser-compatible builds for ESM and CommonJS (#108) +* Browser and Node compatibility without building ([#107](https://github.com/nodejs/modules/issues/107)) +* Browser-compatible specifier resolution ([#109](https://github.com/nodejs/modules/issues/109)) +* Browser-compatible builds for ESM and CommonJS ([#108](https://github.com/nodejs/modules/issues/108)) #### CommonJS Interop: -* Named exports when importing CJS (#81) -* Multi-mode packages (#94) -* Transparent interoperability for ESM importing CommonJS (#100) -* Consumer-agnostic imports (#105) -* Mixed module types within app/module; gradual migration from CommonJS to ESM (#99) -* ESM in .js files (#151) +* Named exports when importing CJS ([#81](https://github.com/nodejs/modules/issues/81)) +* Multi-mode packages ([#94](https://github.com/nodejs/modules/issues/94)) +* Transparent interoperability for ESM importing CommonJS ([#100](https://github.com/nodejs/modules/issues/100)) +* Consumer-agnostic imports ([#105](https://github.com/nodejs/modules/issues/105)) +* Mixed module types within app/module; gradual migration from CommonJS to ESM ([#99](https://github.com/nodejs/modules/issues/99)) +* ESM in .js files ([#151](https://github.com/nodejs/modules/issues/151)) ### Existing Node.js Utility Features: -* Importing non-JavaScript files (#115) -* NodeJS contextual pathing use cases (#121) -* ESM in executable files (#152) -* Callable resolver (#157) +* Importing non-JavaScript files ([#115](https://github.com/nodejs/modules/issues/115)) +* NodeJS contextual pathing use cases ([#121](https://github.com/nodejs/modules/issues/121)) +* ESM in executable files ([#152](https://github.com/nodejs/modules/issues/152)) +* Callable resolver ([#157](https://github.com/nodejs/modules/issues/157)) ### Loader Features -* Code coverage/instrumentation (#95) -* Pluggable Loaders to support multiple use cases (#82) -* Runtime loaders, transpilation at import time (#96) -* Arbitrary sources for module source text (#97) -* Mock modules (injection) (#98) -* Specifier resolution customization (#110) -* Package encapsulation (#111) -* Conditional imports (#113) +* Code coverage/instrumentation ([#95](https://github.com/nodejs/modules/issues/95)) +* Pluggable Loaders to support multiple use cases ([#82](https://github.com/nodejs/modules/issues/82)) +* Runtime loaders, transpilation at import time ([#96](https://github.com/nodejs/modules/issues/96)) +* Arbitrary sources for module source text ([#97](https://github.com/nodejs/modules/issues/97)) +* Mock modules (injection) ([#98](https://github.com/nodejs/modules/issues/98)) +* Specifier resolution customization ([#110](https://github.com/nodejs/modules/issues/110)) +* Package encapsulation ([#111](https://github.com/nodejs/modules/issues/111)) +* Conditional imports ([#113](https://github.com/nodejs/modules/issues/113)) ### WASM Features: -* WASM modules (#106) +* WASM modules (#[106](https://github.com/nodejs/modules/issues/106)) ### Developer and Tooling Features: -* File / path / URL resolving (#103) -* Import CommonJS without needing asynchronous syntax (#116) -* Tree shaking (#102) -* Polyfillability (#101) +* File / path / URL resolving (#[103](https://github.com/nodejs/modules/issues/103)) +* Import CommonJS without needing asynchronous syntax (#[116](https://github.com/nodejs/modules/issues/116)) +* Tree shaking (#[102](https://github.com/nodejs/modules/issues/102)) +* Polyfillability (#[101](https://github.com/nodejs/modules/issues/101)) Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUzQGYbCiVugYBnxE4REBakX29yyo/edit) ([#55](https://github.com/nodejs/modules/issues/55)), our implementation aims to support the following features (subject to change): From b2235236c901d38335322bec2cf37e1327c79aec Mon Sep 17 00:00:00 2001 From: Guy Bedford Date: Wed, 18 Jul 2018 22:16:47 +0200 Subject: [PATCH 071/226] fixup --- README.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/README.md b/README.md index 9743886..67fd143 100644 --- a/README.md +++ b/README.md @@ -15,7 +15,7 @@ Work includes: ## Features -Based on these use cases (#55), our implementation aims to support the following features (subject to change): +Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUzQGYbCiVugYBnxE4REBakX29yyo/edit) ([#55](https://github.com/nodejs/modules/issues/55)), our implementation aims to support the following features (subject to change): ### Baseline Modules Implementation Features: * Spec compliance ([#132](https://github.com/nodejs/modules/issues/132)) @@ -65,8 +65,6 @@ Based on these use cases (#55), our implementation aims to support the following * Tree shaking (#[102](https://github.com/nodejs/modules/issues/102)) * Polyfillability (#[101](https://github.com/nodejs/modules/issues/101)) -Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUzQGYbCiVugYBnxE4REBakX29yyo/edit) ([#55](https://github.com/nodejs/modules/issues/55)), our implementation aims to support the following features (subject to change): - ## Members From 2a882d4ab36817b3b0ab88f49d7628a9e26039ae Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Wed, 1 Aug 2018 15:51:29 -0400 Subject: [PATCH 072/226] chore: update member list with ncu --- README.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/README.md b/README.md index 67fd143..d719f83 100644 --- a/README.md +++ b/README.md @@ -72,7 +72,6 @@ Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUz - [@benjamingr](https://github.com/benjamingr) - Benjamin Gruenbaum - [@benjamn](https://github.com/benjamn) - Ben Newman - [@bmeck](https://github.com/bmeck) - Bradley Meck -- [@ceejbot](https://github.com/ceejbot) - C J Silverio - [@chrisdickinson](https://github.com/chrisdickinson) - Chris Dickinson - [@DanielRosenwasser](https://github.com/DanielRosenwasser) - Daniel Rosenwasser - [@devsnek](https://github.com/devsnek) - Gus Caplan @@ -85,9 +84,7 @@ Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUz - [@jdalton](https://github.com/jdalton) - John-David Dalton - [@jkrems](https://github.com/jkrems) - Jan Olaf Krems - [@justinfagnani](https://github.com/justinfagnani) - Justin Fagnani -- [@linclark](https://github.com/linclark) - Lin Clark - [@ljharb](https://github.com/ljharb) - Jordan Harband -- [@manekinekko](https://github.com/manekinekko) - Wassim Chegham - [@mcollina](https://github.com/mcollina) - Matteo Collina - [@mduleone](https://github.com/mduleone) - Matt DuLeone - [@mhdawson](https://github.com/mhdawson) - Michael Dawson @@ -96,7 +93,6 @@ Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUz - [@targos](https://github.com/targos) - Michaël Zasso - [@tbjers](https://github.com/tbjers) - Torgny Bjers - [@weswigham](https://github.com/weswigham) - Wesley Wigham -- [@XadillaX](https://github.com/XadillaX) - Khaidi Chu @@ -105,23 +101,28 @@ Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUz - [@bmeurer](https://github.com/bmeurer) - Benedikt Meurer +- [@ceejbot](https://github.com/ceejbot) - C J Silverio - [@dduleone](https://github.com/dduleone) - Dan DuLeone - [@devamaz](https://github.com/devamaz) - Ahmad Abdul-Aziz - [@eugeneo](https://github.com/eugeneo) - Eugene Ostroukhov - [@evanplaice](https://github.com/evanplaice) - Evan Plaice - [@hiroppy](https://github.com/hiroppy) - Yuta Hiroto - [@jasnell](https://github.com/jasnell) - James M Snell +- [@linclark](https://github.com/linclark) - Lin Clark +- [@manekinekko](https://github.com/manekinekko) - Wassim Chegham - [@refack](https://github.com/refack) - Refael Ackermann - [@robwormald](https://github.com/robwormald) - Rob Wormald -- [@sendilkumarn](https://github.com/sendilkumarn) - Sendil Kumar +- [@sendilkumarn](https://github.com/sendilkumarn) - Sendil Kumar N +- [@SMotaal](https://github.com/SMotaal) - Saleh Abdel Motaal - [@tbranyen](https://github.com/tbranyen) - Tim Branyen - [@TheLarkInn](https://github.com/TheLarkInn) - Sean Larkin - [@TimothyGu](https://github.com/TimothyGu) - Timothy Gu +- [@tzmanics](https://github.com/tzmanics) - Tara Z. Manicsic - [@WebReflection](https://github.com/WebReflection) - Andrea Giammarchi +- [@XadillaX](https://github.com/XadillaX) - Khaidi Chu - [@xtuc](https://github.com/xtuc) - Sven Sauleau - [@yosuke-furukawa](https://github.com/yosuke-furukawa) - Yosuke Furukawa - [@zackschuster](https://github.com/zackschuster) - Zack Schuster -- [@tzmanics](https://github.com/tzmanics) - Tara Z. Manicsic - [@zenparsing](https://github.com/zenparsing) - Kevin Smith From 02dd122ad6dc70d9b124e4ba2ecb0f2ca9706371 Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Wed, 8 Aug 2018 15:54:22 -0400 Subject: [PATCH 073/226] doc: add meetings notes --- doc/meetings/2018-07-18.md | 125 ++++++++++++++++++++++++++++++++++++ doc/meetings/2018-08-01.md | 128 +++++++++++++++++++++++++++++++++++++ 2 files changed, 253 insertions(+) create mode 100644 doc/meetings/2018-07-18.md create mode 100644 doc/meetings/2018-08-01.md diff --git a/doc/meetings/2018-07-18.md b/doc/meetings/2018-07-18.md new file mode 100644 index 0000000..28736a7 --- /dev/null +++ b/doc/meetings/2018-07-18.md @@ -0,0 +1,125 @@ +# Node.js Foundation Modules Team Meeting 2018-07-18 + +* **Recording**: https://www.youtube.com/watch?v=_k63DkTJpUI +* **GitHub Issue**: https://github.com/nodejs/modules/issues/154 +* **Minutes Google Doc**: https://docs.google.com/document/d/1zruFPTN9dIpvSEkStxo4fkPenXTdhsLEVkcmoKlVmOA/edit + +## Present + +- Gus Caplan (@devsnek) +- Jan Krems (@jkrems) +- Ben Newman (@benjamn) (took notes below) +- Michael Dawson (@mhdawson) +- Matt DuLeone (@mduleone) +- Bradley Farias (@bmeck) +- Guy Bedford +- Jordan Harband (@ljharb) +- Geoffrey Booth +- Jeremiah Senkpiel +- Kevin Smith +- Geoffrey Booth (@GeoffreyBooth) +- Saleh Abdel Motaal (@SMotaal) + +## Agenda + +Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. + +### Update on Progress (15 minute Timebox) + +* Pull request opened for import.meta.require on core [#130](https://github.com/nodejs/modules/issues/130) + - 3 minute timebox + - Jordan: philosophical objection to implementing something we haven’t come to consensus on yet +* Thinking about deadlines [#123](https://github.com/nodejs/modules/issues/123) + - 3 minute timebox + - Jordan: this working group wasn’t convened for expediency, so we should make sure we’re shipping the right thing above all else + - Bradley: there’s been a thought going around about starting a very minimal implementation that we can all agree on, so that we can decide about future features one at a time (more so than now) +* Initiative: Terminology / Historical Decisions documents [#119](https://github.com/nodejs/modules/issues/119) + - 3 minute timebox + - Jan: Myles said probably no progress this week, but next week he may have more time + - Guy: let’s get an update on that from Myles next week then +* Developer Survey [#85](https://github.com/nodejs/modules/issues/85) + - 3 minute timebox + - Guy: goal should be to create agenda items to discuss in these meetings, and also iterate on between meetings + - Michael Dawson: a GitHub issue would make it easier for folks to add ideas asynchronously + - Bradley: survey shouldn’t just be about user expectations, since we can violate those in service of meeting user needs +* Features List Adjustments #156 + - 3 minute timebox + - Guy: removing duplicates and flagging features that weren’t on the README page + - Unfortunately don’t have a quorum to merge PRs + +### Discussion + +* Package-Name-Maps a proposal for bare imports in browsers [#51](https://github.com/nodejs/modules/issues/51) + - 5 Minute Timebox + - Jordan: summarizing: + - Static file that declaratively tells the browser how to resolve bare specifiers to final URLs + - Has nested structure (scopes) to support deep imports from packages + - Should be easy to create to adapt Node code to browsers + - Question: Should Node provide support for optional package name maps, too? + - Bradley: + - Folks are making assumptions about the limits of package name maps without fully investigating the feature set + - For example, you *can* resolve directories and missing file extensions + - Michael Dawson: + - How does this fit into overall priorities? Can we think about this later on? + - Geoffrey Booth: + - I’m trying to avoid code that behaves differently in Node and browsers, so package name maps are a compatibility concern for me + - As packages add maps, they could cause breaking changes in resolution, e.g. for code doing deep imports from those packages + - Lots of value in aligning with the browser on this, though + - Bradley: I don’t think this is the same level of compatibility concern + - Always going to be some mismatch between how Node and browsers work, so we should be considering the subset of functionality that works the same in both + - Bigger compatibility problems with caching, import.meta.url, importing JSON, HTML modules + - Node is not a subset of the web + - Using tools to generate package name maps solves some of the problems here + - Guy: + - Package name maps can only map bare specifiers, so ./ specifiers aren’t addressed by the proposal + - Bradley: + - Shouldn’t make Node dependent on what browsers do here + - Other approaches to solve the same problems, such as loader hooks + - Michael Dawson: + - Node probably would not want to allow mapping bare specifiers to external URLs + - Undermines Node’s security model, though it works in browsers + - Guy: Relative import specifiers are one of the big unresolved problems + - Bradley: that’s something the designers of package name maps should think about + - Michael Dawson: + - Maybe we should be providing input to the design of package name maps rather than discussing whether to implement them as-is + - Guy: + - If anybody believes there is something we should prioritize on this front please raise, otherwise might be left until we figure out some of the other issues. +* Have presentation on loaders. [#135](https://github.com/nodejs/modules/issues/135) + - 20 Minute Timebox + - Purpose: get folks to stop thinking of loaders as an amorphous API that allows anything + - Instead, talk about what loaders actually do, and must be able to do + - Discussion: + - MD: Are facades not able to change / add things to the module? + - BF: when we say code is ESM, we don’t touch it, we just load it directly + - MD: Why would we do otherwise? + - BF: Changing the ordering of imports would be an example of not directly importing an ESM module + - BF: We’re following the spec as long as resolution returns an ESM module record + - Proposal: + - Move loaders off the main thread for isolation and performance + - Command line --loader option + - Environment variables + - Per-package loader hooks configured in package.json? (BF in favor) + - Works in user-land currently, though difficult to keep rebasing it against Node master + - See slides + - Differences between this proposal and existing ideas + - See slides + - Issues + - Caching is tricky, since it works so differently in the browser than other tools + - Would prefer to remove caching from the proposal + - Raw amount of time spent doing transformations is significant + - Caching compilation results should therefore be easy/simple + - Can’t solve this problem in this proposal, but should show it can be solved +* transparent-or-not interop [#90](https://github.com/nodejs/modules/issues/90) + - 20 Minute Timebox + - Skipped this due to running out of time + +Saleh Abdel Motaal on terminology document: + +* Not much to say about terminology document progress +* Two documents + - One document went “way overboard” (first draft) + - Another took a different direction with input from other people +* Guy: can we add one of those documents as a link to the list of resources that we maintain? +* Saleh: yes, will create a markdown document in the repo +* Sounds good to everyone + diff --git a/doc/meetings/2018-08-01.md b/doc/meetings/2018-08-01.md new file mode 100644 index 0000000..d69d6f7 --- /dev/null +++ b/doc/meetings/2018-08-01.md @@ -0,0 +1,128 @@ +# Node.js Foundation Modules Team Meeting 2018-08-01 + +* **Recording**: https://www.youtube.com/watch?v=VakyGVeMUpg +* **GitHub Issue**: https://github.com/nodejs/modules/issues/161 +* **Minutes Google Doc**: https://docs.google.com/document/d/11oDyvFSnPp3mkyvr8SwRQTKo4aEu9Z0khIiQKPdT1Yk/edit + +## Present + +- @MylesBorins (Myles Borins) +- @jdalton (John-David Dalton) +- @mduleone (Matt DuLeone) +- @giltayar (Gil Tayar) +- @GeoffreyBooth (Geoffrey Booth) +- @devsnek (Gus Caplan) +- @weswigham (Wesley Wigham) +- @DanielRosenwasser (Daniel Rosenwasser) +- @SMotaal (Saleh Abdel Motaal) +- @mhdawson (Michael Dawson) +- @targos (Michael Zasso) +- @benjamingr (Benjamin Gruenbaum) +- @robpalme (Rob Palmer) + +## Agenda + +Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. + +### Approving PRs (2 Minute Timebox) + +* Add Sendil Kumar as an observer [#159](https://github.com/nodejs/modules/pull/159) + * No objections + +### Update on Progress (10 Minute Timebox) + +* Have presentation on loaders. [#135](https://github.com/nodejs/modules/issues/135) + - 3 minute timebox + * Need to remove modules agenda +* Create Terminology.md [#158](https://github.com/nodejs/modules/pull/158) + - 3 minute timebox + * Last week at a point where it was just Google docs - switched to markdown going forward. + * Anyone who has any different ideas should weigh in. +* Developer Survey [#85](https://github.com/nodejs/modules/issues/85) + - 3 minute timebox + * Not had time to dig into this + * Anyone else have bandwidth to take over this? + * Mostly silence :) + * Conclusion: Let's kick it back to the discussion thread. + +### Discussion (45 Minute Timebox) + +* ESM in .js Files: + - 15 minute timebox + - Proposals for configuring parse goals of files in --experimental-modules [#160](https://github.com/nodejs/modules/pull/160) + - ESM in .js files proposals [#150](https://github.com/nodejs/modules/pull/150) + + * Issues around use-cases where Node can parse a .js file with an ESM parse goal. + * Have come to some consensus that Node needs to support this somehow + * Doesn't mean that we're getting rid of ESM, just that we want to tackle this use-case + * Have some ideas to tackle this. + * Jordan: Agree with Geoffrey's stance; really sounds like this is a mechanism for overriding the default parse goal for a file. + * Bradley: Happy that this is a cooperative approach and would love to see more of this in the group. Whatever we design needs to be well-thought-out, and whatever features we produce shouldn't step on other features' toes. + * Michael: Is there any chance that some of the existing use-cases we have can form the basis of what we want? + * Need to determine which use-cases are satisfied by a given solution. + * Geoffrey: These use-cases started as "these are the things I can't do in `--experimental-modules`". + * Bradley: any implementation won't be flawless, which is why we have so much to discuss. But perhaps we can have some agreed-upon "base" implementation to base off of. + * Like a kernel implementation with bare-bones functionality. + * Myles: perhaps we can spin up an issue that discusses what this is, then adding the other features that we want later. + * Perhaps one discussion would be around making a more restrictive loader. + * May mean that this is a version of the module system nobody would want to use, and would discourage people from using it in production, but would elicit feedback + * Gil: think it's a really good idea; starts up from ES modules and builds consensus slowly. + * Saleh: two points + * Always consider what would happen if we started off with ESM and implemented a CJS loader within ESM. + * Started off thinking this way, but initially wasn't enough bandwidth when first implementing. + * We would need to be careful as to which features are bottlenecks and which features are the essentials + * Myles: have we found consensus? should we table the discussion if so? + * Jordan: we should make sure that we have consensus; doesn't look like we have consensus + * Daniel: sounds good on a surface level, but if you solve each of the other use-cases, unsolved use-cases might be "left behind" and unsolved + * Jordan: Don't care what we ship flagged, but the first unflagged thing we have should *not* be minimal. + * But need to be careful because big userland features that go flagged for a long time gain momentum + * Jeremiah: agree with Daniel and Jordan + * also, unsure how minimal you can get with a big feature like this + * Bradley: idea was that this minimal kernel doesn't ship anywhere + * Gil: Agree with Brad - probably don't even have to have an actual implementation + * Jeremiah: Okay with last few discussion points + * Michael: want to have some place to land code changes - maybe a fork of the repo. + * Myles: can incubate that kernel in the fork. + * Any objections? + * Geoffrey: still want to be able to improve it + * Should probably talk about ideas of deprecation warnings at the next meeting. + +* Features adjustments and grouping [#156](https://github.com/nodejs/modules/pull/156) + - 10 minute timebox + * Think this was just around fine-tuning certain things around the repo. + * Conclusion: consensus around approval + + +* transparent-or-not interop [#90](https://github.com/nodejs/modules/issues/90) + - 10 minute Timebox + * Two ideas: use of `import` interop and `require` interop + * `import` interop = importing CommonJS modules + * `require` interop = requiring ESM modules + * Some people felt that interop is required for a minimal implementation. + * Wesley: if we're talking strong feelings for interop + * First expectation is the ability to require or import things, and that regardless of whether the required/imported module is authored in ESM and CJS. + * Second expectation is the expectation that ESM consumers should be able to get a reasonably similar API regardless of a dependency's format + * Bradley: what do you specifically mean by that? + * Wesley: authors need to be able to upgrade to ESM; ESM consumers need to be able to consume the same way regardless of the library format. + * Jeremiah: some level of interop a requirement, static import of cjs important, note on require-ing esm: considered bad when I had previously consulted JS teacher folks for the TSC in early 2017 (See https://github.com/nodejs/CTC/blob/master/meetings/2017-02-01.md - https://youtu.be/8Snc5lh0VZQ?t=23m29s) + * Myles: some level of interop is definitely expected + * import() from CJS is likely the recommended mechanism for + * Importing Common.js can be supported but shouldn’t be default + * Likely to fracture the ecosystem if we do otherwise. + * Important to specify a MIME type for .mjs + * Brad: Clarify: do you want .js to be reserved for CJS? + * \[\[Fill this in]] + * Gil: require() ESM is a no-go for me: just use await import() -. + * The current implementation enables you to import CJS from ESM, and is called “‘transparent” but it only (correctly!) allows it to come up as a default import. That’s a no go for me too—most transpiled code today assumes “real” transparent interop (i.e. the ability to use named imports), and so this is not very transparent for it. So if we can’t have it real, then let’s not have it at all. + * Jordan: TC39 enthusiastically said they would strive to make sure CJS can interoperate with ESM. + * Bradley: sounds like this isn't something we want in a minimal implementation + * Gil: or any implementation + * Saleh: I don't consider built-in modules to be CJS. + * "static import" vs "dynamic import" is something we should be careful of because it implies a completely different story. + * Bradley: you want to treat static/dynamic imports as separate mechanisms? + * Saleh: It is more that if I am writing cjs and opt to import(…) then it could be a good way to future proof my codebase as I always expect a promise. If I statically import cjs into esm, then I can rely on module.exports.default = with sync or async in play. + * Wesley: If TC39 is willing to grant us the ability to have named imports, we should take advantage of that. + * Daniel: what community fracture did we have in mind before? + * Jeremiah: care about things actually working well for Node, so being able to statically import CJS is very important. + * Myles: not against interop, just not sure if it should be the default + From ffaa0dbe98188cd0be145a459666b81aade1361c Mon Sep 17 00:00:00 2001 From: Guy Bedford Date: Wed, 29 Aug 2018 22:10:51 +0200 Subject: [PATCH 074/226] add @SMotaal to members --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index d719f83..969c760 100644 --- a/README.md +++ b/README.md @@ -90,6 +90,7 @@ Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUz - [@mhdawson](https://github.com/mhdawson) - Michael Dawson - [@MylesBorins](https://github.com/MylesBorins) - Myles Borins - [@robpalme](https://github.com/robpalme) - Rob Palmer +- [@SMotaal](https://github.com/SMotaal) - Saleh Abdel Motaal - [@targos](https://github.com/targos) - Michaël Zasso - [@tbjers](https://github.com/tbjers) - Torgny Bjers - [@weswigham](https://github.com/weswigham) - Wesley Wigham @@ -113,7 +114,6 @@ Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUz - [@refack](https://github.com/refack) - Refael Ackermann - [@robwormald](https://github.com/robwormald) - Rob Wormald - [@sendilkumarn](https://github.com/sendilkumarn) - Sendil Kumar N -- [@SMotaal](https://github.com/SMotaal) - Saleh Abdel Motaal - [@tbranyen](https://github.com/tbranyen) - Tim Branyen - [@TheLarkInn](https://github.com/TheLarkInn) - Sean Larkin - [@TimothyGu](https://github.com/TimothyGu) - Timothy Gu From 461b29fce5ee74149087c42815a1455c8da24382 Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Wed, 12 Sep 2018 17:02:38 -0400 Subject: [PATCH 075/226] doc: sync members with ncu-team Closes: https://github.com/nodejs/modules/issues/176 --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 969c760..50a607c 100644 --- a/README.md +++ b/README.md @@ -113,6 +113,7 @@ Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUz - [@manekinekko](https://github.com/manekinekko) - Wassim Chegham - [@refack](https://github.com/refack) - Refael Ackermann - [@robwormald](https://github.com/robwormald) - Rob Wormald +- [@rubys](https://github.com/rubys) - Sam Ruby - [@sendilkumarn](https://github.com/sendilkumarn) - Sendil Kumar N - [@tbranyen](https://github.com/tbranyen) - Tim Branyen - [@TheLarkInn](https://github.com/TheLarkInn) - Sean Larkin From 31f538e9fe5568920aa446afa3ba1491ae9ca575 Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Thu, 20 Sep 2018 14:44:51 -0500 Subject: [PATCH 076/226] doc: more august notes (#178) --- doc/meetings/2018-08-15.md | 107 +++++++++++++++++++++++++++++++++++++ doc/meetings/2018-08-29.md | 89 ++++++++++++++++++++++++++++++ 2 files changed, 196 insertions(+) create mode 100644 doc/meetings/2018-08-15.md create mode 100644 doc/meetings/2018-08-29.md diff --git a/doc/meetings/2018-08-15.md b/doc/meetings/2018-08-15.md new file mode 100644 index 0000000..0b8da43 --- /dev/null +++ b/doc/meetings/2018-08-15.md @@ -0,0 +1,107 @@ +# Node.js Foundation Modules Team Meeting 2018-08-15 + +* **Recording**: https://www.youtube.com/watch?v=YiXrnHu8BSI +* **GitHub Issue**: https://github.com/nodejs/modules/issues/167 +* **Minutes Google Doc**: https://docs.google.com/document/d/11SQ4Ib5jdyusHPJfGG_aJR2lsTAX1oAiiGklL2EHxhw/edit + +## Present + +- @devsnek (Gus Caplan) +- @mduleone (Matt DuLeone) +- @giltayar (Gil Tayar) +- @GeoffreyBooth (Geoffrey Booth) +- @guybedford (Guy Bedford) +- @MylesBorins (Myles Borins) +- @LJHarb (Jordan Harband) +- @zenparsing (Kevin Smith) +- @jdalton (John-David Dalton) +- @jkrems (Jan Krems) +- @inidaname (Hassan Sani) +- @fishrock123 (Jeremiah Senkpiel) +- @SMotaal (Saleh Abdel Motaal) + +## Agenda + +Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. + +### approving PRs (2 minute timebox) + +* Nominate @SMotaal as an active member [#162](https://github.com/nodejs/modules/issues/162) +* No quorum to nominate... + +### Update on Progress (4 minute timebox) + +* Create Terminology.md [#158](https://github.com/nodejs/modules/pull/158) + - 2 minute timebox + * Saleh is not in the meeting, so we will move to next meeting + +* Developer Survey [#85](https://github.com/nodejs/modules/issues/85) + - 2 minute timebox + * the person responsible is not in the meeting, so we will move to next meeting + +### Discussion (50 minute timebox) + +* Thinking about deadlines [#123](https://github.com/nodejs/modules/issues/123) + - 5 minute Timebox + * Myles: The previous sentiment that we do not want deadlines just so that there will be deadlines. We need to reach consensus without the pressure of deadlines. With that being said, we have been on this for a while, and yet do not have any insight on when we may have something to release without a flag. There are concern from the steering committee that we need to ship. Large organizations want the Node project to ship something so that they will have guidance on how it will work. I believe we should have a goal of shipping without a flag before Node 12, which is about 14 months, and maybe backport it if possible. Anybody has any ideas on this. + * Geoffrey: I don’t have a specific suggestion. + * Saleh: checkpoints, like having a prototype, or having the terminology document. A structural flow of how the checkpoints interdependent, more than the actual dates. +* Jan: I agree with the checkpoints. For me personally, it’s not the dates, but any way of expressing progress would be good. A list of decisions we can make, so that we can see that there is progress. + +* Managing fork and agreed upon minimal kernel [#166](https://github.com/nodejs/modules/issues/166) + - 10 minute timebox +* Myles: this goes well with the next agenda meeting. The decision last meeting was to strip apart the current implementation. Coming to a consensus around what a minimal implementation is that is inclusive to all future implementations. And then create PRs that add to that. There was a discussion on that: fork? Branch? And the other discussion would be what would be part of this. Perhaps milestones around that minimal implementation and additions to it. + * Gus: I want to keep it as close as possible to other core development. There are a lot of concerns when developing other parts of node, so we need to communicate the changes. So I don’t want it as another repo, ideally, but at least communicate the things outside of ourselves. + * Myles: the http/2 implementation was a fork, that was currently rebased. And maybe we should explore that. + * Geoffrey: I’m OK with that. If it would have been my project, I would take the current implementation, move that out to a PR against the core, and then the minimal implementation would be another PR. + * Myles: removing things from master is a non-starter, and it would be a huge disruption to the ecosystem. + * Geoffrey: why? + * Myles: we need to reach consensus, and we can’t create lots of PRs and changes to master, as it will create lots of noise. + * Saleh: whenever I saw the module wrap I thought it could be a native module. If we create a native module that is a separate implementation. If this module would have the same hooks, then we could also port it to other stuff like Electron. We could stay as close to module wrap or as far away as we need. I prefer being close to module wrap. + * jdalton: a repo within the org is fine. We can create multiple branches within it to scope each discussion. That’s what we did with worker, and doing it with REPL. + * Kevin: I also like the fork idea. We need to figure out who’s in charge of rebasing upstream. + * Jan: to the idea of making it into a library that we can install into the existing node, because then people can use it and try it out without building a fork. Huge advantage, but the problem is that it works for the regular import, tricky for dynamic import, and almost impossible for import.meta. We need changes to the v8 api to make this possible. + * Myles: how can we improve that? + * Jan: if we fork, to try out, people will need to build, unless we do nightly. + * Myles: the build people can create nightlies from the fork. + * Jan: yes, but there is a reason why people don’t try out nightly builds. Getting nightly builds will address some of the pain. If we want is as a native module, we need to ???. + * Gus: for the idea of external module, there are things we need to do ???. It would be really cool to do, but it’s not worth pursuing at this moment. + * Saleh: I see this as an opportunity to house clean. When we write isolated modules, we tend to uncover tight couplings that are hidden because it’s all in one repo. Yes, there will be technical challenges, I think it’s high time to clean up things that have happened over the implementations. There are certain things that might be closed. I hope that people buy into the idea of the native module. + * Myles: we can kick off an issue for that, and given that forking seems like the most buyin, we can do that in the fork repo. + * Myles: let’s continue on the discussion of what will be in the minimal implementation. First Gil’s [reading Gil’s issue] + * Gil: it’s basically Myles’ option, but including the regular node module resolution. + * Myles: [reading Myles’ issue]. Do people have any thoughts on this? + * Jan: it would be important what we are trying to prove or try out. For me, a foundation that everyone can agree on, and then start ??? For me, createRequireFunction is ??? * Myles: ??? The idea with createRequireFunction. Import does not have transparent interop, so we need some kind of basic thing to support interop. + * Saleh: ??? I think anything that is node specific for the minimal implementation, might in most cases, ??? + * LJHarb: the hard part is deciding what ships. If the group decides this is important, then fine, but I feel that this is delaying the final implementation. + * Myles: I’ll create the fork and we can iterate on it. + +* ESM in .js files: + - ESM in .js files proposals [#150](https://github.com/nodejs/modules/pull/150) + - [#160](https://github.com/nodejs/modules/pull/160) + - 10 minute timebox + - Proposals for configuring parse goals of files in --experimental-modules + * Myles: Can Geoff update us on this issue? + * Geoffrey: at least for CoffeeScript (and others), they only support .js as output. So there needs some way to treat .js files as ESM. This issue is—should we enable this, and #160 is some suggestions on this. + * Myles: are you implying that every folder with package.json will have a different resolution algorithm. + * Geoffrey: yes. Not sure about resolution, but definitely mapping. All the others assume that determining a package boundary is what is in the PR that enables this. Then the rest of the issue is that the merged final proposal is that there is a new “mimes” field which maps extensions to mime types. This follows the browser method of thinking about it. The final proposal takes that as a starting point, and what some people also wanted was a way to define these through external files as well. So either an object, inline, or an array of strings that are an array of json files. If it starts with “null”, then we erase the default mappings, otherwise we start with the default node mappings. I was kind of hoping that this is something we want to sign on. + * LJHarb: I like the concept. It’s generic and can be per-package. The only concern is that using mime types is confusing. The web does have mime types, but others don’t necessarily understand this. So my preference is mapping of extension to extensions. But I am all for the idea. + * Myles: question: where do the list of available mimes come from? Is there a list of definitive mime types? Can you do application/typescript? + * Geoffrey: you know the code better than I do. I assume given a mime type, it knows how to treat each file extension. This would be making that more explicit. Instead of saying “for .json do this”, it would say “for application/json do this”. And there would be a mapping. So for all file types that node supports, there would be mime types. And mime types that are not default, maybe the loaders will be able to support this. + * Myles: I believe there is an abstraction that seems a bit ???. To me the mental model that makes more sense is the connection to the loader hooks. I would love to see how that would work and how it fleshes out. + * Saleh: I love the declarative aspect of it. I’m against mime types outside of the browser, but I believe we should address the idea of declaring things in a certain folder. package.json makes sense to use as for this. + * Jan: My problem with the proposal, for me it’s either everyone agrees with the defaults, or everybody adds the same two scaffolding lines everywhere. It feels like something that is opting into complexity and support problems. + +* transparent-or-not interop [#90](https://github.com/nodejs/modules/issues/90) + - 10 minute timebox + * Myles: one of the reason that we are talking about this. Benjamin? + * Benjamin: listening to Geoffrey talking about CoffeeScript, makes me realize that generating new modules and ???. If it’s ESM, we don’t need anything, but if we want to enable using import declarations to import ESM, and for other stuff to get wrapped as ESM modules, then we can just import mymodule.coffee. But if we need import.meta.require, then, I guess I believe there is a future where we don’t need to worry about file extensions and such. + * LJHarb: browsers are definitely going to be using mime types to parse what you import. In browsers it’s either parsed as script or as a module. + * Myles: But the file extension is usually how the server determines mime type. + * Jan: I think it’s problematic to say that everything imported is only ESM. But for most practical purposes the browser has a whitelist of extensions that is allowed to be imported as ESM. + * Jeremiah: I’m not OK that the only way to import is using “import”. Making it so that if we import CJS, it would import CJS and wrap it with an ESM. + * Benjamin: yes, CJS is the exception because it uses the same .js extension as ESM should. But the others, like TypeScript, there is less of a question there and we just need to figure out how to configure this. + * Jan: the problem with enabling importing things like html is that this will be a future backward compatible problem, because we will not in core be able to use that file extension in the future. And it can be really confusing if half of the ecosystem is using one file extension and another is using another file extension for the same purpose. + + [Oops. Meeting got cut off.] + diff --git a/doc/meetings/2018-08-29.md b/doc/meetings/2018-08-29.md new file mode 100644 index 0000000..6d07365 --- /dev/null +++ b/doc/meetings/2018-08-29.md @@ -0,0 +1,89 @@ +# Node.js Foundation Modules Team Meeting 2018-08-29 + +* **Recording**: https://www.youtube.com/watch?v=u9P-nN-FDgA +* **GitHub Issue**: https://github.com/nodejs/modules/issues/172 +* **Minutes Google Doc**: https://docs.google.com/document/d/1DhUZYo8Cw-CNZCnnsV8qVPA0WeK6SH2kt971Rt0DqR0/edit?usp=sharing + +## Present +* Wesley Wigham (@weswigham) +* Daniel Rosenwasser (@DanielRosenwasser) +* Geoffrey Booth (@GeoffreyBooth) +* Bradley Farias (@bmeck) +* Guy Bedford (@guybedford) +* Gus Caplan (@devsnek) +* Saleh Abdel Motaal (@SMotaal) +* John-David Dalton (@jdalton) +* Kevin Smith (@zenparsing) +* Jeremiah Senkpiel (@fishrock123) +* Jordan Harband (@LJHarb) +* Rob Palmer (@robpalme) + +## Agenda + +Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. + +### approving PRs (2 minute timebox) + +* Nominate @SMotaal as an active member [#162](https://github.com/nodejs/modules/issues/162) + +### Update on Progress (5 minute timebox) + +* Create Terminology.md [#158](https://github.com/nodejs/modules/pull/158) + - 2 minute timebox +* Developer Survey [#85](https://github.com/nodejs/modules/issues/85) - proposal - https://github.com/nodejs/modules/issues/173 + - 2 minute timebox + - Don't have any specifics in mind on what we want to know with this survey, but a systematic process could help us get started. + - Someone who comes from this forum will already have information about the survey contents. + - Don't want to write this survey in one person's frame of reference. + - When you ask questions in a particular way, this can sway how people perceive the question and how they'll answer. +- next step: get 4-8 people involved in iterations for the survey + +### ECMAScript Modules PRs (25 minute timebox) + +Extracted from PRs against https://github.com/nodejs/ecmascript-modules prior to the meeting. + +* import.meta.require [#1](https://github.com/nodejs/ecmascript-modules/pull/1) + + * Brad: This fork is something we're putting PRs on, and we explicitly stated the fork might not be pleasant to use. + * We're weighing on whether this fork is something that is "pretty and minimal" or which has more controversial features. + * Geoffrey: Figured initial features would be the least controversial features, and yet this (CJS interop) is the first PR. + * Do we really need this in the first iteration? + * No, but it means that npm is unusable so it's not totally useful. + * Jordan: What's the goal of the implementation? Is it a playground? Is the hard part the implementation? I think the hard stuff is agreeing on stuff, not the implementation. + * Also, what does minimal mean? If it can't work with npm, is it minimal? + * \[\[Someone else has to fill this in, we were having video driver and/or connection issues]] + * Brad: Currently with this implementation, it seems like we're saying the web doesn't matter. + +* remove file extension and directory resolving [#2](https://github.com/nodejs/ecmascript-modules/pull/2) +* default extensions and directory resolving across package boundaries [#4](https://github.com/nodejs/ecmascript-modules/pull/4) + * There's a desire to treat bare names as packages. + * Brad: this is being done in the same name as package name maps, and people are saying "this can be done with ahead-of-time tools". + * Brad: I object to this, not just because the spec is so alpha, but you'd also have to convince me that they're worthwhile. +* remove ".json" default loading [#3](https://github.com/nodejs/ecmascript-modules/pull/3) + * Idea: you can still import from CJS with require, but not with ES modules + * Geoffrey: I recalled that we'd add in importing JSON later on. + * G: instead of removing things, do we need to rethink what we're even going for? + +### Discussion (30 minute timebox) + +* Browser / bundler compatibility [#170](https://github.com/nodejs/modules/issues/170) + * How much should we be tailoring the implementation to the needs of browsers and bundlers? + * Brad: We've seen a miniature version of this feature in past meetings: different people prioritizing different things like existing tools, browsers, and new design space. + * Stripping everything out is the most neutral view of the situation. We need to come to an agreement about what the level of support we care about is. + * Geoffrey: we already came to an agreement on all of this when we came up with a prioritization list. + * Saleh: if we try to turn these questions into something we can ask in the survey, it'd be easier to define the goals. + * Kevin: there will be a lot of programs that *won't* care about programs that work in the browser; we should be considering programs that are written for the the intersection as well as the exclusion as first-class. + * Brad: I want to explicitly state that I think that's a bad idea. Prioritizing one paradigm makes the design space easier. Have to ask how much value is added in this intersection when you consider how it impacts other targets? Choosing one won't lead to all scenarios being ideal, but choosing a prioritized set of paradigms will narrow down the design space, and we have a *very* large design space. + * Guy: If you think about how bundlers work nowadays, they're all based on conventions set by Browserify. Node resolution, importing json, polyfilling process environment variables, etc. - all continued past Browserify. And that was all based on Node. So what we're doing here is setting a precedent for other tools. + * Saleh: While it's good to keep those things in mind, people struggle based on the precedent based on Browserify. + * Wesley: coming at the module design with the mindset that "what people've done with modules is wrong". If I can't continue to do the things + * Bradley: we can't just *do* what Webpack does, or what TypeScript does. We've discussed this for months. There are issues with how the spec is + * Wesley: If the ecosystem is so divorced from the runtime, why are we starting with a different runtime entirely? The idea is we want to capture the existing userbase of Node. + * Going with an intersection is probably the worst thing you can possibly do. I can see two stances: either make things as smooth as possible for Node, or prioritize compatibility with the browser. In either case, you're going to have friction, so the middle ground is going to cause frustration there. +* Brad: what if we can't provide the compatibility compilers have? +* \[\[Fill this in]] +* Jeremiah: the problem with modules the entire time is that we've been stuck in this middle ground. +* Wesley: existing module systems are present and have the goal of emulating modules systems in the ecosystem +* Managing fork and agreed upon minimal kernel [#166](https://github.com/nodejs/modules/issues/166) +* Proposals for configuring parse goals of files in --experimental-modules [#160](https://github.com/nodejs/modules/pull/160) + From 56921171b7cd3838f25eda5fc0709c3a4fd36e18 Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Mon, 1 Oct 2018 21:54:38 -0400 Subject: [PATCH 077/226] doc: 2018.09.12 notes (#186) --- doc/meetings/2018-09-12.md | 103 +++++++++++++++++++++++++++++++++++++ 1 file changed, 103 insertions(+) create mode 100644 doc/meetings/2018-09-12.md diff --git a/doc/meetings/2018-09-12.md b/doc/meetings/2018-09-12.md new file mode 100644 index 0000000..8f8b9a5 --- /dev/null +++ b/doc/meetings/2018-09-12.md @@ -0,0 +1,103 @@ +# Node.js Foundation Modules Team Meeting 2018-09-12 + +* **Recording**: https://www.youtube.com/watch?v=y2Ce_0z5qK4 +* **GitHub Issue**: https://github.com/nodejs/modules/issues/179 +* **Minutes Google Doc**: https://docs.google.com/document/d/1G6siAcmcpza6wyxoMv0cPWlCLpoIoS7duqPSXBu3AIU/edit + +## Present + +- Daniel Rosenwasser @DanielRosenwasser +- MylesBorins, @mylesborins +- Matt DuLeone, @mduleone +- Kevin Smith, @zenparsing +- Michael Zasso, @targos +- Jan Krems, @jkrems +- Sendil Kumar @sendilkumarn +- Geoffrey Booth @GeoffreyBooth +- Wesley Wigham, @weswigham +- Jeremiah Senkpiel @fishrock123 +- Saleh Abdel Motaal @SMotaal +- Guy Bedford @guybedford +- Gus Caplan @devsnek + +## Agenda + +Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. + +## Agenda + +Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. + +### Update on Progress (6 minute timebox) + +* Session at Collab Summit Vancouver [#177](https://github.com/nodejs/modules/issues/177) + * Have time on the agenda specifically to talk about modules in Node + * If you're interested in travel fund/reduced fee for entry, reach out to Myles. +* Create Terminology.md [#158](https://github.com/nodejs/modules/pull/158) + * Would like to introduce a process for coming to consensus of well-understood terms among the group. + +### approving PRs (2 minute timebox) + +* @rubys requesting membership [#176](https://github.com/nodejs/modules/issues/176) + * Welcome to the team! + +### Discussion (40 minute timebox) + +* Thinking about deadlines [#123](https://github.com/nodejs/modules/issues/123) + - 5 minute timebox + - Saleh: Before moving forward with a particular idea, we want to be able to gather input from the community. + - Myles: Growing concerned around our inability to reach consensus. + - If we find ourselves unable to do so, I will step down. + - Context: we've had this working group for ~6 months and had difficulties here. + - Saleh: we have actually found consensus (e.g. the survey) + - Some part of this is due to lack of participation + - But keep in mind everyone has good intentions in this group and we can turn this around. + - Jeremiah: agree with Myles; if we don't see any progress for modules in Node 12, doesn't seem like there's much of a point here. + - Geoffrey: The tools in place for collaboration (e.g. GitHub) doesn't seem fit for what we're doing. + - Also, feel like we need some direction on responsibilities. Who is focusing on what? What are the expectations? + - Also, not sure where to contribute - to the minimal kernel? To the current implementation? And how so? + +* Managing fork and agreed upon minimal kernel [#166](https://github.com/nodejs/modules/issues/166) + - 25 minute timebox + - Had a hard time figuring out what a minimal kernel actually should be. + - Myles: we believe the following should be in a minimal implementation (https://github.com/nodejs/modules/issues/166#issuecomment-420767222) + - a minimal implementation needs to support bare paths (implementation TBD) + - cannot have dynamic path searching (i.e. explicit paths) + - static analysis is important here. + - With respect to CommonJS compatibility, we want to hold off on importing CommonJS modules. + - .js will eventually be able to support modules, but not + - Only support importing ESM + - Jordan: I don't necessarily disagree that this is feasible, but I would feel uncomfortable shipping without dynamic path searching. + - Saleh: Could we add a 3rd bullet list - things we're committed to actually reaching. + - Myles: I don't think we could reach consensus on that. + - Saleh: What about a list of things we acknowledge aren't actually going into this implementation so that people have a good understanding of what's missing. + - Gus: What if we flagged things outside of the minimal codebase? + - Saleh: +1 + - Myles: Only difficult thing is that it makes things messier to send PRs given that you have to account for these different paths. + - Geoffrey: We're conflating "technologically minimal" and "minimal in terms of what we can all agree upon" + - For the former: there are things that we can eventually get to even if we agree it should be done. + - Maybe we could come up with lists here to distinguish + - Saleh: part of the idea with the survey is to get consensus across the group on what we want without having to delegate to a single meeting every 2 weeks. + - Jan: problem is that the survey will consist of individual questions that may not capture the whole picture, or may affect answers to other questions. + - Wesley: are we saying we want to ship options for things we're not sure we want to ship? + - Myles: Sounds like there's a misconception. We're talking entirely about the fork. + - Guy: want to summarize the process this would create going forward and get some checks on assumptions + - My understanding was that we would build a minimal implementation based on an intersection of our consensus + - The process of adding features is to build something that could actually ship, but we are not shipping the minimal kernel itself. + - Myles: do we have any objections on bringing createRequireFunction to Node? + - Someone: I don't know enough about it to be confident. + - Geoffrey: why do we need this in Node if we can land it in our fork? + - Myles: it's generally useful functionality and we'd like to bring something useful to the project. + +* Survey: Initial Draft [#173](https://github.com/nodejs/modules/issues/173) & Developer Survey [#85](https://github.com/nodejs/modules/issues/85) + - 10 minute timebox to Talk about B1 (internal track) + - 5 minute timebox to Talk about C1 (developers track) + - Idea: these surveys are meant to capture consensus given that it is often difficult to participate for reasons such as noise over GitHub. + - Most important thing is that we need tools to reach the consensus we all need. + - Two tracks: B track (internal to this group) and C track (external devs) + - Wesley: what are the action items that these responses are going to drive? + - Saleh: we're getting there, but we need to have more people on the group help out here. + - Myles: if we talk about every feature individually, they may be "good" or "bad", but it's problematic to ask about each feature if they don't have the whole picture/context. + - Don't use the survey as a means of consensus. It's a lens to understand different groups. + - Saleh: hope is that each person who has a set of specific interests will contribute to the survey + - Myles: want to discourage too much process given that we need to ship before JS Interactive From be915fc4d06f51ad52f03783615c0254a1570fde Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Wed, 3 Oct 2018 16:29:55 -0400 Subject: [PATCH 078/226] doc: first pass at minimal-kernel (#180) * doc: first pass at minimal-kernel Refs: https://github.com/nodejs/modules/issues/166 --- doc/plan-for-new-modules-implementation.md | 55 ++++++++++++++++++++++ 1 file changed, 55 insertions(+) create mode 100644 doc/plan-for-new-modules-implementation.md diff --git a/doc/plan-for-new-modules-implementation.md b/doc/plan-for-new-modules-implementation.md new file mode 100644 index 0000000..fd0ce14 --- /dev/null +++ b/doc/plan-for-new-modules-implementation.md @@ -0,0 +1,55 @@ +# Plan for New Modules Implementation + +This document outlines the plan for building a new implementation to support ECMAScript modules in Node.js. The general idea is to start with a “minimal kernel” as Phase 1, which consists of features that the @nodejs/modules group have agreed will be necessary for all potential iterations of our ESM implementation. Phase 1 does _not_ include features that preclude other potential features or implementation approaches; and Phase 1 also does not include some features that should naturally be built in a later phase of development, for example because those features depend on features planned for Phase 1. The minimal kernel/phase 1 is _not_ intended to be merged into Node core or released; it is only a starting point for gradually building layers of consensus. + +At every phase, the following standards must be maintained: + +* Spec compliance ([#132](https://github.com/nodejs/modules/issues/132)): We must always follow the ES spec. +* Browser equivalence ([#133](https://github.com/nodejs/modules/issues/133)): There’s room for debate in specific cases, but in general if Node is doing something that browsers also do, Node should do it in the same way. Alternatively, code that executes in both environments should produce identical results. +* Don’t break CommonJS ([#112](https://github.com/nodejs/modules/issues/112)): We cannot cause breaking changes with regards to CommonJS. + +See also the [features list in the README](https://github.com/nodejs/modules#features). + +## Phase 1: The Minimal Kernel + +These features will be part of the first phase of development: + +* `module.createRequireFromPath` ([nodejs/node#19360](https://github.com/nodejs/node/pull/19360)) is the only way to import CommonJS into an ES module, for now. + - `import.meta.require` fails at runtime as opposed to import time. This is not desireable to all committee members + - Hold off on `import` statements for CommonJS until more progress is made on the dynamic modules spec. + - landed in https://github.com/nodejs/node/commit/246f6332e5a5f395d1e39a3594ee5d6fe869d622 + +* `import` statements will only support files with an `.mjs` extension, and will import only ES modules, for now. + - In a later phase, the intention is to move forward with format databases to map extensions and support multiple use cases. + - No JSON or native modules; `createRequireFromPath` can be used to get these. + +* `import.meta.url`. + - Already in the existing implementation. + +* Dynamic `import()`. + - Already in the existing implementation. + +* Support for built-in modules with named exports + - Already in the existing implementation + +### How will we get from where we are to Phase 1 + +* Remove support in the `import` statement of formats other than ESM: + - No CommonJS. + - No JSON. + - No native modules. + +* Remove dynamic path searching: + - No extension adding. + - No directory resolution, including no support for `index.js` or `index.mjs`. + - No support for `main` field for ESM. + +* Remove current VM implementation + +* Remove current Loader implementation + +These changes are implemented in https://github.com/nodejs/ecmascript-modules/pull/6 + +## Later Phases + +There **will** be future phases. We will **not** ship the code produced by Phase 1. This first phase lacks support for important use cases and will not be released as the new modules implementation. From f6e2bd375c5a105b495a2efe3f8a15891176804a Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Thu, 4 Oct 2018 17:21:58 -0400 Subject: [PATCH 079/226] doc: sync members with ncu-team (#192) --- README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index 50a607c..430e7e4 100644 --- a/README.md +++ b/README.md @@ -72,7 +72,6 @@ Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUz - [@benjamingr](https://github.com/benjamingr) - Benjamin Gruenbaum - [@benjamn](https://github.com/benjamn) - Ben Newman - [@bmeck](https://github.com/bmeck) - Bradley Meck -- [@chrisdickinson](https://github.com/chrisdickinson) - Chris Dickinson - [@DanielRosenwasser](https://github.com/DanielRosenwasser) - Daniel Rosenwasser - [@devsnek](https://github.com/devsnek) - Gus Caplan - [@Fishrock123](https://github.com/Fishrock123) - Jeremiah Senkpiel @@ -83,7 +82,6 @@ Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUz - [@inidaname](https://github.com/inidaname) - Hassan Sani - [@jdalton](https://github.com/jdalton) - John-David Dalton - [@jkrems](https://github.com/jkrems) - Jan Olaf Krems -- [@justinfagnani](https://github.com/justinfagnani) - Justin Fagnani - [@ljharb](https://github.com/ljharb) - Jordan Harband - [@mcollina](https://github.com/mcollina) - Matteo Collina - [@mduleone](https://github.com/mduleone) - Matt DuLeone @@ -94,6 +92,7 @@ Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUz - [@targos](https://github.com/targos) - Michaël Zasso - [@tbjers](https://github.com/tbjers) - Torgny Bjers - [@weswigham](https://github.com/weswigham) - Wesley Wigham +- [@zenparsing](https://github.com/zenparsing) - Kevin Smith @@ -103,12 +102,14 @@ Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUz - [@bmeurer](https://github.com/bmeurer) - Benedikt Meurer - [@ceejbot](https://github.com/ceejbot) - C J Silverio +- [@chrisdickinson](https://github.com/chrisdickinson) - Chris Dickinson - [@dduleone](https://github.com/dduleone) - Dan DuLeone - [@devamaz](https://github.com/devamaz) - Ahmad Abdul-Aziz - [@eugeneo](https://github.com/eugeneo) - Eugene Ostroukhov - [@evanplaice](https://github.com/evanplaice) - Evan Plaice - [@hiroppy](https://github.com/hiroppy) - Yuta Hiroto - [@jasnell](https://github.com/jasnell) - James M Snell +- [@justinfagnani](https://github.com/justinfagnani) - Justin Fagnani - [@linclark](https://github.com/linclark) - Lin Clark - [@manekinekko](https://github.com/manekinekko) - Wassim Chegham - [@refack](https://github.com/refack) - Refael Ackermann @@ -123,7 +124,6 @@ Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUz - [@XadillaX](https://github.com/XadillaX) - Khaidi Chu - [@xtuc](https://github.com/xtuc) - Sven Sauleau - [@yosuke-furukawa](https://github.com/yosuke-furukawa) - Yosuke Furukawa -- [@zackschuster](https://github.com/zackschuster) - Zack Schuster -- [@zenparsing](https://github.com/zenparsing) - Kevin Smith +- [@zackschuster](https://github.com/zackschuster) Zack Schuster From a454f3556d152db7e0a97b3cbe7a020b17723690 Mon Sep 17 00:00:00 2001 From: Ryan Day Date: Wed, 24 Oct 2018 12:15:14 -0700 Subject: [PATCH 080/226] add @soldair to observers (#200) * add soldair to observers hey folks. o/ I'm working on defining a common base for user land loaders. My personal goal is to make loaders to speed up node startup time and make a nice way for these to be implemented. --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 430e7e4..ad1ec2c 100644 --- a/README.md +++ b/README.md @@ -116,6 +116,7 @@ Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUz - [@robwormald](https://github.com/robwormald) - Rob Wormald - [@rubys](https://github.com/rubys) - Sam Ruby - [@sendilkumarn](https://github.com/sendilkumarn) - Sendil Kumar N +- [@soldair](https://github.com/soldair) Ryan Day - [@tbranyen](https://github.com/tbranyen) - Tim Branyen - [@TheLarkInn](https://github.com/TheLarkInn) - Sean Larkin - [@TimothyGu](https://github.com/TimothyGu) - Timothy Gu From f1056139f5e670247ad1edbe116e5ab106fe60f3 Mon Sep 17 00:00:00 2001 From: Saleh Abdel Motaal Date: Wed, 24 Oct 2018 18:36:29 -0400 Subject: [PATCH 081/226] Create Terminology.md (#158) * Create Terminology.md with terms derived from threads * Fix HTML * Add consumer- and author-defined disambiguation * Fix typo * Fix formatting * Add "Stipulative Terms" with one example "Browser Interop" --- doc/Terminology.md | 133 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 133 insertions(+) create mode 100644 doc/Terminology.md diff --git a/doc/Terminology.md b/doc/Terminology.md new file mode 100644 index 0000000..e7500b0 --- /dev/null +++ b/doc/Terminology.md @@ -0,0 +1,133 @@ +Terminology +============ + +This document is used to keep track of common terminology related to modules in [Node.js](https://nodejs.org), focusing primarily on ECMAScript Modules as well as other mainstream module formats. + + + +
+ +Normative Terms +--------------- + +
+ Agnostic Consumers +
+
+ The ability for importer modules to be unaware of the imported module type (CJS vs ESM). This implies that the imported module can be migrated from CJS to ESM without impacting the consumer. + + This term alone does not specify in which direction(s) the agnosticism applies. +
+ +
+ Require Interoperability require() +
+
+ + The ability for a module to import an ESM module using the `require(…)` function. + + The module’s namespace is return directly, i.e. it is not wrapped in a promise. + + If it is impossible to load the graph synchronously, it is intended that the call must throw. +
+ +
+ Import Interoperability import() +
+
+ + The ability for an ESM module to import a CJS module. + + Applies to both static `import … from ` and dynamic `import(…)`. + + This term alone does not specify whether named `exports` are extracted from the CJS exports object. +
+ +
+ Named Exports exportKeys +
+
+ + The ability for a CJS module to elect to expose properties of its `exports` object as fixed set of named exports for use by ESM consumers, as opposed to having a single `export default` equal to the exports object. + + Some forms of CJS are not amenable, e.g. those that dynamically delete properties of the exports object. +
+ +
+ Consumer-defined Disambiguation +
+
+ + When importing a file into an ESM context, the parse goal of the file is determined by the importing module (the consumer). This is often accomplished via syntax, for example by using only `import` statements for ESM or `require` (or other function) for CommonJS. + +
+ +
+ Author-defined Disambiguation +
+
+ + A file or module’s parse goal is included within itself. This is often achieved via a file extension such as `.mjs` or a field in a `package.json` file. Other suggestions have included a `"use module"` directive or unambiguous syntax, such as parsing the file for `import` or `export` statements. + +
+ +Stipulative Terms +----------------- + +
+ Browser Interop +
+
+ + The expectation that a module (namely ES modules) can be written once and be used in both Node.js and a "popular browser" that is "reasonably conforming", beyond the implicit requirements of conformance to the behaviours defined by the ECMAScript specificion. + +
+ +
browser interoperability
+
+ + The stipulation for "browser interoperability" of ES modules here extends to the ability to utilize platform-specific features in such a way that would mitigate any potential for irrecoverable runtime exceptions, such as early errors. This stipulation aims to help encourage ES modules adoption rates for both Node.js and "popular browsers". + + It does not exclude interoperability for runtimes where polyfilling can provide a suitable setting, however, that is neither recommended nor considered to determine "browser interoperability". This stipulation aims to help encourage the "responsible use" of tooling as a vital component of the JavaScript ecosystem. +
+ +
reasonably conforming
+
+ + The stipulation for "reasonably conforming" here excludes browsers that do not conform to the ECMAScript 2015 specification as well as all module specific features defined in subsequent revisions. It also excludes all forms of drafts, non-normative specifications, and recommended specifications that are "not considered" and/or are intentionally "removed" by "popular browsers". +
+ +
popular browsers
+
+ + The term "popular browsers" is intentionally left open to interpretation. +
+ +
+
+ + +
+ + +Deprecated Terms +---------------- + +
+
+ Transparent Interoperability +
+
+ + An imprecise term that refers to some subset of the following independent capabilities: + + 1. [Agnostic Consumers](#agnostic-consumers) (in one or both directions) + 2. [Require Interoperability](#require-interop) + 3. [Import Interoperability](#import-interop) (with or without Named Exports from CJS) +
+
From 329405e35acd01d1b67447840224a94fce37586d Mon Sep 17 00:00:00 2001 From: Geoffrey Booth Date: Wed, 24 Oct 2018 18:39:18 -0700 Subject: [PATCH 082/226] doc: Phase 2 for new modules implementation (#196) * Revisions per call with @MylesBorins, @SMotaal, @jdalton and @GeoffreyBooth * Additional revisions added after 2018-10-24 Module Team Meeting --- doc/plan-for-new-modules-implementation.md | 29 +++++++++++++++++++--- 1 file changed, 26 insertions(+), 3 deletions(-) diff --git a/doc/plan-for-new-modules-implementation.md b/doc/plan-for-new-modules-implementation.md index fd0ce14..7fa33b8 100644 --- a/doc/plan-for-new-modules-implementation.md +++ b/doc/plan-for-new-modules-implementation.md @@ -43,13 +43,36 @@ These features will be part of the first phase of development: - No extension adding. - No directory resolution, including no support for `index.js` or `index.mjs`. - No support for `main` field for ESM. - + * Remove current VM implementation * Remove current Loader implementation These changes are implemented in https://github.com/nodejs/ecmascript-modules/pull/6 -## Later Phases +## Phase 2 + +* Explore design space for virtual module from source + - Potential implementation in: https://github.com/nodejs/ecmascript-modules/pull/8. + +* Improve CommonJS interoperability. + - Refine `createRequireFromPath`. + - See [https://gist.github.com/SMotaal/e73c12bd801d78a3108fa30ecd303676](https://gist.github.com/SMotaal/e73c12bd801d78a3108fa30ecd303676). + +* Define semantics for importing a package entry point, e.g. `import _ from 'lodash'` + - Currently this is only possible via an explicit deep import, e.g. `import _ from 'lodash/index.mjs'`. The idea would be to somehow enable the former syntax. + - `package.json` `module` field? `main` field? + +## Phase 3 + +Phase 3 will tentatively focus on extensible loaders and deliver an environment that allows user-land experimentation. + +We should try to find a loaders solution that supports all items in the [features list in our README](https://github.com/nodejs/modules/#features). + +## Phase 4 + +Phase 4 will include addressing user feedback gathered from the experimentation enabled by Phase 3 and focus on a holistic and complete experience of ESM in Node.js. + +## Future Phases -There **will** be future phases. We will **not** ship the code produced by Phase 1. This first phase lacks support for important use cases and will not be released as the new modules implementation. +TBD. From 3300937f071aa4eb201ec9b26b279101d0d37eb3 Mon Sep 17 00:00:00 2001 From: Guy Bedford Date: Mon, 5 Nov 2018 14:26:17 +0200 Subject: [PATCH 083/226] add format distinction to phase 2 --- doc/plan-for-new-modules-implementation.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/plan-for-new-modules-implementation.md b/doc/plan-for-new-modules-implementation.md index 7fa33b8..0d837cf 100644 --- a/doc/plan-for-new-modules-implementation.md +++ b/doc/plan-for-new-modules-implementation.md @@ -62,6 +62,8 @@ These changes are implemented in https://github.com/nodejs/ecmascript-modules/pu * Define semantics for importing a package entry point, e.g. `import _ from 'lodash'` - Currently this is only possible via an explicit deep import, e.g. `import _ from 'lodash/index.mjs'`. The idea would be to somehow enable the former syntax. - `package.json` `module` field? `main` field? + +* Define semantics for determining when to load sources as CommonJS or ES module for both the top-level main (`node x.js`) and dependency loading. ## Phase 3 From 55a303ee9405193eb926ac1ca41ee74b9e73e6f1 Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Wed, 7 Nov 2018 20:32:26 +0000 Subject: [PATCH 084/226] doc: update members with ncu-team sync --- README.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index ad1ec2c..6252691 100644 --- a/README.md +++ b/README.md @@ -100,6 +100,7 @@ Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUz +- [@bmacnaughton](https://github.com/bmacnaughton) - Bruce MacNaughton - [@bmeurer](https://github.com/bmeurer) - Benedikt Meurer - [@ceejbot](https://github.com/ceejbot) - C J Silverio - [@chrisdickinson](https://github.com/chrisdickinson) - Chris Dickinson @@ -115,8 +116,9 @@ Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUz - [@refack](https://github.com/refack) - Refael Ackermann - [@robwormald](https://github.com/robwormald) - Rob Wormald - [@rubys](https://github.com/rubys) - Sam Ruby +- [@ryzokuken](https://github.com/ryzokuken) - Ujjwal Sharma - [@sendilkumarn](https://github.com/sendilkumarn) - Sendil Kumar N -- [@soldair](https://github.com/soldair) Ryan Day +- [@soldair](https://github.com/soldair) - Ryan Day - [@tbranyen](https://github.com/tbranyen) - Tim Branyen - [@TheLarkInn](https://github.com/TheLarkInn) - Sean Larkin - [@TimothyGu](https://github.com/TimothyGu) - Timothy Gu From 814bb7b0c12bd7d3d4be0bd412bf925e6edd4186 Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Tue, 6 Nov 2018 15:51:29 +0000 Subject: [PATCH 085/226] doc: october meeting notes --- doc/meetings/2018-10-03.md | 110 ++++++++++++++++++++++++++++++++++ doc/meetings/2018-10-24.md | 120 +++++++++++++++++++++++++++++++++++++ 2 files changed, 230 insertions(+) create mode 100644 doc/meetings/2018-10-03.md create mode 100644 doc/meetings/2018-10-24.md diff --git a/doc/meetings/2018-10-03.md b/doc/meetings/2018-10-03.md new file mode 100644 index 0000000..6d666b4 --- /dev/null +++ b/doc/meetings/2018-10-03.md @@ -0,0 +1,110 @@ +# Node.js Foundation Modules Team Meeting 2018-10-03 + +* **Recording**: https://www.youtube.com/watch?v=KJ5sQq9X_e4 +* **GitHub Issue**: https://github.com/nodejs/modules/issues/190 +* **Minutes Google Doc**: https://docs.google.com/document/d/1lJ94nnBEBdwadOXTay-IwgxGzOTg2WFRuHl5dWFJZKA/edit + +## Present + +- Myles Borins (@MylesBorins) +- John-David Dalton (@jdalton) +- Matt DuLeone (@mduleone) +- Wesley Wigham (@weswigham) +- Daniel Rosenwasser (@DanielRosenwasser) +- Rob Palmer (@robpalme) +- Saleh Abdel Motaal (@SMotaal) +- Geoffrey Booth (@GeoffreyBooth) +- Gus Caplan (@devsnek) +- Michael Zasso (@targos) +- Guy Bedford (@GuyBedford) +- Jordan Harband (@ljharb) + +## Agenda + +Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. + +### Update on Progress (5 Minute Timebox) + +* Session at Collab Summit Vancouver [#177](https://github.com/nodejs/modules/issues/177) + - 2 minute timebox + - We'll have a Zoom chat during this. + - No question. +* Terminology + - 2 minute timebox + - Refs: + - Create Terminology.md [#158](https://github.com/nodejs/modules/pull/158) + - Terminology: Stipulative Terms [#184](https://github.com/nodejs/modules/issues/184) + - We were really just dealing with normative terms, but we might want to go deeper in our definitions + - Want to define stipulative terms - a more specialized way to define these ideas. + - Really specific ideas of what we mean when we say something like "browser interop" + +### Discussion (50 Minute Timebox) + +* Surveys + - 15 minute timebox + - Refs: + - Developer Survey [#85](https://github.com/nodejs/modules/issues/85) + - Surveys: Initial Drafts [#173](https://github.com/nodejs/modules/issues/173) + - Surveys: Purpose and Scope [#182](https://github.com/nodejs/modules/issues/182) + - Have time between Tuesday and Thursday to work on this. + - Didn't have a great way to get input on the survey. + - Idea: ask 3-4 people at the summit for their perception of the survey to get an idea of what we could do better. (e.g. asking questions differently, clarifying meaning of questions). + - Have a unique group who we can check with. + +* Minimal Kernel + - 30 minute timebox + - Refs: + - doc: first pass at minimal-kernel [#180](https://github.com/nodejs/modules/pull/180) + - Minimal kernel [ecmascript-modules#6](https://github.com/nodejs/ecmascript-modules/pull/6) + - Any objections to the current functionality in the minimal kernel? + +* Lack of quorum + - Do we need some people to step down to observer status? + - Also, want people to move from observer to members! + - Ironically, need to have quorum to make some changes to get easier quorum. + +* APIs around require + - Has anyone had any thoughts around the `createRequireFunction` APIs? + - There's a set of common scenarios that require composing several other existing APIs + - Wesley: Someone else is going to do this, so maybe it'd make sense to build it into core. + - Gus: import() also should subsume these scenarios. + - Myles: there will be scenarios where people want a dynamic CJS module to come in as something that's not a module. + - Gus: yes, but that's not the common scenario. + - Geoffrey: I just don't see what the use-case is here for modules. + - Gus: This was originally to solve a use-case around tooling - it can be used in an all CJS environment. + - Rob: a lot of people use `require(...)` for lazy synchronous loading, so it definitely has a use-case. + +Guy Bedford arrived! We have quorum! + +* Proposals + - Moving Kevin Smith to an active member + - Unanimous! + - Landing PR [#180](https://github.com/nodejs/modules/pull/180) + - Unanimous! + - [ecmascript-modules#6](https://github.com/nodejs/ecmascript-modules/pull/6) + - Unanimous! + +* Phases + - Myles: Sounds like we can start moving into phase 2 + - Wesley: phase 2 is when we do things that could potentially block things off in the future, right? + - Myles: potentially! But it could just be a phase where we make things more ergonomic, but not necessarily blocking. + - Rob: a document would be the most efficient way of aggregating feedback from the group. + - Geoffrey: \[\[return to this]] + - Myles: do you think writing inline MIME types is the most ergonomic option? + - Geoffrey: this is the current design; if there are any other ideas, provide feedback + - Myles: there are several people who are focused around loaders. Probably a good idea to get those people discussing their vision around loaders in the next meeting. + - Saleh: one problem with --experimental-modules is that without module graph optimizations, things might not be good enough. + - Jordan: what's your criteria for "good enough"? We already have people using babel-node and ts-node, and while they're relatively slow, many people consider them good enough. + - Is this a question of native vs. JS? + - Really just want performance to be a key concern. + - Myles: everything that goes into Node core has a lot of scrutiny on performance. + - Saleh: as we consider loaders, we should envision how they might work in the browser and how they could come with a standard. + - Jan: Thinking about package name maps might be better to think of sooner rather than later. + - Myles: direct support could be done via a loader, so not necessarily mutually exclusive + - Jordan: it's insanely premature to do work around announcements for yarn pnp or tink/crux + - Kevin: It's an exciting time! We should experiment with these different ideas. + - Myles: Wesley said that pnp/tink are like incremental caches, but they're also hijacking the resolution process to do this. This kind of gives a strong signal that there's a need for experimentation. +- Proposal: + - Phase 2: Uncontroversial things not related to loaders + - Phase 3: Flexible loaders that allow experimentation/learning to inform Phase 4 + - Phase 4: Hard decisions (things that may exclude certain use-cases) diff --git a/doc/meetings/2018-10-24.md b/doc/meetings/2018-10-24.md new file mode 100644 index 0000000..bc733e9 --- /dev/null +++ b/doc/meetings/2018-10-24.md @@ -0,0 +1,120 @@ +# Node.js Foundation Modules Team Meeting 2018-10-24 + +* **Recording**: https://www.youtube.com/watch?v=WES0lGeneNs +* **GitHub Issue**: https://github.com/nodejs/modules/issues/206 +* **Minutes Google Doc**: https://docs.google.com/document/d/10HOj79n61bSGXEh6CKfaeB4mc0KW4wwB_EsTh6MVs1k/edit + +## Present + +- Myles Borins (@MylesBorins) +- Matt DuLeone (@mduleone) +- Geoffrey Booth (@GeoffreyBooth) +- John-David Dalton (@jdalton) +- Daniel Rosenwasser (@DanielRosenwasser) +- Gil Tayar (@giltayar) +- Saleh Abdel Motaal (@smotaal) +- Gus Caplan (@devsnek) +- Michael Zasso (@targos) +- Rob Palmer (@robpalme) +- Jordan Harband (@ljharb) + +## Agenda + +Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. + +### Approving PRs (7 Minute Timebox) + +* add @soldair to observers [#200](https://github.com/nodejs/modules/pull/200) + - consensus +* Create Terminology.md [#158](https://github.com/nodejs/modules/pull/158) + +### Update on Progress (8 Minute Timebox) + +* Terminology: Stipulative Terms [#184](https://github.com/nodejs/modules/issues/184) + - 4 minute timebox +* Surveys: + - 4 minute timebox + - Refs: + - Purpose and Scope [#182](https://github.com/nodejs/modules/issues/182) + - Initial Drafts [#173](https://github.com/nodejs/modules/issues/173) + - Developer Survey [#85](https://github.com/nodejs/modules/issues/85) + +### Discussion (40 Minute Timebox) + +* Doc: Phase 2 for new modules implementation [#196](https://github.com/nodejs/modules/pull/196) + - 30 minute timebox + +* keeping ecmascript-modules up to date [#197](https://github.com/nodejs/modules/issues/197) + - 5 minute timebox +* Discussion about an implicit (or explicit) "node" scheme [#169](https://github.com/nodejs/modules/issues/169) + - 5 minute timebox + +* Update on Dynamic Modules [#188](https://github.com/nodejs/modules/issues/188) + - Guy Bedford needed to drop, punted to next meeting + +## 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. + +* Terminology: Stipulative Terms [#184](https://github.com/nodejs/modules/issues/184) + - Saleh: We created a branch that's been out for a bit now to try to clarify specific terms we want to use within this group. + - Has been enough time for people to object to take a look, so... do that! + - Myles: What's the deal with the deprecated terms? Does that mean we can't use those terms? For example, "transparent interop" is listed there. + - Saleh: Everyone has a different interpretation of transparent interop, so it didn't seem like we were productive using these terms and talking past each other. Maybe "deprecated" is not the right term? + - Myles: as an ask, can we eventually separate out the deprecated section, create a policy around that, and as we make the changes please squash the commits +* Surveys: + - 4 minute timebox + - Refs: + - Purpose and Scope [#182](https://github.com/nodejs/modules/issues/182) + - Initial Drafts [#173](https://github.com/nodejs/modules/issues/173) + - Developer Survey [#85](https://github.com/nodejs/modules/issues/85) + - Saleh: I feel pretty uncomfortable putting questions on the survey that aren't representative of what the group is interested in + - Overall the survey was well-received (in terms of willingness to answer the survey), but the questions themselves need feedback from the group + - Saleh's dog: *barking* (okay, they did) + - Saleh: it would be great if we could iterate more with Google Docs + - Myles: it might be productive to set up a meeting outside of this biweekly discussion + +* Doc: Phase 2 for new modules implementation [#196](https://github.com/nodejs/modules/pull/196) + - 20 minute timebox + - Geoffrey: Idea of phases is "what's the next lowest-hanging fruit that we could start implementing?" + - Finishing any given phase doesn't mean we're done. + - Also, things aren't set in stone. + - Saleh: [fill in here] (see new issue [#208](https://github.com/nodejs/modules/issues/208) + - Bradley: I am against that point, but we can chat offline about that. + - Geoffrey: wanted not to discuss specific technical details here + - Jan: Not sure how I feel about first bullet (virtual module integration), third bullet (importing from package names) has a lot of implied semantics + - `import "lodash/index.mjs"` doesn't work today? + - Myles: think it does, but not totally clear + - Jan: anyway, I don't think any of them should work; otherwise npm and yarn will end up hacking around whatever we do + - Myles: regardless of what happens with the packagers, node_modules, package name maps, etc., throwing away node_modules would cause an ecosystem fracture + - Jan: but how is this different from any other loader we'd want people to use? node_modules resolution seems like it could be part of a custom loader. + - Geoffrey: the idea is just to make bare path importing possible in the first place. + - Bradley: I don't know how we're going to make this possible without *some* default. If we can't come to consensus on that default, then we need to push out of stage 2 + - Kevin: what if we swapped phase 2 with phase 3? That might give us some clarity over the points in stage 2. + - Are we ready to talk about loaders? Do we have an implementation? + - Bradley: they exist ephemerally but we really need people to raise loaders as a discussion point - not enough people are talking about them. + - Myles: maybe stage 2 could be a stage of things that are completely unrelated to loaders. + - Gil: Clarification: what are "virtual modules"? + - Saleh: a module that doesn't exist on disk, but that can be created from some source text. For example, want to create a "virtual" module from a service worker. + - Jan: Overall, ideally we'd have some sort of default loader that builds on Node loader API + - Bradley: Loader spec started in TC39 and was discontinued; Realms proposal has evolved from that and it's a string-based API. If you're interested in why it's bad to introduce arbitrary objects into the module graph, you too can join this group which spends 4 hours a week discussing the matter. + - Objections? + - Only if we're intent on shoving things into the module graph. + - Myles: can we at least say we want to explore it in phase 2, without implying an implementation? + - Can we look at both implementations? + - Bradley: no, don't want to take the decisions here that lightly. People have spent years on this, and we're not even in touch with with Realms people. + - Saleh: I object to something like createDynamicModule (if loaders can’t evaluate ESM) + - Myles: this is probably more implementation-specific than the point implies. Can we at least just say we're exploring? Perhaps engaging with the Realms team as well? + - Do we have any objections? For point 3 (`import _ from "lodash"`) can we just retitle this to something like "exploring supporting" rather than just "supporting"? + - "Explore design space for virtual module from source" + - Point 4 (out-of-band command line disambiguation) doesn't have agreement; changing to "exploring" design space might be too broad. + - Could emulate anything with a bash script. + - Consensus! + +* keeping ecmascript-modules up to date [#197](https://github.com/nodejs/modules/issues/197) + - 5 minute timebox + - Not enough time! From 7a8df4659c7b5e42293764b7b1d694f391a8992e Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Sun, 11 Nov 2018 12:22:29 +0100 Subject: [PATCH 086/226] doc: add notes for 2018-11-07 --- doc/meetings/2018-11-07.md | 112 +++++++++++++++++++++++++++++++++++++ 1 file changed, 112 insertions(+) create mode 100644 doc/meetings/2018-11-07.md diff --git a/doc/meetings/2018-11-07.md b/doc/meetings/2018-11-07.md new file mode 100644 index 0000000..fbfa87f --- /dev/null +++ b/doc/meetings/2018-11-07.md @@ -0,0 +1,112 @@ +# Node.js Foundation Modules Team Meeting 2018-11-07 + +* **Recording**: https://www.youtube.com/watch?v=b8wLboT_A_0 +* **GitHub Issue**: https://github.com/nodejs/modules/issues/217 +* **Minutes Google Doc**: https://docs.google.com/document/d/1PdkHSzthrjBHx3OzUaEL5Vqa2L4WtAs8WdJl_L6HT6E/edit + +## Present + +- Matt DuLeone (@mduleone) +- Gus Caplan (@devsnek) +- Daniel Rosenwasser (@DanielRosenwasser) +- Wesley Wigham (@weswigham) +- Geoffrey Booth (@GeoffreyBooth) +- Myles Borins (@MylesBorins) +- Guy Bedford (@guybedford) +- Ujjwal Sharma (@ryzokuken) +- Michael Zasso (@targos) +- Jordan Harband (@ljharb) +- Jan Krems (@jkrems) +- Gil Tayar (@giltayar) + +## Agenda + +Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. + +### Approving PRs (12 minute timebox) + +* Add @ryzokuken as Observer [#213](https://github.com/nodejs/modules/issues/213) + - 1 minute timbox + - No objections. +* @bmacnaughton requesting membership/observer [#211](https://github.com/nodejs/modules/issues/211) + - 1 minute timbox + - No objections. +* esm: refactor dynamic modules [#9](https://github.com/nodejs/ecmascript-modules/pull/9) + - 5 minute timebox + - Gus: Was able to avoid a double module wrap - no behavioral change, just an optimization. + - Awkward silence? + - Myles has dropped out of the call - Brad is the host now! + - Any objections? + - Nope. + - Action item: Gus, can you land this and upstream it? +* Add format distinction to phase 2 [#215](https://github.com/nodejs/modules/pull/215) + - 5 minute timebox + - Guy: at the moment we only have support for top-level execution of ES Modules and you can only import ES modules. + - Trying to provide a distinction for formats in which a module can be imported - want to move this into the phase 2 discussions. + - Action item: Guy can you land the PR and lead the discussions? + +### Update on Progress (1 minute timebox) + +* Surveys: Members formally taking ownership (leadership) is the next step [#209](https://github.com/nodejs/modules/issues/209) + - 1 minute timebox + - Saleh: As a group we must decide how we want to proceed with the survey. + - Must find a way to distribute work in the group for this. + - Jan: is there a list of things that still need to be done? + - Saleh: just simply need people to drive questions they want answered. + +### Discussion (40 Minute Timebox) + +* keeping ecmascript-modules up to date [#197](https://github.com/nodejs/modules/issues/197) + - 10 minute timebox + - Myles: this repository hasn't been actively rebased against `master` + - Silence + - Myles: as a suggestion, let's rebase and allow force rebases on the fork + - Guy: force rebase is kind of hard to review; can we do a 2-branch master for reviews? + - Jordan: ideally these things should be fast-forward rebased so that we can stay as close as possible to the original history. + - Action item: Ryzo will write up a proposal for the process in mind. +* Dynamic Modules Status [#188](https://github.com/nodejs/modules/issues/188) + - 10 minute timebox + - Guy: Gus originally wrote a PR to support importing from CJS + - It was blocked because in the spec it appeared that you need to know the named exports ahead of time. + - But CJS modules don't have statically analyzable imports; you need to run the module to know what's available. + - TC39 is open to allowing exports to be specified during the execution phase. + - Technical changes involve applying TDZ to uninitialized exports. + - Implementation seems to be going well in V8. + - Jordan: got the chance to raise it with TC39 editors group + - Gil: what were the changes in the spec that were needed? + - Guy: Two changes: (1) need to be able to throw during the instantiation phase (in the GetExportedNames function). (2) being able to track namespace records from dynamic modules +* esm resolver spec and implementation refinements [#12](https://github.com/nodejs/ecmascript-modules/pull/12) + - 15 minute timebox + - Guy: want a public resolver spec as a "source of truth" for ESM resolution + - Today + - Error messages aren't that great + - no context on which module caused the error + - no single quotes around the specifier + - doesn't tell you when you try to use an import like a `require()` + - Proposal: provide that information! + - Scoped package resolution: + - Gil: Seems like a potential problem that we'd now be parsing our paths. + - Package resolution keeps walking up the spine, doesn't tell you where you imported from + - Proposal: keep the first node_module path you hit for a deep import, then stop. + - Brad: when we looked through who was using it, we found exactly one hard dependency. +* Explicit package exports proposal (https://github.com/jkrems/proposal-pkg-exports) + - 5 minute timebox (if there is time) + - Jan + - Bare imports behavior is very, well, bare. + - People don't typically use extensions. + - Multiple independent APIs in a single package. + - First draft of a proposal. + - Declare what the public interface is via an `"exports"` field in `package.json`. + + ```json5 + "exports": { + "": "./src/moment.mjs", + "/": "./src/util/", + "/timezones/": "./data/timezones/", + "/timezones/utc": "./data/timezones/utc/index.mjs" + } + ``` + + - Brad: I would like to see how to deal with multiple "modes" (e.g. GraphQL). + - GraphQL introduced multiple modes and ended up eventually splitting into two different packages. + From da826d8b40c90555124521086e998b877e6a8979 Mon Sep 17 00:00:00 2001 From: Geoffrey Booth Date: Tue, 20 Nov 2018 22:38:13 -0800 Subject: [PATCH 087/226] Add links to proposals --- doc/plan-for-new-modules-implementation.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/doc/plan-for-new-modules-implementation.md b/doc/plan-for-new-modules-implementation.md index 0d837cf..b5666b4 100644 --- a/doc/plan-for-new-modules-implementation.md +++ b/doc/plan-for-new-modules-implementation.md @@ -62,8 +62,11 @@ These changes are implemented in https://github.com/nodejs/ecmascript-modules/pu * Define semantics for importing a package entry point, e.g. `import _ from 'lodash'` - Currently this is only possible via an explicit deep import, e.g. `import _ from 'lodash/index.mjs'`. The idea would be to somehow enable the former syntax. - `package.json` `module` field? `main` field? + - Proposal: [“Package Exports” proposal](https://github.com/jkrems/proposal-pkg-exports) for bare module specifier resolution of ESM packages. + - Proposal: [“File Specifier Resolution” proposal](https://github.com/GeoffreyBooth/node-import-file-specifier-resolution-proposal) mentions bare module specifier resolution of CommonJS packages; complements Package Exports proposal. * Define semantics for determining when to load sources as CommonJS or ES module for both the top-level main (`node x.js`) and dependency loading. + - Proposal: [“File Specifier Resolution” proposal](https://github.com/GeoffreyBooth/node-import-file-specifier-resolution-proposal) covers `import` statements of ESM files; and CommonJS files, package entry point and package deep imports. ## Phase 3 From fab6385896824a23f44ac9029e9c728ffbbe14ba Mon Sep 17 00:00:00 2001 From: Geoffrey Booth Date: Tue, 20 Nov 2018 22:38:36 -0800 Subject: [PATCH 088/226] Add links from main README to new implementation repo and roadmap --- README.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/README.md b/README.md index 6252691..64fc766 100644 --- a/README.md +++ b/README.md @@ -13,6 +13,10 @@ Work includes: * Node.js and Browser interoperability * VM Modules implementation +## Current Efforts + +The team is working on a new implementation to potentially replace the `--experimental-modules` implementation in current shipping Node. The new implementation is in progress in the [ecmascript-modules](https://github.com/nodejs/ecmascript-modules) repo, and a road map of its development is [here](./doc/plan-for-new-modules-implementation.md). + ## Features Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUzQGYbCiVugYBnxE4REBakX29yyo/edit) ([#55](https://github.com/nodejs/modules/issues/55)), our implementation aims to support the following features (subject to change): From 04aca8219883bf35da159f68643cff3137500e04 Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Wed, 7 Nov 2018 18:16:22 +0000 Subject: [PATCH 089/226] governance: be explicit about meetings new members can join --- GOVERNANCE.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index 5f95868..b3fe92b 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -33,7 +33,8 @@ There is no specific set of requirements or qualifications for Team Membership b Changes to Team membership should be proposed with an issue and labelled `modules-agenda` to be included in the next [team meeting](#team-meetings). Decisions are made via the -[Consensus Seeking Process](#consensus-seeking-process). +[Consensus Seeking Process](#consensus-seeking-process). If there are not objections in the +issue new members may attend the meeting in which their membership is officially accepted. If a Team member is unable to attend a meeting where a planned membership decision is being made, then their consent is assumed. From 03cf2e2f22e67b5fa9faeed1c75234ee593824f0 Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Thu, 22 Nov 2018 02:39:54 -0500 Subject: [PATCH 090/226] doc: update members with ncu-team (#229) --- README.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index 64fc766..f803717 100644 --- a/README.md +++ b/README.md @@ -74,7 +74,6 @@ Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUz - [@benjamingr](https://github.com/benjamingr) - Benjamin Gruenbaum -- [@benjamn](https://github.com/benjamn) - Ben Newman - [@bmeck](https://github.com/bmeck) - Bradley Meck - [@DanielRosenwasser](https://github.com/DanielRosenwasser) - Daniel Rosenwasser - [@devsnek](https://github.com/devsnek) - Gus Caplan @@ -82,14 +81,11 @@ Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUz - [@GeoffreyBooth](https://github.com/GeoffreyBooth) - Geoffrey Booth - [@giltayar](https://github.com/giltayar) - Gil Tayar - [@guybedford](https://github.com/guybedford) - Guy Bedford -- [@iarna](https://github.com/iarna) - Rebecca Turner - [@inidaname](https://github.com/inidaname) - Hassan Sani - [@jdalton](https://github.com/jdalton) - John-David Dalton - [@jkrems](https://github.com/jkrems) - Jan Olaf Krems - [@ljharb](https://github.com/ljharb) - Jordan Harband -- [@mcollina](https://github.com/mcollina) - Matteo Collina - [@mduleone](https://github.com/mduleone) - Matt DuLeone -- [@mhdawson](https://github.com/mhdawson) - Michael Dawson - [@MylesBorins](https://github.com/MylesBorins) - Myles Borins - [@robpalme](https://github.com/robpalme) - Rob Palmer - [@SMotaal](https://github.com/SMotaal) - Saleh Abdel Motaal @@ -104,6 +100,7 @@ Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUz +- [@benjamn](https://github.com/benjamn) - Ben Newman - [@bmacnaughton](https://github.com/bmacnaughton) - Bruce MacNaughton - [@bmeurer](https://github.com/bmeurer) - Benedikt Meurer - [@ceejbot](https://github.com/ceejbot) - C J Silverio @@ -113,10 +110,13 @@ Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUz - [@eugeneo](https://github.com/eugeneo) - Eugene Ostroukhov - [@evanplaice](https://github.com/evanplaice) - Evan Plaice - [@hiroppy](https://github.com/hiroppy) - Yuta Hiroto +- [@iarna](https://github.com/iarna) - Rebecca Turner - [@jasnell](https://github.com/jasnell) - James M Snell - [@justinfagnani](https://github.com/justinfagnani) - Justin Fagnani - [@linclark](https://github.com/linclark) - Lin Clark - [@manekinekko](https://github.com/manekinekko) - Wassim Chegham +- [@mcollina](https://github.com/mcollina) - Matteo Collina +- [@mhdawson](https://github.com/mhdawson) - Michael Dawson - [@refack](https://github.com/refack) - Refael Ackermann - [@robwormald](https://github.com/robwormald) - Rob Wormald - [@rubys](https://github.com/rubys) - Sam Ruby @@ -131,6 +131,6 @@ Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUz - [@XadillaX](https://github.com/XadillaX) - Khaidi Chu - [@xtuc](https://github.com/xtuc) - Sven Sauleau - [@yosuke-furukawa](https://github.com/yosuke-furukawa) - Yosuke Furukawa -- [@zackschuster](https://github.com/zackschuster) Zack Schuster +- [@zackschuster](https://github.com/zackschuster) - Zack Schuster From 3b6e869fa527fd01848ed205a436409f24dbc432 Mon Sep 17 00:00:00 2001 From: Andy Trevorah Date: Tue, 27 Nov 2018 14:27:25 +0000 Subject: [PATCH 091/226] fix typo keeping the punctuation consistent --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index f803717..c724dd3 100644 --- a/README.md +++ b/README.md @@ -47,7 +47,7 @@ Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUz * ESM in executable files ([#152](https://github.com/nodejs/modules/issues/152)) * Callable resolver ([#157](https://github.com/nodejs/modules/issues/157)) -### Loader Features +### Loader Features: * Code coverage/instrumentation ([#95](https://github.com/nodejs/modules/issues/95)) * Pluggable Loaders to support multiple use cases ([#82](https://github.com/nodejs/modules/issues/82)) From df23d000e3459a4c120fc654523b1dab36bcf662 Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Mon, 26 Nov 2018 15:01:49 -0500 Subject: [PATCH 092/226] doc: add notes for 2018-11-21 Refs: https://github.com/nodejs/modules/issues/226 --- doc/meetings/2018-11-21.md | 89 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 89 insertions(+) create mode 100644 doc/meetings/2018-11-21.md diff --git a/doc/meetings/2018-11-21.md b/doc/meetings/2018-11-21.md new file mode 100644 index 0000000..32b3b72 --- /dev/null +++ b/doc/meetings/2018-11-21.md @@ -0,0 +1,89 @@ +# Node.js Foundation Modules Team Meeting 2018-11-21 + +* **Recording**: https://www.youtube.com/watch?v=NvJgv0-rm1A +* **GitHub Issue**: https://github.com/nodejs/modules/issues/226 +* **Minutes Google Doc**: https://docs.google.com/document/d/1f9orlGCs0q6nLw6qtUpS3-GhdKcuxfYw9uc8Abfk-OA/edit + +## Present + +- Geoffrey Booth (@GeoffreyBooth) +- Myles Borins (@MylesBorins) +- Guy Bedford (@guybedford) +- Michael Zasso (@targos) +- Gus Caplan (@devsnek) +- Rob Palmer (@robpalme) +- Saleh Abdel Motaal (@SMotaal) +- Michael Dawson (@mhdawson) +- Jeremiah Senkpiel (@fishrock123) +- Jan Krems (@jkrems) +- Brad Farias (@bmeck) + +## Agenda + +Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. + +### Approving PRs (7 minute timebox) + +* governance: be explicit about meetings new members can join [#218](https://github.com/nodejs/modules/pull/218) +2 minute timebox +Asking for LTGMs +No objections, landed + +* esm resolver spec and implementation refinements [#12](https://github.com/nodejs/ecmascript-modules/pull/12) + - 5 minute timebox +A number of improvements to error handling +Goal is to make the spec and implementation evolve together. +Asking for LGTMs +No objections, landed + +### Update on Progress (3 minute timebox) + +* Surveys: Members formally taking ownership (leadership) is the next step [#209](https://github.com/nodejs/modules/issues/209) + - 3 minute timebox +Geoffrey: Could use a survey to help settle UX questions especially in Phase 2 +Myles will connect us with NPM survey + +### Discussion (45 Minute Timebox) + +* Thinking about deadlines [#123](https://github.com/nodejs/modules/issues/123) + - 5 minute timebox + +Myles: we should start to think about timelines for phases 2 and 3. +Bradley: potentially move Phase 2-1 into 3 +Saleh: objects to moving Phase 2-1 into 3 +Myles: would love to see Phase 2 finished before Dec 31, big Node 12 milestone in April +Jeremiah: need time for Node team to review, so needs to be before April +Guy: how much time before? + +* When should we drop the moratorium? [#225](https://github.com/nodejs/modules/issues/225) + - 10 minute timebox +Myles: wants to upstream as soon as possible, especially to remove/change things that we know will change in the new implementation +Myles: would people object to upstreaming minimal kernel as it is now? Guy objects +Saleh: wants loaders in +Guy is for upstreaming under certain conditions +Geoffrey: consider the PR aspects, what would we tell users when/if we upstream? +Bradley: doesn’t feel comfortable keeping --loader if we upstream +Guy: could find ways of packaging this, like upstream phases 2 and 3 separately +Myles: what about specifically upstreaming Guy’s PR? No objections + +* keeping ecmascript-modules up to date [#197](https://github.com/nodejs/modules/issues/197) + - 5 minute timebox +Myles: Anyone have any issues with current process that involves opening a PR to trigger a CI build, and then Myles rebases? No objections +Anyone have time helping to automate this? Myles and Michael and Guy offer; Gus: also @ryzokuken from last call offered +Myles: now have a master branch kept current with upstream, “lkgr” is last known good release kept current + +* re-enable issues tab on ecmascript-modules [#212](https://github.com/nodejs/modules/issues/212) + - 5 minute timebox +Gus: The repo is an implementation where code things are happening, when issues pop up they should be with the code. I’ve seen issues opened on other repos, those seem like poor places to track that. +Myles: Consensus to enable issues but move issues that are off-scope to other repos? No objections, issues re-enabled. + +* Resolution Proposal [#228](https://github.com/nodejs/modules/issues/228) +20 minute timebox +Geoffrey gave overview of proposal +Rob: Dual-mode packages: import(“lodash”) and require(“lodash”) *will* return separate instances, assuming “lodash” is a dual-mode package. +Bradley: top concern when he evaluates all proposals now is the potential for separate import specifiers to return different modules for the same specifier, e.g. imported as ESM or CJS, and this proposal addresses that as far as we can tell. +Myles asked for executive summary to be added, Geoffrey agreed to work on that +Rob asked if the “searching up the path for a package.json” logic would happen for relative paths as well as absolute URLs, Guy and Bradley and Geoffrey discussed and agreed that it would, Geoffrey will update text to make that clear. +Geoffrey to Myles: way forward on this and package exports proposals? Vote in next meeting? +Myles and Guy suggest wrapping this into Guy’s resolution spec PR, and approving that PR would implicitly approve the proposals that went into making it, and would clear the way for implementation. + From 020b9fe746959ea6d444c6dc63e27c123a98fae8 Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Tue, 18 Dec 2018 13:48:55 -0500 Subject: [PATCH 093/226] doc: notes for 2018-12-05 Refs: https://docs.google.com/document/d/1b5aA1jiYRSjjvjIwU2pt1FK7OiaR5EMLmM72E9oR9pI/edit --- doc/meetings/2018-12-05.md | 74 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 doc/meetings/2018-12-05.md diff --git a/doc/meetings/2018-12-05.md b/doc/meetings/2018-12-05.md new file mode 100644 index 0000000..1ed0cf3 --- /dev/null +++ b/doc/meetings/2018-12-05.md @@ -0,0 +1,74 @@ +# Node.js Foundation Modules Team Meeting 2018-12-05 + +* **Recording**: https://www.youtube.com/watch?v=OyLCPXym7bE +* **GitHub Issue**: https://github.com/nodejs/modules/issues/236 +* **Minutes Google Doc**: https://docs.google.com/document/d/1b5aA1jiYRSjjvjIwU2pt1FK7OiaR5EMLmM72E9oR9pI/edit + +## Present + +- Saleh Abdel Motaal (@SMotaal) +- Michael Zasso (@targos) +- Bradley Farias (@bmeck) +- Gus Caplan (@devsnek) +- Matt DuLeone (@mduleone) +- Geoffrey Booth (@GeoffreyBooth) +- Kevin Smith (@zenparsing) +- Myles Borins (@MylesBorins) +- Wesley Wigham (@weswigham) +- Guy Bedford (@guybedford) + +## Agenda + +Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. + +### nodejs/modules + +* Locking down the "process" and "Buffer" globals [#235](https://github.com/nodejs/modules/issues/235) + +- Guy: tried to prev remove Buffer/process globals. Was untenable due to performance. Lots of capabilities that might not be desirable to give to all modules. As we move towards security we want to lock down some of those capabilities. If we can lock these down, the time to do it is before we ship if we apply it to ESM. e.g. we could lock down `fs` by removing it from a 3rd party package using a resolver. Approach idea is to make global.process/global.Buffer warnings and add them to the CJS wrapper. +- Jordan: Buffer is a weird thing to be a global. Like the idea of limiting the privilege granting things from process as being a global. Platform detection uses the fact that `process` is a global so we might look at removing dangerous parts rather than the entire global. ESM is a reason to restrict module capabilities. Any feature of that nature should work for CJS. We should not leverage the ESM initiative to directly change features outside of ESM. These changes are not the scope of the ESM working group. +- Myles: CJS interop means that we could export these privileged capabilities. We should record what privileged bits of the process people are using, and we might be able to deprecate the `process` global. Don't think we can ever truly remove `process` from CJS. +- Jordan: If things are possible in CJS but not ESM it is a barrier to migrate to ESM. +- Jeremiah: Buffer was tried to be deprecated in the past (citation?) but it didn't work out. process and Buffer shouldn't be globals but soo much stuff relies on it that removing things is extremely difficult to do. If we removed things in both environments that seems possible (?), but if it only affects ESM that seems confusing. Has anyone looked at how this affects existing solution like webpack? +- Wes: Webpack/Typescript/Babel migration is extra work, if you want to do big breaking migrations you can do it. Making changing during ESM implementation is being argued as a possible time. Most people don't want to do big breaking changes to existing code. +- Guy: the upgrade path is adding 2 imports to your module. I am optimistic about this path. When doing environment detection, need a replacement workflow. How do we want users of modules to determine the environment/host they are running on. +- Kevin: Expanding scope is something we should be careful of. Expanding scope makes it hard to understand the problems we are trying to solve. +- Myles: PR around namespaces. If we have a @nodejs namespace inside of core we could be putting things there. Streams are a good example of this. Larger platform question about if this could be a pattern amongst the greater JS ecosystem. Could shim @nodejs in the browser with something like import maps. +- Jordan: Built-in language modules is desired and people are excited about. Recently there was a concrete proposal https://github.com/tc39/proposal-javascript-standard-library . No one has figured out how to make this work w/ polyfilling/shimming and deleting or denying access to them. We might not want to put our hopes on that. +- Myles: Node Collab summit and TC39 might want to spend time around cross platform concerns. +- Guy: Was hoping to get some thinking about module security here, and can go to node core with it. + +* Dynamic Modules Status [#188](https://github.com/nodejs/modules/issues/188) + +- Guy: Slides from last TC39 https://docs.google.com/presentation/d/1--k5tJmhXJeLlUOmBdHGK3my9VCbZVL0MF8OrTeqS0I/edit#slide=id.p +- Guy: Some changes related to namespaces and cycles since the last meeting. Consensus at the TC39 meeting was some questions about behaviors and we had a breakout. Main question was re-exporting using export * from a dynamic module could cause unknown export names during linking, causing errors. TC39 felt that changes to make this not work so that dynamic behavior does not cascade into ESM was desirable. Open to extending that restriction over time, we could revisit use cases in the future. Next meeting will present the changed spec. +- Gus: Accessing unfinished namespaces is already possible +- Guy: You can access namespaces in cycle before execution, but they have all the exported names already. You cannot know the names of CJS prior to execution, so there is a pending phase for dynamic modules, that is not part of ESM. +- Myles: Order of operation concern. TC39 said they would do it if V8 does it which was waiting on signal from TC39 that it is ok and is now waiting on signal from Node. +- Guy: Correct, TC39 has provisional approval, V8 is pending Node approval. We can then do this step by step to get it to TC39. Could start bringing the impl into our work already. +- Myles: we could float that patch in our fork. +- Jordan: Some reflection methods work but some throw on ESM namespaces that have not evaluated. Haven't found a way to make it work without terrible workarounds. Someone asked why these namespaces are reflectable anyway. If we make all ESM namespaces non-reflectable during cycles this problem might go away. + +Conclusion: we need to have some follow ups. Will make an issue/statement from Node core about endorsing this. + +### nodejs/ecmascript-modules + +* \[Do not merge\] doc: Add pkg-exports proposal to resolve spec [#14](https://github.com/nodejs/ecmascript-modules/pull/14) + - Jan: This is a PR about the "exports" in package.json. Planned on rewriting this based upon Resource loading based upon other doc if/when we put things into Resource based loading. The algorithm in terms of name resolution should not be changed due to any such things and it would just require a refactoring without logic changes. +- Geoffrey: Should we set of goal by next meeting to have the spec document to be done. This gives us homework/time to open any issues on that repo. That would let us have final consensus. +- Bradley: Would like to see write up on thrashing when 2 packages produce a cycle. +- Jan: Behavior doesn't allow for chaining, relative semantics are not allowed to be aliased/go through this other resolution mechanism. +- Myles: Would like to see something other than the empty string for the "main", (leading slash??). How do people feel about extending what the root means. This might be meta-data that could be used to generate import maps. We might want Domenic's input on this. +- Bradley: Uncomfortable with leading slash being rewritten. +- Jan: This is based upon the import map proposal. Leading slash Myles pointed out was after bare name in a specifier. We can revisit empty string. + +* Specify import file specifier resolution proposal [#19](https://github.com/nodejs/ecmascript-modules/pull/19) + +- Guy: this is a compliment proposal to what Jan was presenting. The implementation matches Geoffrey's repo. Takes that and turns it into spec language. Hope is that we can discuss specifics w/ the proposals. +- Geoffrey: Lets try not to put every possible concern about the spec on that PR, please open issues on the proposal repo. Leading slash can be done in another PR if we want it, this is not the last PR we will have and we can add it on as desired. Empty string vs … , all are up for debate and it is bikesheddy at this point. Behavior is locked down it seems. +- Myles: How does this change the loader? +- Geoffrey: This introduces "package scope" also called "package boundary". 2 parts of resolution: location and interpretation. Locating file for an import specifier like `import "lodash"` -> file:///…/lodash/… . This is about interpretation, find the package scope for any located file and read the package.json to know what to do with the file. If it has something flagging the package as ESM you could understand that files are ESM. +- Myles: this is package.json data on how .js files are interpretted? How far does this go? +- Geoffrey: this currently only discusses .js but for any file with a parse goal we may want to deal with this +- Jordan: for packages it seems good to have import-map style rewriting of where files are. Why aren't we doing this for both ESM and CJS. For parsing goals we could benefit from having this in CJS. +- Bradley: We can apply this to a CJS loader that we have discussed in the past. We need the collision-less intention of a format that this proposal supplied if we are to apply it to CJS as well. I will voice strong objection if I am unable to find a way that proposals could not *theoretically* work in CJS, that doesn't cover actual implementation though. Modules work shouldn't be held up by the CJS implementation of this feature. From ca521235829358b39eeb87e97df1ce6a6ec9b465 Mon Sep 17 00:00:00 2001 From: Jordan Harband Date: Tue, 18 Dec 2018 16:10:35 -0500 Subject: [PATCH 094/226] Update doc/meetings/2018-12-05.md Co-Authored-By: MylesBorins --- doc/meetings/2018-12-05.md | 1 + 1 file changed, 1 insertion(+) diff --git a/doc/meetings/2018-12-05.md b/doc/meetings/2018-12-05.md index 1ed0cf3..6a5a50d 100644 --- a/doc/meetings/2018-12-05.md +++ b/doc/meetings/2018-12-05.md @@ -16,6 +16,7 @@ - Myles Borins (@MylesBorins) - Wesley Wigham (@weswigham) - Guy Bedford (@guybedford) +- Jordan Harband (@ljharb) ## Agenda From 267893f3cad9349a735bbd41aef40adfbf203e42 Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Sat, 22 Dec 2018 00:40:19 -0500 Subject: [PATCH 095/226] doc: notes for 2018-12-19 Refs: https://github.com/nodejs/modules/issues/240 --- doc/meetings/2018-12-19.md | 97 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 97 insertions(+) create mode 100644 doc/meetings/2018-12-19.md diff --git a/doc/meetings/2018-12-19.md b/doc/meetings/2018-12-19.md new file mode 100644 index 0000000..13c85c0 --- /dev/null +++ b/doc/meetings/2018-12-19.md @@ -0,0 +1,97 @@ +# Node.js Foundation Modules Team Meeting 2018-12-19 + +* **Recording**: https://www.youtube.com/watch?v=T2i-dkaKklE +* **GitHub Issue**: https://github.com/nodejs/modules/issues/240 +* **Minutes Google Doc**: https://docs.google.com/document/d/1Kj6Ja4DM_x8Ehis-nahgttCFLMupsmWiZUhdf-WPl6U/edit + +## Present + +- Matt DuLeone (@mduleone) +- Wesley Wigham (@weswigham) +- Daniel Rosenwasser (@DanielRosenwasser) +- Guy Bedford (@guybedford) +- Myles Borins (@MylesBorins) +- Rob Palmer (@robpalme) +- Jan Krems (@jkrems) +- Gus Caplan (@devsnek) +- Bradley Farias (@bmeck) +- Hassan Sani (@inidaname) +- Geoffrey Booth (@GeoffreyBooth) +- John-David Dalton (@jdalton) + +## Agenda + +Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. + +### Discussion (55 minute timebox) + +* Discussion: Organizing work [#230](https://github.com/nodejs/modules/issues/230) + - 10 minute timebox + - How we can organize & structure work + - If we had some sort of page to say "who's working on what", that'd be great. + - Looking to expand this outside of the existing groups + - Myles: Node as a whole is a bit of a "do-ocracy" - it's just a matter of who does the work. + - Not sure whether a designated responsibilities model is something that will work or scale. + - What do you imagine the commitment of this document? + - Geoffrey: we have something like that with the phase documents; but it's more of a statement of who's interested in what, and who to include on PRs and the like. + - Kevin: Hard to get clarity on goals of various groups, and how we want to do work, but I don't have a specific recommendation. + - Myles: Saleh has recommended a "project board"; could imagine a column for each topic + - Rob: Focus groups can definitely lead to progress; really would love an index to point back to this work. + - Geoffrey: can we get consensus on a project board? + - No objections! + - Myles: Great, who will do this? + - Seems like both Geoffrey and Saleh + +* Dynamic Modules Development in Node.js [#24894](https://github.com/nodejs/node/issues/24894) + - 15 minute timebox + - Refs: + - Update spec to throw on export * from dynamic modules [#11](https://github.com/nodejs/dynamic-modules/pull/11) + - Bradley: we encountered something controversial about the behavior here, so this PR is a response to that. + - so by removing this behavior, we are open to new design space + - for clarity: nobody is saying "get rid of `export *`", just saying it isn't clear given that there's lack of consensus around it + - we may come back and add this, but we don't want to lose momentum on this feature + - Jordan: I've made similar objections in the past (i.e. "shipping without X is unacceptable"), but we're not even shipping this unflagged, so it's reasonable. Nobody should be relying on this experimental behavior. + - Kevin: don't have to do a "line in the sand" approach + - Bradley: blocking on a forward path because of a controversial feature is going to block whole proposals + - we're refusing to let ourselves agree on anything because of absolutes + - we should feel comfortable reverting features + - also, we have deadlines here + - JDD: this feature is kind of the point of transparent interop + - if we believe this is something that adds complexity to the spec; it's going to be easier to work this in from the start than later on + - we should go to TC39 first and get clarity on what we can do here + - Myles: is this something that can wait 2 weeks? + - JDD: saying "this work can be reverted" or making an explicit goal to support this somehow would be reasonable. + - Myles: so what if we added this work to phase 2? + - Bradley: I'm not okay with a commitment to not shipping without `export *` interop, but am okay with a heavy investigation here. + - JDD: If we aren't shipping this feature, then we are shipping non-transparent interop. + - Myles: Guy, do you have anything to add? + - Guy: Nothing I can verbalize. + - Myles: can we agree that we're adding exploring the `export *` space to our roadmap? + - Guy: I've spent so much time on this. Nobody has wanted to contribute, nor has anyone provided a use-case for `export *` with CJS. I've worked with TC39 to rewrite parts of the spec for transparent interop. And then one person coming to this thread has jumped into the thread and derailed the process. This is incredibly demoralizing. If someone can provide *one* use-case, that would be minimally helpful here; along with someone willing to talk about the minimal details + - JDD: have tons of users who would be impacted by this; took a survey of code in the wild. + - Bradley: Actually didn't see that many occurrences; numbers don't entirely back that up. Many of those are occurrences are compiled code anyway. + - Jeremiah: don't think compiled code is the audience for dynamic module interop. + - Myles: Perhaps we'll have to revisit the idea of whether dynamic modules are the right solution. + - JDD, what would be your feeling if this whole thing went to a vote? + - JDD: I'd feel pretty lousy if the goal is transparent interop; I can do this today with a compiler. + - Myles: how about we land the current work, and work on `export *`, revisiting the work itself if we're unable to reach a conclusion. + - Guy: can we resolve this discussion before the next TC39 meeting? + - Do we have any objections around merging in the current PR? + - No objections! + - Do we have any objections around merging in the documentation over the next week? + - No objections! + +* Specify import file specifier resolution proposal [#19](https://github.com/nodejs/ecmascript-modules/pull/19) + - ~~15 minute timebox~~ + - 2 minute update + +\[Out of time] + +Next meeting will be January 2nd. + +\[Zoom issues - abrupt meeting cutoff 2 minutes early :D] + +* \[Do not merge\] doc: Add pkg-exports proposal to resolve spec [#14](https://github.com/nodejs/ecmascript-modules/pull/14) + - 15 minute timebox + + From e25952f4c9f2e74eb8cd48f682741eb04a1561e2 Mon Sep 17 00:00:00 2001 From: Jordan Harband Date: Sat, 22 Dec 2018 00:45:11 -0500 Subject: [PATCH 096/226] Update doc/meetings/2018-12-19.md Co-Authored-By: MylesBorins --- doc/meetings/2018-12-19.md | 1 + 1 file changed, 1 insertion(+) diff --git a/doc/meetings/2018-12-19.md b/doc/meetings/2018-12-19.md index 13c85c0..b4d61bf 100644 --- a/doc/meetings/2018-12-19.md +++ b/doc/meetings/2018-12-19.md @@ -18,6 +18,7 @@ - Hassan Sani (@inidaname) - Geoffrey Booth (@GeoffreyBooth) - John-David Dalton (@jdalton) +- Jordan Harband (@ljharb) ## Agenda From 8551f41f1b2d62db788f0c26d0b16de5fb8649b7 Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Wed, 16 Jan 2019 15:12:39 -0500 Subject: [PATCH 097/226] doc: update stage 2 regarding dynamic modules (#242) As agreed upon in Dec 19th meeting --- doc/plan-for-new-modules-implementation.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/doc/plan-for-new-modules-implementation.md b/doc/plan-for-new-modules-implementation.md index b5666b4..d8d11b8 100644 --- a/doc/plan-for-new-modules-implementation.md +++ b/doc/plan-for-new-modules-implementation.md @@ -64,10 +64,14 @@ These changes are implemented in https://github.com/nodejs/ecmascript-modules/pu - `package.json` `module` field? `main` field? - Proposal: [“Package Exports” proposal](https://github.com/jkrems/proposal-pkg-exports) for bare module specifier resolution of ESM packages. - Proposal: [“File Specifier Resolution” proposal](https://github.com/GeoffreyBooth/node-import-file-specifier-resolution-proposal) mentions bare module specifier resolution of CommonJS packages; complements Package Exports proposal. - + * Define semantics for determining when to load sources as CommonJS or ES module for both the top-level main (`node x.js`) and dependency loading. - Proposal: [“File Specifier Resolution” proposal](https://github.com/GeoffreyBooth/node-import-file-specifier-resolution-proposal) covers `import` statements of ESM files; and CommonJS files, package entry point and package deep imports. +* Implement specification changes related to dynamic module records + - Proposal: ["Dynamic Modules Proposal"](https://github.com/nodejs/dynamic-modules/) + - We will need to reach consensus on appropriate behavior for [`export * from 'dynamic-module'`](https://github.com/nodejs/dynamic-modules/pull/11). If consensus cannot be reached, then this feature will be deferred to a later phase. The current behavior of throwing may also be reverted at a later time. + ## Phase 3 Phase 3 will tentatively focus on extensible loaders and deliver an environment that allows user-land experimentation. From 30969d4bdbcec6dad8050a8c631da0f052b34683 Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Thu, 17 Jan 2019 12:01:21 -0500 Subject: [PATCH 098/226] doc: update members with ncu-team sync --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index c724dd3..54051f4 100644 --- a/README.md +++ b/README.md @@ -90,7 +90,6 @@ Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUz - [@robpalme](https://github.com/robpalme) - Rob Palmer - [@SMotaal](https://github.com/SMotaal) - Saleh Abdel Motaal - [@targos](https://github.com/targos) - Michaël Zasso -- [@tbjers](https://github.com/tbjers) - Torgny Bjers - [@weswigham](https://github.com/weswigham) - Wesley Wigham - [@zenparsing](https://github.com/zenparsing) - Kevin Smith @@ -123,6 +122,7 @@ Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUz - [@ryzokuken](https://github.com/ryzokuken) - Ujjwal Sharma - [@sendilkumarn](https://github.com/sendilkumarn) - Sendil Kumar N - [@soldair](https://github.com/soldair) - Ryan Day +- [@tbjers](https://github.com/tbjers) - Torgny Bjers - [@tbranyen](https://github.com/tbranyen) - Tim Branyen - [@TheLarkInn](https://github.com/TheLarkInn) - Sean Larkin - [@TimothyGu](https://github.com/TimothyGu) - Timothy Gu From 37ef312ffbf9132c8183d5a605279c3e328813f7 Mon Sep 17 00:00:00 2001 From: Geoffrey Booth Date: Sun, 20 Jan 2019 22:04:20 -0800 Subject: [PATCH 099/226] =?UTF-8?q?Let=E2=80=99s=20start=20tackling=20--ev?= =?UTF-8?q?al,=20STDIN=20and=20extensionless=20entry=20points?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- doc/plan-for-new-modules-implementation.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/plan-for-new-modules-implementation.md b/doc/plan-for-new-modules-implementation.md index d8d11b8..dd268ef 100644 --- a/doc/plan-for-new-modules-implementation.md +++ b/doc/plan-for-new-modules-implementation.md @@ -72,6 +72,8 @@ These changes are implemented in https://github.com/nodejs/ecmascript-modules/pu - Proposal: ["Dynamic Modules Proposal"](https://github.com/nodejs/dynamic-modules/) - We will need to reach consensus on appropriate behavior for [`export * from 'dynamic-module'`](https://github.com/nodejs/dynamic-modules/pull/11). If consensus cannot be reached, then this feature will be deferred to a later phase. The current behavior of throwing may also be reverted at a later time. +* Define semantics for enabling ESM treatment of source code loaded via `--eval`, STDIN and extensionless files. + ## Phase 3 Phase 3 will tentatively focus on extensible loaders and deliver an environment that allows user-land experimentation. From a864c4cc8fc8c3ffe48a29774442050037ee0403 Mon Sep 17 00:00:00 2001 From: Jordan Harband Date: Mon, 21 Jan 2019 01:53:40 -0800 Subject: [PATCH 100/226] Update doc/plan-for-new-modules-implementation.md Co-Authored-By: GeoffreyBooth --- doc/plan-for-new-modules-implementation.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/plan-for-new-modules-implementation.md b/doc/plan-for-new-modules-implementation.md index dd268ef..b6b2f32 100644 --- a/doc/plan-for-new-modules-implementation.md +++ b/doc/plan-for-new-modules-implementation.md @@ -72,7 +72,7 @@ These changes are implemented in https://github.com/nodejs/ecmascript-modules/pu - Proposal: ["Dynamic Modules Proposal"](https://github.com/nodejs/dynamic-modules/) - We will need to reach consensus on appropriate behavior for [`export * from 'dynamic-module'`](https://github.com/nodejs/dynamic-modules/pull/11). If consensus cannot be reached, then this feature will be deferred to a later phase. The current behavior of throwing may also be reverted at a later time. -* Define semantics for enabling ESM treatment of source code loaded via `--eval`, STDIN and extensionless files. +* Define semantics for enabling ESM treatment of source code loaded via `--eval`, STDIN, and extensionless files. ## Phase 3 From 83df4650353b7ad678c69f29e4712b48a9093b4c Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Tue, 29 Jan 2019 15:57:24 -0700 Subject: [PATCH 101/226] doc: 2019-01-16 notes Refs: https://github.com/nodejs/modules/issues/248 --- doc/meetings/2019-01-16.md | 85 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 85 insertions(+) create mode 100644 doc/meetings/2019-01-16.md diff --git a/doc/meetings/2019-01-16.md b/doc/meetings/2019-01-16.md new file mode 100644 index 0000000..d6bf29b --- /dev/null +++ b/doc/meetings/2019-01-16.md @@ -0,0 +1,85 @@ +# Node.js Foundation Modules Team Meeting 2019-01-16 + +* **Recording**: https://www.youtube.com/watch?v=miv2i1h5CM0 +* **GitHub Issue**: https://github.com/nodejs/modules/issues/248 +* **Minutes Google Doc**: https://docs.google.com/document/d/1JTNIz5XMoKKAxyKF4pC-GoK9Wy3ZUIF0EwsUezZ87L8/edit + +## Present + +- Myles Borins (@MylesBorins) +- Saleh Abdel Motaal (@SMotaal) +- Matt DuLeone (@mduleone) +- Jeremiah Senkpiel (@fishrock123) +- Gus Caplan (@devsnek) +- Rob Palmer (@robpalme) +- Guy Bedford (@guybedford) +- Wesley Wigham (@weswigham) +- Daniel Rosenwasser (@DanielRosenwasser) +- Geoffrey Booth (@GeoffreyBooth) +- Jordan Harband (@LJHarb) + +## Agenda + +Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. + +### Updates (5 minute timebox) + +* Structuring a "Breakout Teams" project board [#244](https://github.com/nodejs/modules/issues/244) + - 2 minute timebox + +* Discussion: Organizing work [#230](https://github.com/nodejs/modules/issues/230) + - 3 minute timebox + +Selah: it is up and ready to start being used. Needs groups to start using it. + +### Approving PRs (5 minute timebox) + +* doc: update stage 2 regarding dynamic modules [#242](https://github.com/nodejs/modules/pull/242) + - 5 minute timebox + - No objections! + +### Discussion (40 minute timebox) + +* Mode: esm proposal [#247](https://github.com/nodejs/modules/issues/247) + - 10 minute timebox + - Demo time! + - Started off with a minimal implementation with several proposals. + - Have a few edge cases with how they interact which we'll go over. + - This minimal implementation supports `.mjs`, and Node can run with that. + - Can also use CommonJS from a `.js` file from plain Node. + - And can also `import` from that CommonJS `.js` file! + - Note that + - the `.js` comes in with a `default`. + - have to use the fully-qualified name. + - Setting the `main` field in a `package.json` still resolves correctly when directing to a CommonJS, but has to be explicit with relative and extensionful paths when pointing to ESM. + - "Deep" imports from packages don't work - each package is totally encapsulated. + - New `exports` field - can forward deep paths within a package. + - We discussed treating all `.js` as ESM - here, to accomplish that, users have to select `mode: esm`. + - All this means you can use the `package.json` `main` field for CJS and `exports` for ESM, and you can have them both work simultaneously. + - You can also turn off the encapsulation behavior (unclear - how @guybedford?) + - Jordan: You have a really good case for the ergonomics of `"mode": "esm"` + - Guy: I don't care what it is as long as it takes 20 keystrokes or fewer + - In terms of the `exports` functionality, it might be a little difficult to make it apply to CommonJS + - Gus: Why is encapsulation the default in `"mode": "esm"`? + - Guy: `"exports"` is an encapsulation of what you get in the package. + - Gus: I have go to but I have concerns about this not including JavaScript inputs. We need something that gives people more freedom. + - Rob: feels like the "desired" way of using it and I wonder - \[\[background noise from siren]] + - Guy: Have to ensure that people who don't like encapsulation have a way out. + - Geoffrey: Would love to have people try this out to see what's confusing and get user feedback. Specifically, how the main, mode, and exports fields work together. + +* Dynamic Modules Development in Node.js [#24894](https://github.com/nodejs/node/issues/24894) + - 10 minute timebox + - Without spec text there's really nothing we can do here. + +* Specify import file specifier resolution proposal [#19](https://github.com/nodejs/ecmascript-modules/pull/19) + - 10 min + + - If `"mode"` is the one thing that turns things on/off, then maybe `"exports"` shouldn't be the signifier for whether a package is ESM. + - Jordan: A map from files to parsing modes would probably be more general. + - Bradley: treating any one given circularity problem as "fatal" means you have to treat the whole system as fatal. We should avoid treating all circularities as fatal. Goto example is loader.js being loaded as CJS but making all .js files treated as ESM + - Myles: even if you just use strings for `mode`, you can always expand to mapping objects later on. + - Guy: if this is something we want to pursue, this is worth raising with npm given that it's focused around UX. + +* \[Do not merge\] doc: Add pkg-exports proposal to resolve spec [#14](https://github.com/nodejs/ecmascript-modules/pull/14) + - 10 minute timebox + - Action item: create an issue for updating the exports spec to be applicable to the CJS goals From f9d4464d70a754d80ac2d878a3f20f9b57c9eca4 Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Wed, 13 Feb 2019 01:15:26 -0800 Subject: [PATCH 102/226] doc: 2019-01-30 notes Refs: https://github.com/nodejs/modules/issues/258 --- doc/meetings/2019-01-30.md | 105 +++++++++++++++++++++++++++++++++++++ 1 file changed, 105 insertions(+) create mode 100644 doc/meetings/2019-01-30.md diff --git a/doc/meetings/2019-01-30.md b/doc/meetings/2019-01-30.md new file mode 100644 index 0000000..6d019c6 --- /dev/null +++ b/doc/meetings/2019-01-30.md @@ -0,0 +1,105 @@ +# Node.js Foundation Modules Team Meeting 2019-01-30 + +* **Recording**: https://www.youtube.com/watch?v=a1YraH8GoHk +* **GitHub Issue**: https://github.com/nodejs/modules/issues/258 +* **Minutes Google Doc**: https://docs.google.com/document/d/1yx4k1syLuMU_98sa2ASu3mgXSJ4-9Lac8uWzqIlEoYc/edit + +## Present + +- Saleh Abdel Motaal (@smotaal) +- Myles Borins (@MylesBorins) +- Geoffrey Booth (@GeoffreyBooth) +- Matt DuLeone (@mduleone) +- Wesley Wigham (@weswigham) +- Jan Krems (@jkrems) +- Guy Bedford (@guybedford) +- Michael Zasso (@targos) +- John-David Dalton (@jdalton) +- Gus Caplan (@devsnek) +- Hassan Sani (@inidaname) +- Daniel Rosenwasser (@DanielRosenwasser) +- Ahmad Abdul-Aziz (@devamaz) + +## Agenda + +Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. + +### Announcements + +* --eval, STDIN, and extensionless files [#251](https://github.com/nodejs/modules/pull/251) + +Please express interest in the thread + +### Discussion + +* Slack channel [#249](https://github.com/nodejs/modules/pull/249) + - 5 minute timebox +* Dynamic Modules Development in Node.js [#24894](https://github.com/nodejs/node/issues/24894) + - 15 minute timebox + - Guy: briefly went through the change + - Was some resistance from Till + - Some concern about whether dynamic modules loosen certain invariants + - Have been promises from TC39 over the years that these issues would be worked on, but there's not necessarily any implementation feedback except that there could potentially be a spec exception to "here's how this is allowed to work" + - Brad + - Domenic Denicola and AWB were not able to attend, so they weren't present to object, but they have raised concerns over GitHub. + - The "forbids" clause over other implementations seems like it could alleviate certain concerns. + - AWB is concerned around existing invariants, Domenic wants to have a separate web standard and a specific behavior for Node. + - Myles: This probably won't happen today. It probably won't happen quickly if it does. + It feels like it may not happen. + - JDD: I have a sunnier disposition. Sounds like there might be a path here. + - Daniel: Same. Really sounded like Till's concern was about browsers taking on the "exceptional' behavior. + - Brad: Ben Newman from Meteor sounded like the current design was incomplete. + - Myles: May need to come up with a come up with something by the March meeting + - Saleh: need to have a parallel approach that can defer to a JS polyfill. + - Myles: I don't think the concern is implementation, just about consensus and staying conformant with the spec + - Guy: Node doesn't generally add its own functionality to V8, and keeping any sort of implementation synced with V8 might be a pain. + - Jeff: Can't have interop without planning for it. + - Brad: Saying "no ESM interop" could keep things open and work towards it, and use a loader otherwise. + - JDD: What's the future look like if it doesn't happen? + - Myles: fill this in + - Jordan: Trying to lock down a design in the next 2 months out of a sense of urgency is probably not the right way to go about this. +* Minimum to release? [#253](https://github.com/nodejs/modules/issues/253) + - 15 minute timebox + - Myles: Cut Node 12 in April - any semantically versioned changes need to go in by mid-March + - the only thing that would need to go in is the new "package fields" proposals + - but the longer it sits and stuff touches it, the harder it is to modify/remove + - Myles: We need to ship something. We have decision paralysis. + - Joke - we wanted to avoid a Python 2/Python 3 decision, but in the time it took to decide all this, Python has fixed their ecosystem + - Provide named exports in April if we can; if not, don't provide transparent interop. + - Figuring out file extensions and IRP proposals seem like they could be done, but must be done. + - Saleh: shouldn't take away experimental features that would otherwise be useful due to issues around risk + - JDD: We give people explicit warranties not to use experimental stuff! + - Jordan: people have to learn their lesson with breaking changes - they shouldn't be relied on. + - Guy: Having the capability with an experimental loader hook, you'd be able to generally address the broader concerns including interop. + - Myles: things we need to tackle + - \[\[Fill this in]] + - file specifier resolution + - Missing features + - loaders & VM + - If we copied over the minimal kernel as it exists today, we'd lose functionality for putting ES modules in VM. Is that a blocker? + - Gus: they're a separate feature, it should be fine to merge in both + - Jans: At least from what I remember, the VM module leaked a lot of information about how modules work. Keeping the VM module in the minimal kernel would actually restrict our design space. + - Jeff: adding a list to the required features, there's things like entry points. + - Myles: Realms are probably coming eventually - the truly perfect solution to VM modules would be realms. + - Brad: Realms don't let you create new modules. The APIs are *very* different as well. + - Myles: but can the same things achievable in Realms? + - Brad: largely, yes + - Myles: so what if we ship vm as deprecated the same way domains are? Would that be fine? + - Jans: it's always a known unknown. + - Myles: can you work on this between now and when we want to ship? + - Jans: sure + - Myles: can we just flag vm module support? seems like it's not blocking + - Action item: Myles to come up with a list of blocking and non-blocking issues + - Saleh: could imagine an experimental module loader that tries to achieve the same things as vm. + +* WIP \[Do not merge\] - Irp type modules [#29](https://github.com/nodejs/ecmascript-modules/pull/28) + - 15 minute timebox + - Refs: + - Mode: esm proposal [#247](https://github.com/nodejs/modules/issues/247) + + + +* Import file specifier proposal implementation [#256](https://github.com/nodejs/modules/issues/256) + - 5 minute timebox + +Can land if we have consensus by next wednesday From 46cfea67ad09907811a6b302d64f735a2fca4485 Mon Sep 17 00:00:00 2001 From: Jordan Harband Date: Wed, 13 Feb 2019 13:33:44 -0800 Subject: [PATCH 103/226] Update doc/meetings/2019-01-30.md Co-Authored-By: MylesBorins --- doc/meetings/2019-01-30.md | 1 + 1 file changed, 1 insertion(+) diff --git a/doc/meetings/2019-01-30.md b/doc/meetings/2019-01-30.md index 6d019c6..fea7348 100644 --- a/doc/meetings/2019-01-30.md +++ b/doc/meetings/2019-01-30.md @@ -19,6 +19,7 @@ - Hassan Sani (@inidaname) - Daniel Rosenwasser (@DanielRosenwasser) - Ahmad Abdul-Aziz (@devamaz) +- Jordan Harband (@ljharb) ## Agenda From 58db12d9bb0d60fb91a1944b4269dba66c24113f Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Tue, 26 Feb 2019 18:12:54 -0500 Subject: [PATCH 104/226] doc: add notes for 2019-02-13 (#269) --- doc/meetings/2019-02-13.md | 123 +++++++++++++++++++++++++++++++++++++ 1 file changed, 123 insertions(+) create mode 100644 doc/meetings/2019-02-13.md diff --git a/doc/meetings/2019-02-13.md b/doc/meetings/2019-02-13.md new file mode 100644 index 0000000..9593642 --- /dev/null +++ b/doc/meetings/2019-02-13.md @@ -0,0 +1,123 @@ +# Node.js Foundation Modules Team Meeting 2019-02-13 + +* **Recording**: https://www.youtube.com/watch?v=W25K1c2e2y8 +* **GitHub Issue**: https://github.com/nodejs/modules/issues/266 +* **Minutes Google Doc**: https://docs.google.com/document/d/14pkjW9fnsgjImVabQQLLgtrJn2x_FCpMGUmoDJej_kQ/edit + +## Present + +- @DanielRosenwasser +- @jdalton (John-David Dalton) +- @SMotaal (Saleh Abdel Motaal) +- @robpalme (Rob Palmer) +- @inidaname (Hassan Sani) +- @weswigham (Wesley Wigham) +- @devamaz (Ahmad Abdul-Aziz) +- @devsnek (Gus Caplan) +- @guybedford (Guy Bedford) +- @Fishrock123 (Jeremiah Senkpiel) +- @MylesBorins (Myles Borins) +- @ljharb (Jordan Harband) + +## Agenda + +Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. + +### Note + +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 + +https://github.com/nodejs/modules/issues/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 + +* Agree on timeline + - 5 minute timebox + - Basically replacing the flagged implementation by April 2019, potentially unflag by October 2019 + - Any objections here? + - Jordan: Want to ensure that we don't try to rush anything based on deadlines. + - But no objections! +* What features are out of scope for timeline + - 5 minute timebox + - Proposal to omit `package.json` exports and VM modules + - Can put VM modules behind a flag + - JDD: does that mean VM modules can become stable before modules? + - Myles: technically the project can do anything since we're not a chartered working group, but we're assuming good faith decisions. Node core participants are aware that not everyone in the group is necessarily comfortable with VM modules going in before ES modules. + - Geoffrey: Doesn't feel like VM modules should be blocked, but definitely not with old module semantics + - Gus: Being the person who works on VM modules, I think I can keep track of that, and we don't need to worry about changes there. + - Objections to removing scope +* CommonJS interop + - 20 minute timebox + - Refs: + - CommonJS import interoperability decisions +[#264](https://github.com/nodejs/modules/issues/264) +- What is considered acceptable iteration can we do addon proposals? + - Breaking vs additive. +- What can be done that intersects existing tooling/support? + -Subset of behavior? +- What can be done that allows iterative migration? + - Subset acceptable? + - Make an update to Dynamic Modules Development in Node.js [#24894](https://github.com/nodejs/node/issues/24894) + - Import named vs default from CommonJS packages [#260](https://github.com/nodejs/modules/issues/260) + - Moving forward with Dynamic Modules? [#252](https://github.com/nodejs/modules/issues/252) + - CJS named exports via two-phase execution [#31](https://github.com/nodejs/ecmascript-modules/pull/31) + - Clarification: we mean `import`-ing a CJS, right? + - Right. + - should we continue to pursue dynamic modules in TC39? + - Brad: The "dynamic modules" behavior can be seen as an extension of "standard" behavior with ESM. + - Jordan: After shipping unflagged, it is much harder to take something back. It still feels like it's worth pursuing and something we could address. Much of the work would just be rewriting parts of the spec operating over Source Text Module Record (STMR) as operating over Abstract Module Records instead. \[\[please review]] + - Myles: Lin Clark is currently working on something called Cyclical Module Records, which is a new record type that sits between STMRs and Abstract Module Records + - Robert: Would Google be willing to ship that change? + - Domenic Denicola from Chrome suggested the change + - Myles: if we decide to move forward with out-of-order execution, doesn't seem like we'd need dynamic modules + - Guy: only reason I bring it up is we might be blocking work on dynamic modules + - Geoffrey: can always replace one with the other if it's compatible + - should we rely on out-of-order execution? + - Wesley: would be okay with OOO-execution; most code that relies on execution order can be rewritten with workarounds. + - Brad: we have run into security issues based on execution ordering exploits + - Myles: \[\[something about top-level `await` - please review]] + - Brad: top level await is definitely unrelated + - Guy: I believe that out of order execution is a spec violation - CJS doesn't have a corresponding "module type" in the ES spec. + - Brad: Out of order execution means that you can't safely refactor without sometimes different behavior. + - Guy: Instantiation is an asynchronous phase - any new top level module starts at an instantiation phase. Execution is synchronous and well-defined. + - Jordan: Idea is that this goes against the "spirit/intent" of the spec. TC39 says they would forbid OOO-exec if they could + - Myles: we're focusing a lot on whether we violate the spec and are almost out of time. Guy has two implementations, one with named exports and an OOO-exec implementation. Can we bring this forward to TC39 in March and + - Brad: Just to add, OOO-exec isn't something we can do as an additive phase. + - Myles: but do we have consensus to bring this to TC39? + - Brad: I won't be presenting OOO execution again + - Myles: I will be happy to present. + - Consensus to solving named exports using OOO execution? + - Against: Myles, Gus, Bradley, Jeremiah, Jordan, Rob, Kevin, Hassan (8) + - For: Daniel, JDD, Wesley, Jan, Geoffrey (5) + - is it even possible to ship named exports in interop? + - Geoffrey: If this was the only way to get named exports, would we still pursue it? + - Gotta move on. + - is it okay to only ship CJS as default exports? + - Daniel: no if we think we can do better, you give people a blessing/mandate to write in that way + - Jordan: to specifically add to that, I agree, but would be fine with this only if named is impossible + - WIP \[Do not merge\] - Irp type dynamic modules [#29](https://github.com/nodejs/ecmascript-modules/pull/29) +* File Extension Resolution + - 10 minute timebox +* Loaders + - 5 minute timebox +* Requirements for different phases + - 5 minute timebox + - Refs: + - * Minimum to release? [#253](https://github.com/nodejs/modules/issues/253) +* Requirements to remove flag + - 5 minute timebox + - Refs: + - Entry points proposal spec and implementation [#32](https://github.com/nodejs/ecmascript-modules/pull/32) + - Jordan: no objection if it's flagged + - Import file specifier proposal implementation [#256](https://github.com/nodejs/modules/issues/256) + - Mode: esm proposal [#247](https://github.com/nodejs/modules/issues/247) + + + + From 537d362b59e3f8067aada96d7b9519ab9ecf9d4a Mon Sep 17 00:00:00 2001 From: Daniel Rosenwasser Date: Tue, 26 Feb 2019 15:29:49 -0800 Subject: [PATCH 105/226] Corrected categorization and language for RESOURCES.md (#30) --- RESOURCES.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/RESOURCES.md b/RESOURCES.md index 2aed9b7..df15431 100644 --- a/RESOURCES.md +++ b/RESOURCES.md @@ -14,18 +14,18 @@ Following a list of ESM and CommonJS relevant projects. -#### Transpilers - * [Babel](http://babeljs.io) transpiled ES6+ including modules downgraded to CommonJS with an `exports.default` strategy - * [TypeScript](https://www.typescriptlang.org) transpiled classes including ES6 like/inspired modules - #### Bundlers * [Webpack](https://webpack.js.org) multi purpose bundler compatible with CommonJS `exports.default` strategy. Actually diverging from npm resolution preferring a `browser` field in the `package.json` instead of actual CommonJS. * [Rollup](https://rollupjs.org) next-generation ES6 module bundler with tree shaking capability * [Parceljs](https://parceljs.org/) multi purpose bundler focused on zero config and performance * [Browserify](http://browserify.org) the CommonJS module bundler that brought NodeJS to the Web -#### Compilers - * [Reify](https://www.npmjs.com/package/reify) compiles ESM syntax to CommonJS, supporting live bindings without rewriting imported variable names +#### Transpilers + * [Babel](http://babeljs.io) converts ES2015+ to older versions, including a CommonJS interop layer with ESM + * [TypeScript](https://www.typescriptlang.org) TypeScript is a typed superset of JavaScript that compiles to plain JavaScript, including a CommonJS interop layer with ESM + +#### Loaders + * [Reify](https://www.npmjs.com/package/reify) compiles ESM syntax to CommonJS on the fly, supporting live bindings without rewriting imported variable names * [@std/esm](https://github.com/standard-things/esm) is a fork of Reify focused on following Node's ESM support roadmap while providing a bridge from the CJS/ESM usage of today to the ESM of tomorrow. #### Runtime Utilities From 3767bc7810f6eee16da50332d49ec0a9085527d2 Mon Sep 17 00:00:00 2001 From: Geoffrey Booth Date: Mon, 25 Feb 2019 22:44:44 -0800 Subject: [PATCH 106/226] Revise per current status --- doc/plan-for-new-modules-implementation.md | 112 +++++++++++++-------- 1 file changed, 68 insertions(+), 44 deletions(-) diff --git a/doc/plan-for-new-modules-implementation.md b/doc/plan-for-new-modules-implementation.md index b6b2f32..e8f08db 100644 --- a/doc/plan-for-new-modules-implementation.md +++ b/doc/plan-for-new-modules-implementation.md @@ -1,38 +1,31 @@ # Plan for New Modules Implementation -This document outlines the plan for building a new implementation to support ECMAScript modules in Node.js. The general idea is to start with a “minimal kernel” as Phase 1, which consists of features that the @nodejs/modules group have agreed will be necessary for all potential iterations of our ESM implementation. Phase 1 does _not_ include features that preclude other potential features or implementation approaches; and Phase 1 also does not include some features that should naturally be built in a later phase of development, for example because those features depend on features planned for Phase 1. The minimal kernel/phase 1 is _not_ intended to be merged into Node core or released; it is only a starting point for gradually building layers of consensus. +This document outlines the plan for building a new implementation to support ECMAScript modules in Node.js. The effort is split up into phases: -At every phase, the following standards must be maintained: +* **Phase 0** branches off of current Node but removes much of the Node 8.5.0+ `--experimental-modules` implementation so that a new implementation could be built in its place. -* Spec compliance ([#132](https://github.com/nodejs/modules/issues/132)): We must always follow the ES spec. -* Browser equivalence ([#133](https://github.com/nodejs/modules/issues/133)): There’s room for debate in specific cases, but in general if Node is doing something that browsers also do, Node should do it in the same way. Alternatively, code that executes in both environments should produce identical results. -* Don’t break CommonJS ([#112](https://github.com/nodejs/modules/issues/112)): We cannot cause breaking changes with regards to CommonJS. +* **Phase 1** adds the “minimal kernel,” features that the modules working group felt would likely appear in any potential new ES modules implementation. -See also the [features list in the README](https://github.com/nodejs/modules#features). +* **Phase 2** fleshes out the implementation with enough functionality that it should be useful to average users as a minimum viable product. + - At the completion of Phase 2, the old `--experimental-modules` implementation is replaced with this new one (still behind the `--experimental-modules` flag). The goal is to “upstream” the new implementation with the release of Node 12, in April 2019. -## Phase 1: The Minimal Kernel +* **Phase 3** improves user experience and extends the MVP. -These features will be part of the first phase of development: + - At the completion of Phase 3, the new implementation’s experimental flag is dropped. The goal is to “release” (drop the `--experimental-modules` flag) by when Node 12 starts LTS in October 2019. -* `module.createRequireFromPath` ([nodejs/node#19360](https://github.com/nodejs/node/pull/19360)) is the only way to import CommonJS into an ES module, for now. - - `import.meta.require` fails at runtime as opposed to import time. This is not desireable to all committee members - - Hold off on `import` statements for CommonJS until more progress is made on the dynamic modules spec. - - landed in https://github.com/nodejs/node/commit/246f6332e5a5f395d1e39a3594ee5d6fe869d622 +The effort is currently in **Phase 2**. -* `import` statements will only support files with an `.mjs` extension, and will import only ES modules, for now. - - In a later phase, the intention is to move forward with format databases to map extensions and support multiple use cases. - - No JSON or native modules; `createRequireFromPath` can be used to get these. +At every phase, the following standards must be maintained: -* `import.meta.url`. - - Already in the existing implementation. +* Spec compliance ([#132](https://github.com/nodejs/modules/issues/132)): We must always follow the ES spec. +* Browser equivalence ([#133](https://github.com/nodejs/modules/issues/133)): There’s room for debate in specific cases, but in general if Node is doing something that browsers also do, Node should do it in the same way. Alternatively, code that executes in both environments should produce identical results. +* Don’t break CommonJS ([#112](https://github.com/nodejs/modules/issues/112)): We cannot cause breaking changes with regards to CommonJS. -* Dynamic `import()`. - - Already in the existing implementation. +See also the [features list in the README](https://github.com/nodejs/modules#features). -* Support for built-in modules with named exports - - Already in the existing implementation +## Phase 0: Start Fresh -### How will we get from where we are to Phase 1 +From current shipping Node, the following changes were made to strip out most of the Node 8.5.0+ `--experimental-modules` implementation so that a new implementation could be built in its place: * Remove support in the `import` statement of formats other than ESM: - No CommonJS. @@ -48,42 +41,73 @@ These features will be part of the first phase of development: * Remove current Loader implementation -These changes are implemented in https://github.com/nodejs/ecmascript-modules/pull/6 +These changes were implemented in https://github.com/nodejs/ecmascript-modules/pull/6. -## Phase 2 +## Phase 1: The Minimal Kernel -* Explore design space for virtual module from source - - Potential implementation in: https://github.com/nodejs/ecmascript-modules/pull/8. +The “minimal kernel” consists of features that the @nodejs/modules group have agreed will be necessary for all potential iterations of our ESM implementation. Phase 1 does _not_ include features that preclude other potential features or implementation approaches; and Phase 1 also does not include some features that should naturally be built in a later phase of development, for example because those features depend on features planned for Phase 1. -* Improve CommonJS interoperability. - - Refine `createRequireFromPath`. - - See [https://gist.github.com/SMotaal/e73c12bd801d78a3108fa30ecd303676](https://gist.github.com/SMotaal/e73c12bd801d78a3108fa30ecd303676). +* `module.createRequireFromPath` ([nodejs/node#19360](https://github.com/nodejs/node/pull/19360)) is the only way to import CommonJS into an ES module, for now. + - `import.meta.require` fails at runtime as opposed to import time. This is not desireable to all committee members. + - Hold off on `import` statements for CommonJS until more progress is made on the dynamic modules spec. + - Landed in core in https://github.com/nodejs/node/commit/246f6332e5a5f395d1e39a3594ee5d6fe869d622 + +* `import` statements will only support files with an `.mjs` extension, and will import only ES modules, for now. + - No JSON or native modules; `createRequireFromPath` can be used to get these. + +* `import.meta.url`. + - Already in the existing implementation. + +* Dynamic `import()`. + - Already in the existing implementation. + +* Support for built-in modules with named exports + - Already in the existing implementation. + +## Phase 2: Minimum Viable Product: Required to Upstream + +Phase 2 fleshes out the implementation with enough functionality that it should be useful to average users as a minimum viable product. At the completion of Phase 2, the old `--experimental-modules` implementation is replaced with this new one (still behind the `--experimental-modules` flag). * Define semantics for importing a package entry point, e.g. `import _ from 'lodash'` - - Currently this is only possible via an explicit deep import, e.g. `import _ from 'lodash/index.mjs'`. The idea would be to somehow enable the former syntax. - - `package.json` `module` field? `main` field? - - Proposal: [“Package Exports” proposal](https://github.com/jkrems/proposal-pkg-exports) for bare module specifier resolution of ESM packages. - - Proposal: [“File Specifier Resolution” proposal](https://github.com/GeoffreyBooth/node-import-file-specifier-resolution-proposal) mentions bare module specifier resolution of CommonJS packages; complements Package Exports proposal. + - Proposal: [“File Specifier Resolution” proposal](https://github.com/GeoffreyBooth/node-import-file-specifier-resolution-proposal) covers bare module specifier resolution of CommonJS packages. + - Landed in https://github.com/nodejs/ecmascript-modules/pull/28. * Define semantics for determining when to load sources as CommonJS or ES module for both the top-level main (`node x.js`) and dependency loading. - Proposal: [“File Specifier Resolution” proposal](https://github.com/GeoffreyBooth/node-import-file-specifier-resolution-proposal) covers `import` statements of ESM files; and CommonJS files, package entry point and package deep imports. - -* Implement specification changes related to dynamic module records - - Proposal: ["Dynamic Modules Proposal"](https://github.com/nodejs/dynamic-modules/) - - We will need to reach consensus on appropriate behavior for [`export * from 'dynamic-module'`](https://github.com/nodejs/dynamic-modules/pull/11). If consensus cannot be reached, then this feature will be deferred to a later phase. The current behavior of throwing may also be reverted at a later time. + - Landed in https://github.com/nodejs/ecmascript-modules/pull/28. * Define semantics for enabling ESM treatment of source code loaded via `--eval`, STDIN, and extensionless files. + - Proposal: [“Entry Points Proposal”](https://github.com/geoffreybooth/node-esm-entry-points-proposal) covers non-file forms of input as well as adding `--type` flag for controlling file-based input. + - Landed in https://github.com/nodejs/ecmascript-modules/pull/32. -## Phase 3 +* Dual CommonJS/ESM packages: Support packages that can both be `require`d as CommonJS and `import`ed as ESM, with separate entry points for each. + - Proposal: https://github.com/nodejs/modules/issues/273. + - PR: https://github.com/nodejs/ecmascript-modules/pull/41. + +## Phase 3: Path to Stability: Removing `--experimental-modules` Flag + +Phase 3 improves user experience and extends the MVP. At the end of this phase, the `--experimental-modules` flag is dropped. + +### UX Improvements + +* Better mechanism for creating `require` function. + - See [https://gist.github.com/SMotaal/e73c12bd801d78a3108fa30ecd303676](https://gist.github.com/SMotaal/e73c12bd801d78a3108fa30ecd303676). + - `import 'nodejs:require'`? `import.meta.require`? Or only `createRequireFromPath`? -Phase 3 will tentatively focus on extensible loaders and deliver an environment that allows user-land experimentation. +* A loaders solution that supports all items in the [features list in our README](https://github.com/nodejs/modules/#features). + - Should loaders be per package, per application or either? -We should try to find a loaders solution that supports all items in the [features list in our README](https://github.com/nodejs/modules/#features). +* Map the paths within modules, providing similar functionality as the browser’s [import maps proposal](https://github.com/WICG/import-maps#packages-via-trailing-slashes). + - Proposal: [“Package Exports Proposal”](https://github.com/jkrems/proposal-pkg-exports). -## Phase 4 +* Automatic entry point module type detection. + - Proposal: [“Entry Points Proposal”](https://github.com/geoffreybooth/node-esm-entry-points-proposal) includes `--type=auto` flag for running `.js` files in either ESM or CommonJS based on which module system is detected. -Phase 4 will include addressing user feedback gathered from the experimentation enabled by Phase 3 and focus on a holistic and complete experience of ESM in Node.js. +### Needs Consensus -## Future Phases +* Finalize support for (or removal of) `import` of CommonJS files and packages. + - See https://github.com/nodejs/modules/issues/264. + - Defaults only or named exports? Behind a flag or not? -TBD. +* File extension/directory index searching in ESM. + - See https://github.com/nodejs/modules/issues/268. From 766711c1e98d322d052e58beb36b6a762ed3ff72 Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Wed, 27 Feb 2019 15:19:13 -0500 Subject: [PATCH 107/226] governance: explicit rules for modules-lkgr fork (#277) Current rules only apply to this repo not the fork. Makes things clearer and expands on the types of changes that don't require meetings to be approved. --- GOVERNANCE.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/GOVERNANCE.md b/GOVERNANCE.md index b3fe92b..44bd044 100644 --- a/GOVERNANCE.md +++ b/GOVERNANCE.md @@ -98,10 +98,11 @@ meeting. In both cases the decision must be seconded by a majority of the Team or else the discussion will continue. Simple majority wins. Only Active Members participate in a vote. -## Merging PRs into this Repository +## Merging PRs into this Repository or nodejs/ecmascript-modules This section does not apply to [the Node.js core repository](https://github.com/nodejs/node). -It only applies to [the Modules repository](https://github.com/nodejs/modules). +It only applies to [the Modules repository](https://github.com/nodejs/modules) and +[nodejs/ecmascript-modules](https://github.com/nodejs/ecmascript-modules). Pull requests not included under the _special exemptions_ section below must reach consensus in a meeting in order to be merged into this repository. A pull @@ -117,6 +118,9 @@ changes to this repository: - Editorial changes. - Meeting minutes. - Updates to the team lists via the `ncu-sync` tool. +- Doc Fixes +- Tests +- Fixing Conflicts with a rebase These pull requests may be merged without being presented at a meeting if a reasonable time is given for review and there no dissent. The time period seen From 6757db7e33c1856c7b435078808e5781e29b1548 Mon Sep 17 00:00:00 2001 From: Geoffrey Booth Date: Wed, 27 Feb 2019 13:09:00 -0800 Subject: [PATCH 108/226] Revisions per 2019-02-27 meeting --- doc/plan-for-new-modules-implementation.md | 18 ++++++++++-------- 1 file changed, 10 insertions(+), 8 deletions(-) diff --git a/doc/plan-for-new-modules-implementation.md b/doc/plan-for-new-modules-implementation.md index e8f08db..c5d002f 100644 --- a/doc/plan-for-new-modules-implementation.md +++ b/doc/plan-for-new-modules-implementation.md @@ -76,27 +76,29 @@ Phase 2 fleshes out the implementation with enough functionality that it should - Proposal: [“File Specifier Resolution” proposal](https://github.com/GeoffreyBooth/node-import-file-specifier-resolution-proposal) covers `import` statements of ESM files; and CommonJS files, package entry point and package deep imports. - Landed in https://github.com/nodejs/ecmascript-modules/pull/28. -* Define semantics for enabling ESM treatment of source code loaded via `--eval`, STDIN, and extensionless files. +* Define semantics for enabling ESM treatment of source code loaded via `--eval`, STDIN, and extensionless files (both with and without shebang lines). - Proposal: [“Entry Points Proposal”](https://github.com/geoffreybooth/node-esm-entry-points-proposal) covers non-file forms of input as well as adding `--type` flag for controlling file-based input. - Landed in https://github.com/nodejs/ecmascript-modules/pull/32. -* Dual CommonJS/ESM packages: Support packages that can both be `require`d as CommonJS and `import`ed as ESM, with separate entry points for each. - - Proposal: https://github.com/nodejs/modules/issues/273. - - PR: https://github.com/nodejs/ecmascript-modules/pull/41. +* A loaders solution that supports all items in the [features list in our README](https://github.com/nodejs/modules/#features). + - Should loaders be per package, per application or either? + - Will land in Phase 2 only if an implementation without major problems (e.g. memory leaks) can be completed in time. If the problems can be isolated behind a flag, we could upstream a buggy implementation and fix and unflag it after unflagging. + ## Phase 3: Path to Stability: Removing `--experimental-modules` Flag -Phase 3 improves user experience and extends the MVP. At the end of this phase, the `--experimental-modules` flag is dropped. +Phase 3 improves user experience and extends the MVP. Phase 3 is malleable based on how things proceed while working on this phase. At the end of this phase, the `--experimental-modules` flag is dropped. ### UX Improvements +* Dual CommonJS/ESM packages: Either support packages that can both be `require`d as CommonJS and `import`ed as ESM; or decide to specifically not support dual CommonJS/ESM packages. + - Proposal: https://github.com/nodejs/modules/issues/273. + - PR: https://github.com/nodejs/ecmascript-modules/pull/41. + * Better mechanism for creating `require` function. - See [https://gist.github.com/SMotaal/e73c12bd801d78a3108fa30ecd303676](https://gist.github.com/SMotaal/e73c12bd801d78a3108fa30ecd303676). - `import 'nodejs:require'`? `import.meta.require`? Or only `createRequireFromPath`? -* A loaders solution that supports all items in the [features list in our README](https://github.com/nodejs/modules/#features). - - Should loaders be per package, per application or either? - * Map the paths within modules, providing similar functionality as the browser’s [import maps proposal](https://github.com/WICG/import-maps#packages-via-trailing-slashes). - Proposal: [“Package Exports Proposal”](https://github.com/jkrems/proposal-pkg-exports). From c07ce91b0739e66f749dfeda9e2d1029522bf038 Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Wed, 27 Feb 2019 16:24:17 -0500 Subject: [PATCH 109/226] doc: update members list with ncu-team (#281) $ ncu-team sync README.md --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 54051f4..beab701 100644 --- a/README.md +++ b/README.md @@ -73,13 +73,11 @@ Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUz -- [@benjamingr](https://github.com/benjamingr) - Benjamin Gruenbaum - [@bmeck](https://github.com/bmeck) - Bradley Meck - [@DanielRosenwasser](https://github.com/DanielRosenwasser) - Daniel Rosenwasser - [@devsnek](https://github.com/devsnek) - Gus Caplan - [@Fishrock123](https://github.com/Fishrock123) - Jeremiah Senkpiel - [@GeoffreyBooth](https://github.com/GeoffreyBooth) - Geoffrey Booth -- [@giltayar](https://github.com/giltayar) - Gil Tayar - [@guybedford](https://github.com/guybedford) - Guy Bedford - [@inidaname](https://github.com/inidaname) - Hassan Sani - [@jdalton](https://github.com/jdalton) - John-David Dalton @@ -99,6 +97,7 @@ Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUz +- [@benjamingr](https://github.com/benjamingr) - Benjamin Gruenbaum - [@benjamn](https://github.com/benjamn) - Ben Newman - [@bmacnaughton](https://github.com/bmacnaughton) - Bruce MacNaughton - [@bmeurer](https://github.com/bmeurer) - Benedikt Meurer @@ -108,6 +107,7 @@ Based on [these use cases](https://docs.google.com/document/d/10BBsIqdAXB9JR2KUz - [@devamaz](https://github.com/devamaz) - Ahmad Abdul-Aziz - [@eugeneo](https://github.com/eugeneo) - Eugene Ostroukhov - [@evanplaice](https://github.com/evanplaice) - Evan Plaice +- [@giltayar](https://github.com/giltayar) - Gil Tayar - [@hiroppy](https://github.com/hiroppy) - Yuta Hiroto - [@iarna](https://github.com/iarna) - Rebecca Turner - [@jasnell](https://github.com/jasnell) - James M Snell From 62d0df744e6b735d0bda5ffa022f85476280c5b6 Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Wed, 27 Feb 2019 16:24:30 -0500 Subject: [PATCH 110/226] doc: 2019-02-20 Notes (#275) --- doc/meetings/2019-02-20.md | 122 +++++++++++++++++++++++++++++++++++++ 1 file changed, 122 insertions(+) create mode 100644 doc/meetings/2019-02-20.md diff --git a/doc/meetings/2019-02-20.md b/doc/meetings/2019-02-20.md new file mode 100644 index 0000000..83369f0 --- /dev/null +++ b/doc/meetings/2019-02-20.md @@ -0,0 +1,122 @@ +# Node.js Foundation Modules Team Meeting 2019-02-20 + +* **Recording**: https://www.youtube.com/watch?v=H34VieUOGu4 +* **GitHub Issue**: https://github.com/nodejs/modules/issues/270 +* **Minutes Google Doc**: https://docs.google.com/document/d/1AFnHc85SzFZFUqL6xL7xTDOmFB9FM6q9yapjYGQiXi0/edit + +## Present + +- John-David Danger Dalton (@jdalton) +- Myles Borins (@MylesBorins) +- Bradley Farias (@bmeck) +- Wesley Wigham (@weswigham) +- Daniel Rosenwasser (@DanielRosenwasser) +- Gus Caplan (@devsnek) +- Jeremiah Senkpiel (@Fishrock123) +- Jordan Harband (@ljharb) + +## 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 + +https://github.com/nodejs/modules/issues/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 + * https://github.com/nodejs/ecmascript-modules/pull/261 + * Out of order execution (https://github.com/nodejs/ecmascript-modules/pull/31) + * Leaned against out-of-order execution + * Shipping just default exports + * Leaning towards not doing this if named exports are a possibility. + * Removed some of the functionality here, but the "plumbing" is there + * Myles: could we put that behind a flag? + * Daniel: Seems reasonable, but just concerned with the name. call out that it's an interop strategy. + * Jeremiah: Shipping without interop seems like not an option. + * Myles: Just as an FYI, pushing back means we'll need to go to a vote + * Myles: So do we have objections? + * Geoffrey: wouldn't feel comfortable shipping because messaging might be confusing if that strategy isn't what we want to go with in the first place. Also, if we take it back, people could say we're "removing interop". + * Myles: Don't think that's true, we're within our right to remove anything flagged. + * Jordan: meta-point: certain choices have to be made for different use-cases. Making different choices shut down certain use-cases. Want us to think about our use-cases in the final product. + * Wesley: we're generally in agreement that we and TC39 want to support named exports. Why can't we ship one of the proposals behind a flag? + * Brad: which one? OOO-exec? JDD's? Guy's? + * Wesley: not the OOO-exec one + * Brad: `export *` has come up in the committee again. + * Wesley: these changes aren't observable for code people tend to write + * Brad: These changes are observable. + * Wesley: Minor in comparison to the change of not having any interop + * Gus: these are pretty observable + * Wesley: for people writing code, are they observable? + * Gus: Not necessarily, but what about bundlers? Linters? Those need static imports + * Wesley: all of these tools already analyze just fine despite dynamic behavior. + * Myles: we need true static analyzability for the sort of cold start improvements that we hope to achieve in Node core. + * Jordan: this is the sort of thing that can't be handled in TC39. \[\[fill in later]] + * Wesley: going with a non-final version of named imports is the more reasonable thing to do than shipping a default only + * Brad: would you be okay throwing that implementation out if we can't make it work? + * Daniel: we'd potentially have to throw some implementation out no matter what we ship + * Wesley: and shipping named exports is more aligned with what this group wants to ship + * Brad: counter-point: should we ship the thing we're more likely to be able to ship? + * Myles: There are more people who want no interop than no named interop (with just a default import available) + * Named exports + * Have a path towards supporting it with dynamic modules. + * Some people might feel discouraged from the work, but it's an open path. + * Geoffrey: can we just ship this unflagged? + * \[\[objections]] + * JDD: would be against even a flagged implementation shipping + * Myles: is this because `export *`? + * JDD: not clear that dynamic modules will solve this exactly; the + * Brad: strong mischaracterization of Guy's work, calling it a failed proposal is unreasonable! + * JDD: Just because one person has worked on it doesn't mean we need to rubber-stamp it. I am a delegate and I would block the current proposal as-is. + * Brad: work being from just one person doesn't mean it's good or bad, it's something that we can iterate on + * JDD: if we're trying to come to the best design, I don't believe this is the right direction. + * Jordan: why do you find default acceptable, but the rest of it not? + * JDD: `default` doesn't cause any spec changes, has a reasonable precedent. Would rather start from low-to-no-effort spec work. Otherwise you have to throw on syntax. + * Wesley: No named exports means you *do* have errors on syntax. + * JDD: no, that's erroring on bindings that don't exist + * Wesley: there's no difference as a user!!!! + * Refs: + * CommonJS import interoperability decisions [#264](https://github.com/nodejs/modules/issues/264) + * Make an update to Dynamic Modules Development in Node.js [#24894](https://github.com/nodejs/node/issues/24894) + * Import named vs default from CommonJS packages [#260](https://github.com/nodejs/modules/issues/260) + * Moving forward with Dynamic Modules? [#252](https://github.com/nodejs/modules/issues/252) + * CJS named exports via two-phase execution [#31](https://github.com/nodejs/ecmascript-modules/pull/31) + * WIP [Do not merge] - Irp type dynamic modules [#29](https://github.com/nodejs/ecmascript-modules/pull/29) +* File Extension Resolution + * 15 minute timebox + * Refs: + * File extension/directory index resolution in ESM [#268](https://github.com/nodejs/modules/issues/268) + * Existing resolution algorithm for CJS searches through a handful of extensions to search. + * Currently the minimal kernel doesn't support this. Should we? People on the committee don't want this to begin with. + * Brad: we should be okay shipping without it initially and then shipping. That way we have two paths later on. + * Geoffrey: if we make this opt-in, that's fine. users become aware of the behavior. + * Jordan: I would object to shipping without it unflagged. I find extension lookup so critical that I don't think we can ship without it. + * Gus: to people who don't want to ship by default, I'm confused. If you don't want this feature, don't use it and just be explicit specifiers. + * Myles: we want an ecosystem of modules that can be shared across all ecosystems/runtimes. If you allow people mixing, your dependencies can throw a wrench in the mix if their paths don't work. + * Could we use something like import maps to make this easier. + * Myles: that doesn't work, import maps would blow up exponentially in size to model the entire dependency tree. They're meant for modeling only a few bare imports. + * Gus: I could totally see Yarn or npm shipping something that just generates these files anyway. +* Loaders + * 5 minute timebox +* Requirements to replace upstream + * 10 minute timebox + * Refs: + * Minimum to release? [#253](https://github.com/nodejs/modules/issues/253) +* Requirements to remove flag + * 5 minute timebox + * Refs: + * Entry points proposal spec and implementation [#32](https://github.com/nodejs/ecmascript-modules/pull/32) + * Import file specifier proposal implementation [#256](https://github.com/nodejs/modules/issues/256) + * Mode: esm proposal [#247](https://github.com/nodejs/modules/issues/247) + From a491d9d4eadf5345e2879596ff999dda7c0ce686 Mon Sep 17 00:00:00 2001 From: Geoffrey Booth Date: Wed, 27 Feb 2019 13:33:29 -0800 Subject: [PATCH 111/226] Revisions per 2019-02-27 meeting --- doc/plan-for-new-modules-implementation.md | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/doc/plan-for-new-modules-implementation.md b/doc/plan-for-new-modules-implementation.md index c5d002f..e89be2f 100644 --- a/doc/plan-for-new-modules-implementation.md +++ b/doc/plan-for-new-modules-implementation.md @@ -68,6 +68,8 @@ The “minimal kernel” consists of features that the @nodejs/modules group hav Phase 2 fleshes out the implementation with enough functionality that it should be useful to average users as a minimum viable product. At the completion of Phase 2, the old `--experimental-modules` implementation is replaced with this new one (still behind the `--experimental-modules` flag). +### Core Functionality + * Define semantics for importing a package entry point, e.g. `import _ from 'lodash'` - Proposal: [“File Specifier Resolution” proposal](https://github.com/GeoffreyBooth/node-import-file-specifier-resolution-proposal) covers bare module specifier resolution of CommonJS packages. - Landed in https://github.com/nodejs/ecmascript-modules/pull/28. @@ -82,7 +84,12 @@ Phase 2 fleshes out the implementation with enough functionality that it should * A loaders solution that supports all items in the [features list in our README](https://github.com/nodejs/modules/#features). - Should loaders be per package, per application or either? - - Will land in Phase 2 only if an implementation without major problems (e.g. memory leaks) can be completed in time. If the problems can be isolated behind a flag, we could upstream a buggy implementation and fix and unflag it after unflagging. + - Will land in Phase 2 only if an implementation without major problems (e.g. memory leaks) can be completed in time. If the problems can be isolated behind a flag specific to loaders, we could upstream a buggy implementation and unflag it after its bugs are fixed. + +### Needs Consensus + +* Add, or decide not to support, file extension and directory index searching in ESM. + - See https://github.com/nodejs/modules/issues/268. ## Phase 3: Path to Stability: Removing `--experimental-modules` Flag @@ -110,6 +117,3 @@ Phase 3 improves user experience and extends the MVP. Phase 3 is malleable based * Finalize support for (or removal of) `import` of CommonJS files and packages. - See https://github.com/nodejs/modules/issues/264. - Defaults only or named exports? Behind a flag or not? - -* File extension/directory index searching in ESM. - - See https://github.com/nodejs/modules/issues/268. From b590e38fb71848bbe5170cb0914a9564f4152aa9 Mon Sep 17 00:00:00 2001 From: Guy Bedford Date: Mon, 4 Mar 2019 21:50:14 +0200 Subject: [PATCH 112/226] Move loaders to phase 3 --- doc/plan-for-new-modules-implementation.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/plan-for-new-modules-implementation.md b/doc/plan-for-new-modules-implementation.md index e89be2f..e14a049 100644 --- a/doc/plan-for-new-modules-implementation.md +++ b/doc/plan-for-new-modules-implementation.md @@ -82,10 +82,6 @@ Phase 2 fleshes out the implementation with enough functionality that it should - Proposal: [“Entry Points Proposal”](https://github.com/geoffreybooth/node-esm-entry-points-proposal) covers non-file forms of input as well as adding `--type` flag for controlling file-based input. - Landed in https://github.com/nodejs/ecmascript-modules/pull/32. -* A loaders solution that supports all items in the [features list in our README](https://github.com/nodejs/modules/#features). - - Should loaders be per package, per application or either? - - Will land in Phase 2 only if an implementation without major problems (e.g. memory leaks) can be completed in time. If the problems can be isolated behind a flag specific to loaders, we could upstream a buggy implementation and unflag it after its bugs are fixed. - ### Needs Consensus * Add, or decide not to support, file extension and directory index searching in ESM. @@ -98,6 +94,10 @@ Phase 3 improves user experience and extends the MVP. Phase 3 is malleable based ### UX Improvements +* A loaders solution that supports all items in the [features list in our README](https://github.com/nodejs/modules/#features). + - Should loaders be per package, per application or either? + - Will land in Phase 2 only if an implementation without major problems (e.g. memory leaks) can be completed in time. If the problems can be isolated behind a flag specific to loaders, we could upstream a buggy implementation and unflag it after its bugs are fixed. + * Dual CommonJS/ESM packages: Either support packages that can both be `require`d as CommonJS and `import`ed as ESM; or decide to specifically not support dual CommonJS/ESM packages. - Proposal: https://github.com/nodejs/modules/issues/273. - PR: https://github.com/nodejs/ecmascript-modules/pull/41. From 656b2d14b140bbb2a0671c4f4eb63ff08a472b57 Mon Sep 17 00:00:00 2001 From: Guy Bedford Date: Mon, 4 Mar 2019 23:22:31 +0200 Subject: [PATCH 113/226] remove unnecessary phase2 note --- doc/plan-for-new-modules-implementation.md | 1 - 1 file changed, 1 deletion(-) diff --git a/doc/plan-for-new-modules-implementation.md b/doc/plan-for-new-modules-implementation.md index e14a049..1d34b36 100644 --- a/doc/plan-for-new-modules-implementation.md +++ b/doc/plan-for-new-modules-implementation.md @@ -96,7 +96,6 @@ Phase 3 improves user experience and extends the MVP. Phase 3 is malleable based * A loaders solution that supports all items in the [features list in our README](https://github.com/nodejs/modules/#features). - Should loaders be per package, per application or either? - - Will land in Phase 2 only if an implementation without major problems (e.g. memory leaks) can be completed in time. If the problems can be isolated behind a flag specific to loaders, we could upstream a buggy implementation and unflag it after its bugs are fixed. * Dual CommonJS/ESM packages: Either support packages that can both be `require`d as CommonJS and `import`ed as ESM; or decide to specifically not support dual CommonJS/ESM packages. - Proposal: https://github.com/nodejs/modules/issues/273. From 24e1835dd44c0db8f058088cc19959b50ca07e73 Mon Sep 17 00:00:00 2001 From: Geoffrey Booth Date: Mon, 4 Mar 2019 14:22:13 -0800 Subject: [PATCH 114/226] Update plan for file extension/directory index searching per 2019-03-04 meeting --- doc/plan-for-new-modules-implementation.md | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/doc/plan-for-new-modules-implementation.md b/doc/plan-for-new-modules-implementation.md index 1d34b36..0037a7d 100644 --- a/doc/plan-for-new-modules-implementation.md +++ b/doc/plan-for-new-modules-implementation.md @@ -68,8 +68,6 @@ The “minimal kernel” consists of features that the @nodejs/modules group hav Phase 2 fleshes out the implementation with enough functionality that it should be useful to average users as a minimum viable product. At the completion of Phase 2, the old `--experimental-modules` implementation is replaced with this new one (still behind the `--experimental-modules` flag). -### Core Functionality - * Define semantics for importing a package entry point, e.g. `import _ from 'lodash'` - Proposal: [“File Specifier Resolution” proposal](https://github.com/GeoffreyBooth/node-import-file-specifier-resolution-proposal) covers bare module specifier resolution of CommonJS packages. - Landed in https://github.com/nodejs/ecmascript-modules/pull/28. @@ -82,10 +80,9 @@ Phase 2 fleshes out the implementation with enough functionality that it should - Proposal: [“Entry Points Proposal”](https://github.com/geoffreybooth/node-esm-entry-points-proposal) covers non-file forms of input as well as adding `--type` flag for controlling file-based input. - Landed in https://github.com/nodejs/ecmascript-modules/pull/32. -### Needs Consensus - -* Add, or decide not to support, file extension and directory index searching in ESM. +* File extension and directory index searching in ESM, behind its own flag. - See https://github.com/nodejs/modules/issues/268. + - Per 2019-03-04 meeting, searching will be disabled by default in ESM but enabled via a flag; and the flag will be neutral as to which state the feature should take (similar to `--type=commonjs` / `--type=module`, where the former is currently a noop because it’s the default; but if the default changes someday, the latter would become the noop). ## Phase 3: Path to Stability: Removing `--experimental-modules` Flag From 3dab8714a24cbadd3dbf25f861f8a8f11f9fb3ad Mon Sep 17 00:00:00 2001 From: Myles Borins Date: Wed, 6 Mar 2019 02:51:08 -0500 Subject: [PATCH 115/226] doc: 2019-02-27 meeting notes (#285) Refs: https://github.com/nodejs/modules/issues/276 --- doc/meetings/2019-02-27.md | 107 +++++++++++++++++++++++++++++++++++++ 1 file changed, 107 insertions(+) create mode 100644 doc/meetings/2019-02-27.md diff --git a/doc/meetings/2019-02-27.md b/doc/meetings/2019-02-27.md new file mode 100644 index 0000000..c43ac6f --- /dev/null +++ b/doc/meetings/2019-02-27.md @@ -0,0 +1,107 @@ +# Node.js Foundation Modules Team Meeting 2019-02-27 + +* **Recording**: https://youtu.be/wYKeySvX8EI +* **GitHub Issue**: https://github.com/nodejs/modules/issues/276 +* **Minutes Google Doc**: https://docs.google.com/document/d/1gXpUwJGPAgHNLqbOdqKEoRQsbdQwqgXAC2kC_tyQ6Tk/edit + +## Present + +- Myles Borins (@MylesBorins) +- Gus Caplan (@devsnek) +- Wesley Wigham (@weswigham) +- Geoffrey Booth (@GeoffreyBooth) +- Jan Krems (@jkrems) +- Saleh Abdel Motaal (@smotaal) +- Jeremiah Senkpiel (@Fishrock123) +- Guy Bedford (@guybedford) +- Matt DuLeone (@mduleone) +- Jordan Harband (@ljharb) + +## 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 + +https://github.com/nodejs/modules/issues/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. + +### Review Open PRs (15 minute timebox) + +All discussion are limited to 5 minutes and will be ended early if it is obvious there is no consensus + +* -m alias for --type=module [#39](https://github.com/nodejs/ecmascript-modules/pull/39) + +Consensus to land and discuss further if necessary. +Also discussing [#45](https://github.com/nodejs/ecmascript-modules/pull/45). + +Can land in 48 hours based on review + +* Exports main [#41](https://github.com/nodejs/ecmascript-modules/pull/41) + +To be revisited after extension resolution; ask to review extension resolution in this meeting in order to unblock + +* esm: add experimental .json support to loader [#43](https://github.com/nodejs/ecmascript-modules/pull/43) + +Skip for now + +* Warn about `--type` with shebang [#37](https://github.com/nodejs/ecmascript-modules/pull/37) + +* ESM_FORMAT: Avoid reading package.json when extension is unambiguous [#33](https://github.com/nodejs/ecmascript-modules/pull/33) + +#44 adds tests to be merged into other PR #45 + +### Discussion (40 minutes) + +* Review last weeks discussion + * 5 minute timebox + +* What is an MVP to upstream? + +Reviewing https://github.com/nodejs/modules/pull/280, the revised road map + * No objections to overall structure or phases 0 or 1 + + + * 10 minute timebox + * Refs: + * Minimum to release? [#253](https://github.com/nodejs/modules/issues/253) + * Entry points proposal spec and implementation [#32](https://github.com/nodejs/ecmascript-modules/pull/32) + * Import file specifier proposal implementation [#256](https://github.com/nodejs/modules/issues/256) + * Mode: esm proposal [#247](https://github.com/nodejs/modules/issues/247) + +* Loaders + * 5 minute timebox + +* File Extension Resolution + * 10 minute timebox + * Refs: + * File extension/directory index resolution in ESM [#268](https://github.com/nodejs/modules/issues/268) + +* CommonJS interop + * 10 minute timebox + * Refs: + * Proposal for dual ESM/CommonJS packages [#273](https://github.com/nodejs/modules/issues/273) + * CommonJS import interoperability decisions [#264](https://github.com/nodejs/modules/issues/264) + * Make an update to Dynamic Modules Development in Node.js [#24894](https://github.com/nodejs/node/issues/24894) + * Import named vs default from CommonJS packages [#260](https://github.com/nodejs/modules/issues/260) + * Moving forward with Dynamic Modules? [#252](https://github.com/nodejs/modules/issues/252) + * CJS named exports via two-phase execution [#31](https://github.com/nodejs/ecmascript-modules/pull/31) + * WIP [Do not merge] - Irp type dynamic modules [#29](https://github.com/nodejs/ecmascript-modules/pull/29) + + + + + + + + + + + From e1e7563dced81a12214ebdabb088a56f8f6af5d8 Mon Sep 17 00:00:00 2001 From: Geoffrey Booth Date: Sat, 9 Mar 2019 23:38:15 -0800 Subject: [PATCH 116/226] Announcement blog post, first draft --- doc/announcement.md | 99 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 99 insertions(+) create mode 100644 doc/announcement.md diff --git a/doc/announcement.md b/doc/announcement.md new file mode 100644 index 0000000..bcc3d92 --- /dev/null +++ b/doc/announcement.md @@ -0,0 +1,99 @@ +# Announcing a New `--experimental-modules` + +Back in 2017, Node.js 8.9.0 shipped experimental support for [ECMAScript modules](https://hacks.mozilla.org/2018/03/es-modules-a-cartoon-deep-dive/), known for their `import` and `export` statements. This support was behind the flag `--experimental-modules`. + +A lot has happened since then. All major browsers [now support](https://caniuse.com/#feat=es6-module) ECMAScript modules (ES modules) via `