|
| 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