This repository has been archived by the owner on Sep 2, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 44
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
doc: add meeting notes for 2018-03-14
closes: #47 refs: https://www.youtube.com/watch?v=U9xG4JPdznA refs: https://docs.google.com/document/d/1fwQ_XkYyJO3p5fE2o9H9i7iWii0LB4OyQxepBlaa6-Y/edit
- Loading branch information
1 parent
af7d918
commit 4ea9e63
Showing
1 changed file
with
119 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,119 @@ | ||
| # Node.js Foundation Modules Team Meeting 2018-03-14 | ||
|
|
||
| * **Recording**: https://www.youtube.com/watch?v=U9xG4JPdznA | ||
| * **GitHub Issue**: https://github.com/nodejs/modules/issues/47 | ||
| * **Minutes Google Doc**: https://docs.google.com/document/d/1fwQ_XkYyJO3p5fE2o9H9i7iWii0LB4OyQxepBlaa6-Y/edit | ||
|
|
||
| ## Present | ||
|
|
||
| Chris Dickinson (@chrisdickinson) | ||
| Myles Borins (@MylesBorins) | ||
| Wesley Wigham (@weswigham) | ||
| Michael Zasso (@targos) | ||
| Gus Caplan (@devsnek) | ||
| Gil Tayar (@giltayar) | ||
| C J Silverio (@ceejbot) | ||
| Torgny Bjers (@tbjers) | ||
| Matt DuLeone (@mduleone) | ||
| Benjamin Gruenbaum (@benajingr) | ||
| Daniel Rosenwasser (@DanielRosenwasser) | ||
| John-David Dalton (@jdalton) | ||
| Rebecca Turner (@iarna) | ||
| Lin Clark (@linclark) | ||
| Guy Bedford (@guybedford) | ||
| Bradley Farias (@bfarias) | ||
| Jordan Harband (@ljharb) | ||
| Hassan Sani (@inidaname) | ||
| Justin Fagnani (@justinfagnani) | ||
| Ben Newman (@benjamn) | ||
| Jeremiah Senkpiel (@Fishrock123) | ||
| Jan Olaf Krems (@jkrems) | ||
|
|
||
| ## Agenda | ||
|
|
||
| Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. | ||
|
|
||
|
|
||
| ### nodejs/modules | ||
|
|
||
| #### Approving PRs ~ 1 minute timebox | ||
|
|
||
| * doc: add meeting notes for 2018-02-28 [#38](https://github.com/nodejs/modules/pull/38) | ||
| * No objections! | ||
|
|
||
| #### For awareness ~ 3 minute timebox | ||
|
|
||
| * doc: add MANIFESTO.md [#45](https://github.com/nodejs/modules/pull/45) | ||
| * Remove stuff relating to implementation. | ||
| * Should occur later today. | ||
| * Please look over this! | ||
|
|
||
| * Use Cases Meeting [#41](https://github.com/nodejs/modules/issues/41) | ||
| * Brad created a forum to discuss different use-cases. | ||
| * Pattern in GitHub discussions to go in-depth into use-cases. | ||
| * Maybe someone else should run that. | ||
| * Please chime in if you're interested. | ||
| * We have time to discuss that today. | ||
|
|
||
| * Online Module Summit [#9](https://github.com/nodejs/modules/issues/9) | ||
| * Had a doodle open for several weeks - decided it will be on the April 3rd. | ||
| * Schedule should be out around Wednesday next week. | ||
|
|
||
| ### Discussion | ||
|
|
||
| * Upstream changes to ESM in nodejs/node [#42](https://github.com/nodejs/modules/issues/42) | ||
| * Bradley: is there anything controversial around vm.module? | ||
| * JDD, Wesley, DanielR, CJ: Seconding notion that avoiding new functionality that is user-facing seems reasonable | ||
| * Named exports: any objections? | ||
| * Bradley: We just said we wanted to avoid user-facing functionality, but that's user-facing functionality. | ||
| * Wesley: We are concerned over named exports being a general mechanism beyond Node's core modules. | ||
| * Jeremiah: \[\[follow-up, something about get-accessors]] | ||
| * Rebeca: Will have to address things on a case-by-case basis | ||
| * Jordan: concerned with anything going forward that can leak into the package ecosystem; should have a lot of caution around what we do. | ||
| * Gil: Instead of setting up principles, maybe we should just decide things on a case-by-case basis. | ||
| * Myles: want "push over pull" - hard to make people keep up to date on everything. | ||
|
|
||
| * Use Cases for ESM in Node.js | ||
| * CJ | ||
| * https://gist.github.com/ceejbot/d8703c71dd5cfba4ba93e755371e96e7 | ||
| * Use-cases that explicitly have no implementation detail in mind. | ||
| * Jeremiah | ||
| * How large do you imagine this list getting? | ||
| * Bradley | ||
| * I like the list, but I want to see adjustments about how the use-cases are fulfilled. | ||
| * Perhaps things are too specific? e.g. code coverage is achieved, maybe not necessarily via a loader hook | ||
| * Daniel: don't be too afraid of the length of the list until it becomes a problem | ||
| * Jan: What about existing direction around code-coverage? | ||
| * CJ: V8's code coverage functionality is speculative at this point; not clear that it satisfies all the use-cases people have in mind. | ||
| * Bradley: keep language in mind! We didn't say anything disparaging just now, but be respectful of others' efforts. | ||
| * Guy: as someone who's worked with/on transpilers as first-class citizens, I do wonder whether the use-case is worthwhile. | ||
| * It'll probably be done in some form, but is it worth listing? | ||
| * Justin: should probably consider it a use-case, not clear if it should be discouraged, but compat concern is a valid one. | ||
| * Daniel: even if we feel like it's not a valid scenario, we should consider them as use-cases if people are doing it today | ||
| * Wesley: ESM should not be seen as an opportunity to start again | ||
| * Ben: Keep in mind other module formats beyond CJS | ||
| * Chris: Easy to try to "editorialize" what we want to do, but it's worth reviewing the use-cases after thinking them through. | ||
| * Jan: We're considering what people do today, but what about what people will *want* to do in the future? | ||
| * Myles: Please fill up that form with use-cases and we can iterate! | ||
| * Maybe a Google Doc (I swear I'm not trying to sell everyone on using Google Docs!) would be easier to iterate on than on GitHub issues? | ||
|
|
||
| * WASM/ES Module integration (Lin Clark) | ||
| * (hopefully I've done this presentation justice! - @DanielRosenwasser) | ||
| * Would like users to be able to use import/export .wasm files from .js files. | ||
| * Importing & exporting ESM declarations reference the same memory locations. | ||
| * Steps in typical ESM | ||
| * Construction: fetch module files, turn them into module records, recursively fetch dependencies (\[\[RequestedModules]]), do the same. | ||
| * Instantiation: | ||
| * Depth-first post-order traversal. | ||
| * Module environment records will be created if necessary | ||
| * Evaluation | ||
| * Bindings are linked together; for variables, set to 'undefined' until set by the respective exporting module. | ||
| * How would this work in WASM? | ||
| * Similar steps | ||
| * What about cyclic dependencies? | ||
| * Live bindings may not work because these values need to be set to undefined, but wasm only sees numeric values. | ||
| * May have to work with TC39 to just remove cyclical import restriction for non-JS module dependencies. | ||
| * Difficult to do eager construction (e.g. bundling) | ||
| * Need to figure this out. | ||
| * Bradley: Problems with live bindings importing from JS? | ||
|
|