Skip to content
This repository was archived by the owner on Sep 2, 2023. It is now read-only.

Commit 5388eff

Browse files
committed
1 parent af7d918 commit 5388eff

File tree

1 file changed

+119
-0
lines changed

1 file changed

+119
-0
lines changed

doc/meetings/2018-03-14.md

Lines changed: 119 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,119 @@
1+
# Node.js Foundation Modules Team Meeting 2018-03-14
2+
3+
* **Recording**: https://www.youtube.com/watch?v=U9xG4JPdznA
4+
* **GitHub Issue**: https://github.com/nodejs/modules/issues/47
5+
* **Minutes Google Doc**: https://docs.google.com/document/d/1fwQ_XkYyJO3p5fE2o9H9i7iWii0LB4OyQxepBlaa6-Y/edit
6+
7+
## Present
8+
9+
Chris Dickinson (@chrisdickinson)
10+
Myles Borins (@MylesBorins)
11+
Wesley Wigham (@weswigham)
12+
Michael Zasso (@targos)
13+
Gus Caplan (@devsnek)
14+
Gil Tayar (@giltayar)
15+
C J Silverio (@ceejbot)
16+
Torgny Bjers (@tbjers)
17+
Matt DuLeone (@mduleone)
18+
Benjamin Gruenbaum (@benajingr)
19+
Daniel Rosenwasser (@DanielRosenwasser)
20+
John-David Dalton (@jdalton)
21+
Rebecca Turner (@iarna)
22+
Lin Clark (@linclark)
23+
Guy Bedford (@guybedford)
24+
Bradley Farias (@bfarias)
25+
Jordan Harband (@ljharb)
26+
Hassan Sani (@inidaname)
27+
Justin Fagnani (@justinfagnani)
28+
Ben Newman (@benjamn)
29+
Jeremiah Senkpiel (@Fishrock123)
30+
Jan Olaf Krems (@jkrems)
31+
32+
## Agenda
33+
34+
Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting.
35+
36+
37+
### nodejs/modules
38+
39+
#### Approving PRs ~ 1 minute timebox
40+
41+
* doc: add meeting notes for 2018-02-28 [#38](https://github.com/nodejs/modules/pull/38)
42+
* No objections!
43+
44+
#### For awareness ~ 3 minute timebox
45+
46+
* doc: add MANIFESTO.md [#45](https://github.com/nodejs/modules/pull/45)
47+
* Remove stuff relating to implementation.
48+
* Should occur later today.
49+
* Please look over this!
50+
51+
* Use Cases Meeting [#41](https://github.com/nodejs/modules/issues/41)
52+
* Brad created a forum to discuss different use-cases.
53+
* Pattern in GitHub discussions to go in-depth into use-cases.
54+
* Maybe someone else should run that.
55+
* Please chime in if you're interested.
56+
* We have time to discuss that today.
57+
58+
* Online Module Summit [#9](https://github.com/nodejs/modules/issues/9)
59+
* Had a doodle open for several weeks - decided it will be on the April 3rd.
60+
* Schedule should be out around Wednesday next week.
61+
62+
### Discussion
63+
64+
* Upstream changes to ESM in nodejs/node [#42](https://github.com/nodejs/modules/issues/42)
65+
* Bradley: is there anything controversial around vm.module?
66+
* JDD, Wesley, DanielR, CJ: Seconding notion that avoiding new functionality that is user-facing seems reasonable
67+
* Named exports: any objections?
68+
* Bradley: We just said we wanted to avoid user-facing functionality, but that's user-facing functionality.
69+
* Wesley: We are concerned over named exports being a general mechanism beyond Node's core modules.
70+
* Jeremiah: \[\[follow-up, something about get-accessors]]
71+
* Rebeca: Will have to address things on a case-by-case basis
72+
* Jordan: concerned with anything going forward that can leak into the package ecosystem; should have a lot of caution around what we do.
73+
* Gil: Instead of setting up principles, maybe we should just decide things on a case-by-case basis.
74+
* Myles: want "push over pull" - hard to make people keep up to date on everything.
75+
76+
* Use Cases for ESM in Node.js
77+
* CJ
78+
* https://gist.github.com/ceejbot/d8703c71dd5cfba4ba93e755371e96e7
79+
* Use-cases that explicitly have no implementation detail in mind.
80+
* Jeremiah
81+
* How large do you imagine this list getting?
82+
* Bradley
83+
* I like the list, but I want to see adjustments about how the use-cases are fulfilled.
84+
* Perhaps things are too specific? e.g. code coverage is achieved, maybe not necessarily via a loader hook
85+
* Daniel: don't be too afraid of the length of the list until it becomes a problem
86+
* Jan: What about existing direction around code-coverage?
87+
* CJ: V8's code coverage functionality is speculative at this point; not clear that it satisfies all the use-cases people have in mind.
88+
* Bradley: keep language in mind! We didn't say anything disparaging just now, but be respectful of others' efforts.
89+
* Guy: as someone who's worked with/on transpilers as first-class citizens, I do wonder whether the use-case is worthwhile.
90+
* It'll probably be done in some form, but is it worth listing?
91+
* Justin: should probably consider it a use-case, not clear if it should be discouraged, but compat concern is a valid one.
92+
* 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
93+
* Wesley: ESM should not be seen as an opportunity to start again
94+
* Ben: Keep in mind other module formats beyond CJS
95+
* Chris: Easy to try to "editorialize" what we want to do, but it's worth reviewing the use-cases after thinking them through.
96+
* Jan: We're considering what people do today, but what about what people will *want* to do in the future?
97+
* Myles: Please fill up that form with use-cases and we can iterate!
98+
* 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?
99+
100+
* WASM/ES Module integration (Lin Clark)
101+
* (hopefully I've done this presentation justice! - @DanielRosenwasser)
102+
* Would like users to be able to use import/export .wasm files from .js files.
103+
* Importing & exporting ESM declarations reference the same memory locations.
104+
* Steps in typical ESM
105+
* Construction: fetch module files, turn them into module records, recursively fetch dependencies (\[\[RequestedModules]]), do the same.
106+
* Instantiation:
107+
* Depth-first post-order traversal.
108+
* Module environment records will be created if necessary
109+
* Evaluation
110+
* Bindings are linked together; for variables, set to 'undefined' until set by the respective exporting module.
111+
* How would this work in WASM?
112+
* Similar steps
113+
* What about cyclic dependencies?
114+
* Live bindings may not work because these values need to be set to undefined, but wasm only sees numeric values.
115+
* May have to work with TC39 to just remove cyclical import restriction for non-JS module dependencies.
116+
* Difficult to do eager construction (e.g. bundling)
117+
* Need to figure this out.
118+
* Bradley: Problems with live bindings importing from JS?
119+

0 commit comments

Comments
 (0)