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.
Merge pull request #398 from SMotaal/master
doc: Minutes for 2019-10-09
- Loading branch information
Showing
1 changed file
with
116 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,116 @@ | ||
| # Node.js Foundation Modules Team Meeting 2019-10-09 | ||
|
|
||
| ## Links | ||
|
|
||
| * **Recording**: https://www.youtube.com/watch?v=l4lb-mURzyw&v=-6XBx7yinrI | ||
| > [Part 1](https://www.youtube.com/watch?v=l4lb-mURzyw) | [Part 2](https://www.youtube.com/watch?v=-6XBx7yinrI) | ||
| * **GitHub Issue**: https://github.com/nodejs/modules/issues/396 | ||
| * **Minutes Google Doc**: https://docs.google.com/document/d/1ZkgPmwULxJz2kLEHRZyPqbJnlXcWUgB1ouphPvxKlGE/edit | ||
|
|
||
| ## Present | ||
|
|
||
| * Modules team: @nodejs/modules | ||
| * Jan Krems (@jkrems) | ||
| * Alex Aubuchon (@A-lxe) | ||
| * Gus Caplan (@devsnek) | ||
| * Geoffrey Booth (@GeoffreyBooth) | ||
| * Guy Bedford (@guybedford) | ||
| * Jordan Harband (@ljharb) | ||
| * Saleh Abdel Motaal (@SMotaal) | ||
| * Wesley Wigham (@weswigham) | ||
| * Bryan Clark (@clarkbw) | ||
| * Ruy Adorno (@ruyadorno) (observer/guest) | ||
| * Rob Palmer (@robpalme) | ||
|
|
||
| ## Agenda | ||
|
|
||
| ## Announcements | ||
|
|
||
| * Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. | ||
|
|
||
| ### nodejs/modules | ||
|
|
||
| * Roadmap update [#387](https://github.com/nodejs/modules/pull/387) | ||
|
|
||
| * Geoffrey: Based on discussions in latest meeting. Shouldn’t be surprising. | ||
| * Guy: Just looking for approval? | ||
| * Geoffrey: Assuming that we want to unflag for v12 LTS, anything not done yet was moved to stage 4 (post-unflag). This includes loaders, self reference (`@/`), … - all should be okay to ship after unflagging. Only blocker is PR to fix tests. | ||
| * Guy: Not as simple, update on unflagging PR? | ||
| * Geoffrey: May be documentation update, may be able to land without quorum? | ||
| * Jordan: As long as this doesn’t imply final consensus on unflagging, I’m fine with landing. We need a proper decision on that. If this is just a "guess" on what’s likely to be in the unflaged implementation, it may be misleading. | ||
| * Guy: So far focussed on technical blockers to unflagging, not yet ready to make decisions on features to go in. Biggest change is async node bootstrap which may change timing, promise/task queues, emitting events, async hooks, etc.. | ||
| * Guy: Going to talk to Matteo about async hook design decisions. Rough estimate at ~50% before we can talk about consensus / make calls on unflagging. | ||
| * Saleh: What are the critical choices that force us to do an async bootstrap? Are there other places than modules where async bootstrap would have helped / would help in the future? | ||
| * Guy: In theory, it should be historical that it is sync. This is just the first time core is forced to do something async. TLA may force us to be async sooner or later. We may be able to make it sync but not clear if it’ll pay off. | ||
| * Wes: We may be able to spin event loop without microtasks. | ||
| * Jan: Don’t we need microtasks for the modules-related Promises? | ||
| * Guy: Happy to have other people look into it, running out of cycles to do it myself. If we don’t get this figured out soon, it doesn’t look good for unflagging this month. | ||
| * Geoffrey: Don’t need to get it in this month (technically) for unflagging in LTS according to Myles. There may be wiggle room but there’s no precedent for unflagging a big feature within LTS so we can’t depend on it being possible. | ||
| * Geoffrey: Once tests pass - can we unflag? | ||
| * Jan: We should have an actual explicit decision on unflagging. | ||
| * Geoffrey: What does that mean in practice? Can we know already if we’ll have consensus to unflag in a few weeks? | ||
| * Jordan: Not convinced that loaders block unflagging. Hang-up to me is - beyond extension searching etc. - compatibility of a published package with pre- and post-module node. Achievable with exports-dot if it’s included in unflagged version. Second kind of compat is require and import possible using same specifier, in some form. The use case needs to be covered somehow. Don’t have time myself but time shouldn’t completely decide what is possible with a "complete" modules implementation. Don’t want to be blocker but we should be aware of the effect we’ll have. If we unflag right now, package authors may not know how to properly deal with ESM migration, bumping versions correctly, handle migration, etc.. | ||
| * Jan: Need to make choice between one-resolution-per-specifier-and-source vs. maximum-adoption (import may resolve to module while require may resolve the same specifier to another URL). | ||
| * Jordan: Singleton should be dealt with by package authors, better to optimize for maximizing ESM code running. | ||
| * Geoffrey: Others have already objected to "dual mode specifiers". There’s no ideal outcome most likely. | ||
| * Jordan: Right now pkg.exports is ~import map. Maybe there’s a way that can remap a specifier somehow, not by default, to opt into divergent specifiers. | ||
| * Geoffrey: Similar to declaring named exports in package.json. | ||
| * Jordan: Difference between making it impossible and being annoying but potentially temporary. | ||
| * Geoffrey: People will have tools and keep using it (module field etc.) and may use them to work around pain points. Should have another discussion around this at next meeting. | ||
|
|
||
|
|
||
|
|
||
| * JSON modules are being reverted on web [#391](https://github.com/nodejs/modules/issues/391) | ||
|
|
||
| * Guy: JSON modules have been backed out of HTML based on security concerns. Other syntax for importing data formats (like JSON) is being discussed. Suggestion: Reflag in node. | ||
| * Jan: Flagging right now seems cheap, let’s do it and potentially undo once the dust has settled. | ||
| (no objections) | ||
|
|
||
|
|
||
|
|
||
| * Script-based configuration files in "type": "module" packages [#389](https://github.com/nodejs/modules/issues/389) | ||
|
|
||
| * Guy: Found regressions on packages that eagerly adopted type:module where the packages weren’t consistently using .js for ESM only. Babel transforms & tool configs may break. For now it’s disabled but we have to decide how to go forward. Opposite direction suggested in https://github.com/nodejs/node/pull/29862 - do not restrict CJS loader for type:module, just not inject into ESM. That way it will generally fail when used from the wrong loader (because of syntax errors). Wesley had concerns? | ||
| * Wes: Allowing CJS to require JS inside of type:module is walking back the clear answer on how to interpret a file. Tools can no longer tell from the file how it should be interpreted. Heuristics used today *could* be dropped but backing out of type:module would force them back. | ||
| * Saleh: Maybe `createLegacyRequire(path)(…)` || `require.legacy(…)` that works (but is discouraged) and ignores type. | ||
| * Wes: They can already do that. ESLint already switched to another implementation. It can already be done. But code exists that "works" because it assumes the wrong semantics. | ||
| * Geoffrey: I can understand why tool authors are annoyed that node "broke" them. There’s not that many of them, they can fix it on their side. Determining how to interpret a file requires a heuristic today. | ||
| * Wes: But we’re trying to move away from those heuristics. .js is always CJS in a node package unless it’s mjs or type:module. | ||
| * Geoffrey: Suggested having a method to determine how node would interpret a file. | ||
| * Jan: I don’t think there’s disagreement that we want all .js in type:module to be enforced to be ESM. We could start with a deprecation warning right now. | ||
| * Wes: That’s fine as long as type:module hasn’t been shipped. We shouldn’t keep the deprecation warning after type:module has shipped (unflagged). | ||
| * Guy: Let’s try to add the warning now, aiming to make it throw when modules ship (are unflagged). | ||
| * Wes: That’s fine as long as the warning doesn’t survive unflagging. | ||
| * Jordan: (As maintainer of the resolve npm impl) +1 to fewer variants being live. | ||
|
|
||
|
|
||
|
|
||
| * Loader Hooks [#351](https://github.com/nodejs/modules/issues/351) | ||
| * Guy: Skipping over | ||
| * Alex: Changed `--loader` option to `--experimental-loader` (With an undocumented alias to `--loader`) — [#29752](https://github.com/nodejs/node/pull/29752) | ||
|
|
||
| * Proposal: Support loading package by own "name" [#306](https://github.com/nodejs/modules/issues/306) | ||
|
|
||
| * Guy: Uncertainty about the symbol being used, parcel is pushing for ~. | ||
| * Jordan: Originally was ~, Gus objected (or echoed) because of posix home directory. Settled on @. If nobody has a strong objection, we could land. | ||
| * Geoffrey: Matteo did bring up ~ as well (TSC member), cc’d TSC member. | ||
| * Jordan: Can we agree on either being okay, as long as TSC picks one? | ||
| * Geoffrey: Think we have consensus? | ||
|
|
||
|
|
||
|
|
||
| * Unflagging experimental exports (https://github.com/nodejs/node/pull/29867) | ||
|
|
||
| * Guy: Posted PR, currently behind own flag. May be important to unflag modules itself. We don’t need to land right now. Order is important here. | ||
| * Jan: Change of position: Fine to land right now and make self-reference a follow-up. | ||
| * Saleh: At some point there may be dual mode. If we do unflag exports - is a package having multiple modes an issue? | ||
| * Guy: Right now exports are independent of mode/interpretation. They are orthogonal. You can use exports to map to different files for different implementations - using different paths. | ||
| * Saleh: Clarifying - meant one specifier pointing to different files. | ||
| * Guy: That’d be conditional mappings. Not implemented yet. | ||
| * Jan: But design space for "forking" of specifiers is open using arrays. | ||
| * Saleh: Yes, perfect, so dual mode leads to enhancement that does not break export maps in the ecosystem on various versions of Node.js (thanks) | ||
| * Jordan: Would be happy to unflag right now. But we should unflag around the same time as modules. | ||
| * Guy: We could also unflag as a single PR? | ||
| * Goeffrey: Should we just remove the additional flag and move exports to `--experimental-modules`? | ||
| * Jordan: If we come up with pre-modules/post-modules outside of exports, we could also ship exports immediately. | ||
| * (consensus) |