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.
- Loading branch information
1 parent
2a882d4
commit 02dd122
Showing
2 changed files
with
253 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,125 @@ | ||
| # Node.js Foundation Modules Team Meeting 2018-07-18 | ||
|
|
||
| * **Recording**: https://www.youtube.com/watch?v=_k63DkTJpUI | ||
| * **GitHub Issue**: https://github.com/nodejs/modules/issues/154 | ||
| * **Minutes Google Doc**: https://docs.google.com/document/d/1zruFPTN9dIpvSEkStxo4fkPenXTdhsLEVkcmoKlVmOA/edit | ||
|
|
||
| ## Present | ||
|
|
||
| - Gus Caplan (@devsnek) | ||
| - Jan Krems (@jkrems) | ||
| - Ben Newman (@benjamn) (took notes below) | ||
| - Michael Dawson (@mhdawson) | ||
| - Matt DuLeone (@mduleone) | ||
| - Bradley Farias (@bmeck) | ||
| - Guy Bedford | ||
| - Jordan Harband (@ljharb) | ||
| - Geoffrey Booth | ||
| - Jeremiah Senkpiel | ||
| - Kevin Smith | ||
| - Geoffrey Booth (@GeoffreyBooth) | ||
| - Saleh Abdel Motaal (@SMotaal) | ||
|
|
||
| ## Agenda | ||
|
|
||
| Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. | ||
|
|
||
| ### Update on Progress (15 minute Timebox) | ||
|
|
||
| * Pull request opened for import.meta.require on core [#130](https://github.com/nodejs/modules/issues/130) | ||
| - 3 minute timebox | ||
| - Jordan: philosophical objection to implementing something we haven’t come to consensus on yet | ||
| * Thinking about deadlines [#123](https://github.com/nodejs/modules/issues/123) | ||
| - 3 minute timebox | ||
| - Jordan: this working group wasn’t convened for expediency, so we should make sure we’re shipping the right thing above all else | ||
| - Bradley: there’s been a thought going around about starting a very minimal implementation that we can all agree on, so that we can decide about future features one at a time (more so than now) | ||
| * Initiative: Terminology / Historical Decisions documents [#119](https://github.com/nodejs/modules/issues/119) | ||
| - 3 minute timebox | ||
| - Jan: Myles said probably no progress this week, but next week he may have more time | ||
| - Guy: let’s get an update on that from Myles next week then | ||
| * Developer Survey [#85](https://github.com/nodejs/modules/issues/85) | ||
| - 3 minute timebox | ||
| - Guy: goal should be to create agenda items to discuss in these meetings, and also iterate on between meetings | ||
| - Michael Dawson: a GitHub issue would make it easier for folks to add ideas asynchronously | ||
| - Bradley: survey shouldn’t just be about user expectations, since we can violate those in service of meeting user needs | ||
| * Features List Adjustments #156 | ||
| - 3 minute timebox | ||
| - Guy: removing duplicates and flagging features that weren’t on the README page | ||
| - Unfortunately don’t have a quorum to merge PRs | ||
|
|
||
| ### Discussion | ||
|
|
||
| * Package-Name-Maps a proposal for bare imports in browsers [#51](https://github.com/nodejs/modules/issues/51) | ||
| - 5 Minute Timebox | ||
| - Jordan: summarizing: | ||
| - Static file that declaratively tells the browser how to resolve bare specifiers to final URLs | ||
| - Has nested structure (scopes) to support deep imports from packages | ||
| - Should be easy to create to adapt Node code to browsers | ||
| - Question: Should Node provide support for optional package name maps, too? | ||
| - Bradley: | ||
| - Folks are making assumptions about the limits of package name maps without fully investigating the feature set | ||
| - For example, you *can* resolve directories and missing file extensions | ||
| - Michael Dawson: | ||
| - How does this fit into overall priorities? Can we think about this later on? | ||
| - Geoffrey Booth: | ||
| - I’m trying to avoid code that behaves differently in Node and browsers, so package name maps are a compatibility concern for me | ||
| - As packages add maps, they could cause breaking changes in resolution, e.g. for code doing deep imports from those packages | ||
| - Lots of value in aligning with the browser on this, though | ||
| - Bradley: I don’t think this is the same level of compatibility concern | ||
| - Always going to be some mismatch between how Node and browsers work, so we should be considering the subset of functionality that works the same in both | ||
| - Bigger compatibility problems with caching, import.meta.url, importing JSON, HTML modules | ||
| - Node is not a subset of the web | ||
| - Using tools to generate package name maps solves some of the problems here | ||
| - Guy: | ||
| - Package name maps can only map bare specifiers, so ./ specifiers aren’t addressed by the proposal | ||
| - Bradley: | ||
| - Shouldn’t make Node dependent on what browsers do here | ||
| - Other approaches to solve the same problems, such as loader hooks | ||
| - Michael Dawson: | ||
| - Node probably would not want to allow mapping bare specifiers to external URLs | ||
| - Undermines Node’s security model, though it works in browsers | ||
| - Guy: Relative import specifiers are one of the big unresolved problems | ||
| - Bradley: that’s something the designers of package name maps should think about | ||
| - Michael Dawson: | ||
| - Maybe we should be providing input to the design of package name maps rather than discussing whether to implement them as-is | ||
| - Guy: | ||
| - If anybody believes there is something we should prioritize on this front please raise, otherwise might be left until we figure out some of the other issues. | ||
| * Have presentation on loaders. [#135](https://github.com/nodejs/modules/issues/135) | ||
| - 20 Minute Timebox | ||
| - Purpose: get folks to stop thinking of loaders as an amorphous API that allows anything | ||
| - Instead, talk about what loaders actually do, and must be able to do | ||
| - Discussion: | ||
| - MD: Are facades not able to change / add things to the module? | ||
| - BF: when we say code is ESM, we don’t touch it, we just load it directly | ||
| - MD: Why would we do otherwise? | ||
| - BF: Changing the ordering of imports would be an example of not directly importing an ESM module | ||
| - BF: We’re following the spec as long as resolution returns an ESM module record | ||
| - Proposal: | ||
| - Move loaders off the main thread for isolation and performance | ||
| - Command line --loader option | ||
| - Environment variables | ||
| - Per-package loader hooks configured in package.json? (BF in favor) | ||
| - Works in user-land currently, though difficult to keep rebasing it against Node master | ||
| - See slides | ||
| - Differences between this proposal and existing ideas | ||
| - See slides | ||
| - Issues | ||
| - Caching is tricky, since it works so differently in the browser than other tools | ||
| - Would prefer to remove caching from the proposal | ||
| - Raw amount of time spent doing transformations is significant | ||
| - Caching compilation results should therefore be easy/simple | ||
| - Can’t solve this problem in this proposal, but should show it can be solved | ||
| * transparent-or-not interop [#90](https://github.com/nodejs/modules/issues/90) | ||
| - 20 Minute Timebox | ||
| - Skipped this due to running out of time | ||
|
|
||
| Saleh Abdel Motaal on terminology document: | ||
|
|
||
| * Not much to say about terminology document progress | ||
| * Two documents | ||
| - One document went “way overboard” (first draft) | ||
| - Another took a different direction with input from other people | ||
| * Guy: can we add one of those documents as a link to the list of resources that we maintain? | ||
| * Saleh: yes, will create a markdown document in the repo | ||
| * Sounds good to everyone | ||
|
|
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,128 @@ | ||
| # Node.js Foundation Modules Team Meeting 2018-08-01 | ||
|
|
||
| * **Recording**: https://www.youtube.com/watch?v=VakyGVeMUpg | ||
| * **GitHub Issue**: https://github.com/nodejs/modules/issues/161 | ||
| * **Minutes Google Doc**: https://docs.google.com/document/d/11oDyvFSnPp3mkyvr8SwRQTKo4aEu9Z0khIiQKPdT1Yk/edit | ||
|
|
||
| ## Present | ||
|
|
||
| - @MylesBorins (Myles Borins) | ||
| - @jdalton (John-David Dalton) | ||
| - @mduleone (Matt DuLeone) | ||
| - @giltayar (Gil Tayar) | ||
| - @GeoffreyBooth (Geoffrey Booth) | ||
| - @devsnek (Gus Caplan) | ||
| - @weswigham (Wesley Wigham) | ||
| - @DanielRosenwasser (Daniel Rosenwasser) | ||
| - @SMotaal (Saleh Abdel Motaal) | ||
| - @mhdawson (Michael Dawson) | ||
| - @targos (Michael Zasso) | ||
| - @benjamingr (Benjamin Gruenbaum) | ||
| - @robpalme (Rob Palmer) | ||
|
|
||
| ## Agenda | ||
|
|
||
| Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. | ||
|
|
||
| ### Approving PRs (2 Minute Timebox) | ||
|
|
||
| * Add Sendil Kumar as an observer [#159](https://github.com/nodejs/modules/pull/159) | ||
| * No objections | ||
|
|
||
| ### Update on Progress (10 Minute Timebox) | ||
|
|
||
| * Have presentation on loaders. [#135](https://github.com/nodejs/modules/issues/135) | ||
| - 3 minute timebox | ||
| * Need to remove modules agenda | ||
| * Create Terminology.md [#158](https://github.com/nodejs/modules/pull/158) | ||
| - 3 minute timebox | ||
| * Last week at a point where it was just Google docs - switched to markdown going forward. | ||
| * Anyone who has any different ideas should weigh in. | ||
| * Developer Survey [#85](https://github.com/nodejs/modules/issues/85) | ||
| - 3 minute timebox | ||
| * Not had time to dig into this | ||
| * Anyone else have bandwidth to take over this? | ||
| * Mostly silence :) | ||
| * Conclusion: Let's kick it back to the discussion thread. | ||
|
|
||
| ### Discussion (45 Minute Timebox) | ||
|
|
||
| * ESM in .js Files: | ||
| - 15 minute timebox | ||
| - Proposals for configuring parse goals of files in --experimental-modules [#160](https://github.com/nodejs/modules/pull/160) | ||
| - ESM in .js files proposals [#150](https://github.com/nodejs/modules/pull/150) | ||
|
|
||
| * Issues around use-cases where Node can parse a .js file with an ESM parse goal. | ||
| * Have come to some consensus that Node needs to support this somehow | ||
| * Doesn't mean that we're getting rid of ESM, just that we want to tackle this use-case | ||
| * Have some ideas to tackle this. | ||
| * Jordan: Agree with Geoffrey's stance; really sounds like this is a mechanism for overriding the default parse goal for a file. | ||
| * Bradley: Happy that this is a cooperative approach and would love to see more of this in the group. Whatever we design needs to be well-thought-out, and whatever features we produce shouldn't step on other features' toes. | ||
| * Michael: Is there any chance that some of the existing use-cases we have can form the basis of what we want? | ||
| * Need to determine which use-cases are satisfied by a given solution. | ||
| * Geoffrey: These use-cases started as "these are the things I can't do in `--experimental-modules`". | ||
| * Bradley: any implementation won't be flawless, which is why we have so much to discuss. But perhaps we can have some agreed-upon "base" implementation to base off of. | ||
| * Like a kernel implementation with bare-bones functionality. | ||
| * Myles: perhaps we can spin up an issue that discusses what this is, then adding the other features that we want later. | ||
| * Perhaps one discussion would be around making a more restrictive loader. | ||
| * May mean that this is a version of the module system nobody would want to use, and would discourage people from using it in production, but would elicit feedback | ||
| * Gil: think it's a really good idea; starts up from ES modules and builds consensus slowly. | ||
| * Saleh: two points | ||
| * Always consider what would happen if we started off with ESM and implemented a CJS loader within ESM. | ||
| * Started off thinking this way, but initially wasn't enough bandwidth when first implementing. | ||
| * We would need to be careful as to which features are bottlenecks and which features are the essentials | ||
| * Myles: have we found consensus? should we table the discussion if so? | ||
| * Jordan: we should make sure that we have consensus; doesn't look like we have consensus | ||
| * Daniel: sounds good on a surface level, but if you solve each of the other use-cases, unsolved use-cases might be "left behind" and unsolved | ||
| * Jordan: Don't care what we ship flagged, but the first unflagged thing we have should *not* be minimal. | ||
| * But need to be careful because big userland features that go flagged for a long time gain momentum | ||
| * Jeremiah: agree with Daniel and Jordan | ||
| * also, unsure how minimal you can get with a big feature like this | ||
| * Bradley: idea was that this minimal kernel doesn't ship anywhere | ||
| * Gil: Agree with Brad - probably don't even have to have an actual implementation | ||
| * Jeremiah: Okay with last few discussion points | ||
| * Michael: want to have some place to land code changes - maybe a fork of the repo. | ||
| * Myles: can incubate that kernel in the fork. | ||
| * Any objections? | ||
| * Geoffrey: still want to be able to improve it | ||
| * Should probably talk about ideas of deprecation warnings at the next meeting. | ||
|
|
||
| * Features adjustments and grouping [#156](https://github.com/nodejs/modules/pull/156) | ||
| - 10 minute timebox | ||
| * Think this was just around fine-tuning certain things around the repo. | ||
| * Conclusion: consensus around approval | ||
|
|
||
|
|
||
| * transparent-or-not interop [#90](https://github.com/nodejs/modules/issues/90) | ||
| - 10 minute Timebox | ||
| * Two ideas: use of `import` interop and `require` interop | ||
| * `import` interop = importing CommonJS modules | ||
| * `require` interop = requiring ESM modules | ||
| * Some people felt that interop is required for a minimal implementation. | ||
| * Wesley: if we're talking strong feelings for interop | ||
| * First expectation is the ability to require or import things, and that regardless of whether the required/imported module is authored in ESM and CJS. | ||
| * Second expectation is the expectation that ESM consumers should be able to get a reasonably similar API regardless of a dependency's format | ||
| * Bradley: what do you specifically mean by that? | ||
| * Wesley: authors need to be able to upgrade to ESM; ESM consumers need to be able to consume the same way regardless of the library format. | ||
| * Jeremiah: some level of interop a requirement, static import of cjs important, note on require-ing esm: considered bad when I had previously consulted JS teacher folks for the TSC in early 2017 (See https://github.com/nodejs/CTC/blob/master/meetings/2017-02-01.md - https://youtu.be/8Snc5lh0VZQ?t=23m29s) | ||
| * Myles: some level of interop is definitely expected | ||
| * import() from CJS is likely the recommended mechanism for | ||
| * Importing Common.js can be supported but shouldn’t be default | ||
| * Likely to fracture the ecosystem if we do otherwise. | ||
| * Important to specify a MIME type for .mjs | ||
| * Brad: Clarify: do you want .js to be reserved for CJS? | ||
| * \[\[Fill this in]] | ||
| * Gil: require() ESM is a no-go for me: just use await import() -. | ||
| * The current implementation enables you to import CJS from ESM, and is called “‘transparent” but it only (correctly!) allows it to come up as a default import. That’s a no go for me too—most transpiled code today assumes “real” transparent interop (i.e. the ability to use named imports), and so this is not very transparent for it. So if we can’t have it real, then let’s not have it at all. | ||
| * Jordan: TC39 enthusiastically said they would strive to make sure CJS can interoperate with ESM. | ||
| * Bradley: sounds like this isn't something we want in a minimal implementation | ||
| * Gil: or any implementation | ||
| * Saleh: I don't consider built-in modules to be CJS. | ||
| * "static import" vs "dynamic import" is something we should be careful of because it implies a completely different story. | ||
| * Bradley: you want to treat static/dynamic imports as separate mechanisms? | ||
| * Saleh: It is more that if I am writing cjs and opt to import(…) then it could be a good way to future proof my codebase as I always expect a promise. If I statically import cjs into esm, then I can rely on module.exports.default = with sync or async in play. | ||
| * Wesley: If TC39 is willing to grant us the ability to have named imports, we should take advantage of that. | ||
| * Daniel: what community fracture did we have in mind before? | ||
| * Jeremiah: care about things actually working well for Node, so being able to statically import CJS is very important. | ||
| * Myles: not against interop, just not sure if it should be the default | ||
|
|