forked from nodejs/modules
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Showing
1 changed file
with
122 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,122 @@ | ||
| # 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) | ||
|
|
||
| ## 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) | ||
|
|
||
|
|
||
|
|
||
|
|