From 69eb69461d1b949a33d1a1796a3e644ba1b9a57d Mon Sep 17 00:00:00 2001 From: Sendil Kumar N Date: Sat, 28 Jul 2018 01:47:16 +0200 Subject: [PATCH 001/169] 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 002/169] 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 003/169] 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 004/169] 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 005/169] 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 006/169] 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 007/169] 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 008/169] 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 009/169] 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 010/169] 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 011/169] 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 012/169] 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 013/169] 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 014/169] 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 015/169] 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 016/169] 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 017/169] 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 018/169] 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 019/169] 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 020/169] 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 021/169] 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 022/169] 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 023/169] 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 024/169] 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 025/169] 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 026/169] 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 027/169] 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 028/169] 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 029/169] 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 030/169] 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 031/169] 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 032/169] 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 033/169] 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 034/169] 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 035/169] 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 036/169] 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 037/169] 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 038/169] 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 039/169] 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 040/169] 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 041/169] 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 042/169] =?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 043/169] 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 044/169] 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 045/169] 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 046/169] 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 047/169] 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 048/169] 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 049/169] 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 050/169] 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 051/169] 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 052/169] 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 053/169] 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 054/169] 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 055/169] 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 056/169] 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 057/169] 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 058/169] 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 059/169] 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 `