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
121 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,121 @@ | ||
| # Node.js Foundation Modules Team Meeting 2019-02-20 | ||
|
|
||
| * **Recording**: https://www.youtube.com/watch?v=H34VieUOGu4 | ||
| * **GitHub Issue**: https://github.com/nodejs/modules/issues/270 | ||
| * **Minutes Google Doc**: https://docs.google.com/document/d/1AFnHc85SzFZFUqL6xL7xTDOmFB9FM6q9yapjYGQiXi0/edit | ||
|
|
||
| ## Present | ||
|
|
||
| - John-David Danger Dalton (@jdalton) | ||
| - Myles Borins (@MylesBorins) | ||
| - Bradley Farias (@bmeck) | ||
| - Wesley Wigham (@weswigham) | ||
| - Daniel Rosenwasser (@DanielRosenwasser) | ||
| - Gus Caplan (@devsnek) | ||
| - Jeremiah Senkpiel (@Fishrock123) | ||
|
|
||
| ## Agenda | ||
|
|
||
| Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. | ||
|
|
||
| ### Note | ||
|
|
||
| This is an out of band follow up to last week’s meeting. 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 | ||
| * Review last weeks discussion | ||
| * 5 minute timebox | ||
| * CommonJS interop | ||
| * 10 minute timebox | ||
| * https://github.com/nodejs/ecmascript-modules/pull/261 | ||
| * Out of order execution (https://github.com/nodejs/ecmascript-modules/pull/31) | ||
| * Leaned against out-of-order execution | ||
| * Shipping just default exports | ||
| * Leaning towards not doing this if named exports are a possibility. | ||
| * Removed some of the functionality here, but the "plumbing" is there | ||
| * Myles: could we put that behind a flag? | ||
| * Daniel: Seems reasonable, but just concerned with the name. call out that it's an interop strategy. | ||
| * Jeremiah: Shipping without interop seems like not an option. | ||
| * Myles: Just as an FYI, pushing back means we'll need to go to a vote | ||
| * Myles: So do we have objections? | ||
| * Geoffrey: wouldn't feel comfortable shipping because messaging might be confusing if that strategy isn't what we want to go with in the first place. Also, if we take it back, people could say we're "removing interop". | ||
| * Myles: Don't think that's true, we're within our right to remove anything flagged. | ||
| * Jordan: meta-point: certain choices have to be made for different use-cases. Making different choices shut down certain use-cases. Want us to think about our use-cases in the final product. | ||
| * Wesley: we're generally in agreement that we and TC39 want to support named exports. Why can't we ship one of the proposals behind a flag? | ||
| * Brad: which one? OOO-exec? JDD's? Guy's? | ||
| * Wesley: not the OOO-exec one | ||
| * Brad: `export *` has come up in the committee again. | ||
| * Wesley: these changes aren't observable for code people tend to write | ||
| * Brad: These changes are observable. | ||
| * Wesley: Minor in comparison to the change of not having any interop | ||
| * Gus: these are pretty observable | ||
| * Wesley: for people writing code, are they observable? | ||
| * Gus: Not necessarily, but what about bundlers? Linters? Those need static imports | ||
| * Wesley: all of these tools already analyze just fine despite dynamic behavior. | ||
| * Myles: we need true static analyzability for the sort of cold start improvements that we hope to achieve in Node core. | ||
| * Jordan: this is the sort of thing that can't be handled in TC39. \[\[fill in later]] | ||
| * Wesley: going with a non-final version of named imports is the more reasonable thing to do than shipping a default only | ||
| * Brad: would you be okay throwing that implementation out if we can't make it work? | ||
| * Daniel: we'd potentially have to throw some implementation out no matter what we ship | ||
| * Wesley: and shipping named exports is more aligned with what this group wants to ship | ||
| * Brad: counter-point: should we ship the thing we're more likely to be able to ship? | ||
| * Myles: There are more people who want no interop than no named interop (with just a default import available) | ||
| * Named exports | ||
| * Have a path towards supporting it with dynamic modules. | ||
| * Some people might feel discouraged from the work, but it's an open path. | ||
| * Geoffrey: can we just ship this unflagged? | ||
| * \[\[objections]] | ||
| * JDD: would be against even a flagged implementation shipping | ||
| * Myles: is this because `export *`? | ||
| * JDD: not clear that dynamic modules will solve this exactly; the | ||
| * Brad: strong mischaracterization of Guy's work, calling it a failed proposal is unreasonable! | ||
| * JDD: Just because one person has worked on it doesn't mean we need to rubber-stamp it. I am a delegate and I would block the current proposal as-is. | ||
| * Brad: work being from just one person doesn't mean it's good or bad, it's something that we can iterate on | ||
| * JDD: if we're trying to come to the best design, I don't believe this is the right direction. | ||
| * Jordan: why do you find default acceptable, but the rest of it not? | ||
| * JDD: `default` doesn't cause any spec changes, has a reasonable precedent. Would rather start from low-to-no-effort spec work. Otherwise you have to throw on syntax. | ||
| * Wesley: No named exports means you *do* have errors on syntax. | ||
| * JDD: no, that's erroring on bindings that don't exist | ||
| * Wesley: there's no difference as a user!!!! | ||
| * Refs: | ||
| * CommonJS import interoperability decisions [#264](https://github.com/nodejs/modules/issues/264) | ||
| * 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) | ||
| * WIP [Do not merge] - Irp type dynamic modules [#29](https://github.com/nodejs/ecmascript-modules/pull/29) | ||
| * File Extension Resolution | ||
| * 15 minute timebox | ||
| * Refs: | ||
| * File extension/directory index resolution in ESM [#268](https://github.com/nodejs/modules/issues/268) | ||
| * Existing resolution algorithm for CJS searches through a handful of extensions to search. | ||
| * Currently the minimal kernel doesn't support this. Should we? People on the committee don't want this to begin with. | ||
| * Brad: we should be okay shipping without it initially and then shipping. That way we have two paths later on. | ||
| * Geoffrey: if we make this opt-in, that's fine. users become aware of the behavior. | ||
| * Jordan: I would object to shipping without it unflagged. I find extension lookup so critical that I don't think we can ship without it. | ||
| * Gus: to people who don't want to ship by default, I'm confused. If you don't want this feature, don't use it and just be explicit specifiers. | ||
| * Myles: we want an ecosystem of modules that can be shared across all ecosystems/runtimes. If you allow people mixing, your dependencies can throw a wrench in the mix if their paths don't work. | ||
| * Could we use something like import maps to make this easier. | ||
| * Myles: that doesn't work, import maps would blow up exponentially in size to model the entire dependency tree. They're meant for modeling only a few bare imports. | ||
| * Gus: I could totally see Yarn or npm shipping something that just generates these files anyway. | ||
| * Loaders | ||
| * 5 minute timebox | ||
| * Requirements to replace upstream | ||
| * 10 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) | ||
| * Import file specifier proposal implementation [#256](https://github.com/nodejs/modules/issues/256) | ||
| * Mode: esm proposal [#247](https://github.com/nodejs/modules/issues/247) | ||
|
|