doc: add meeting notes for 2018-03-14

doc/meetings/2018-03-14.md

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