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.
Meeting notes for 07/31 (nodejs#367)
* Meeting notes for 07/31 * important editorial changes * Update doc/meetings/2019-07-31.md Co-Authored-By: Jordan Harband <ljharb@gmail.com>
- Loading branch information
1 parent
b2db493
commit 270ee1d
Showing
1 changed file
with
102 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,102 @@ | ||
| # Node.js Foundation Modules Team Meeting 2019-07-31 | ||
|
|
||
| ## Links | ||
|
|
||
| * **Recording**: Unavailable due to no account access. | ||
| * **GitHub Issue**: https://github.com/nodejs/modules/issues/362 | ||
| * **Minutes Google Doc**: https://docs.google.com/document/d/1nGdMbuJ4hyNJ8QABUwaOiPg8MFfygeBythMc4WL-1mY | ||
|
|
||
| ## Present | ||
|
|
||
| * Modules team: @nodejs/modules | ||
| * Gus Caplan (@devsnek) | ||
| * Rob Palmer (@robpalme) | ||
| * Guy Bedford (@guybedford) | ||
| * Jordan Harband (@ljharb) | ||
| * Bradley Farias (@bmeck) | ||
| * Wesley Wigham (@weswigham) | ||
| * Hassan Sani (@inidaname) | ||
| * Geoffrey Booth (@geoffreybooth) | ||
| * John-David Dalton (@jdalton) | ||
|
|
||
| * Observers | ||
| * Maël Nison (@arcanis) | ||
| * Jamie Kyle (@jamiebuilds) | ||
| * Devon Govett (@devongovett) | ||
| * Alex Aubuchon (@a-lxe) | ||
| * Darcy Clarke (@darcyclarke) | ||
|
|
||
|
|
||
| ## Agenda | ||
|
|
||
| ## Announcements | ||
|
|
||
| *Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. | ||
|
|
||
| * No YouTube LiveStream :-( - we couldn't figure out how to start it | ||
|
|
||
| * New joiner: Mael - interested in the loader hooks | ||
| * New joiner: Devon - spoken to Guy about exports/entries | ||
| * New joiner: Darcy Clarke - joined npm to handle OSS/community ("woo" from JDD & ❤️ from Darcy) | ||
|
|
||
| ### nodejs/node | ||
|
|
||
| * esm: support loading data: URLs [#28614](https://github.com/nodejs/node/pull/28614) | ||
| BF: ESM has a url-based module map now - it's historical. Found use for data-urls in the past. PR ready to load them via import. PR is incomplete - due to lack of MIME parser. Only handles certain MIMEs. Allows in-memory resources representable via data urls. Does not support CJS or C++ modules. Does support JSON, ESM, WASM. Concern: is it useful? Concern: what is a data url? | ||
| Having content-addressable things as a URL. String has the entire resource. Attach a MIME to express format. It's an absolute URL - not hierarchical. Previously used on the web to embed content in another format. Now used on the web for minor use-cases. Convenient for working around oddities. If Node does not support, it's a detriment. Not considered harmful. Security WG invited to look it over - reviews so far same as the browser. | ||
| Use-cases: | ||
| Why use absolute URL for an in-memory resource? You can put records into the main module map. No other way except if you write to file system. Data URLs may have performance issues. The ability to create singleton module addressable by content is the biggest use-case. You can have a thenable module that lets you get the namespace - no other way to do this with dynamic import(). | ||
| JH: Data URLs do not have a current location, so they can't access relative things. This is a historical decision in browsers. Gus and I worked on Symbol.thenable to solve the thenable module issue. The data URL trick was mentioned but it seems like it's only possible to do it on things available absolutely. How do I solve the thenable case? | ||
| BF: You need a way to resolve to an absolute specifier. | ||
| JH: You need import.meta.resolve to be available to handle this use-case. | ||
| BF: Agreed. Should be a separate PR. Browsers only agreed to a sync resolve. Not agreed to async resolve. Something that is not idempotent. Non-trivial for Node to perform sync resolve. Would be a hefty performance cost. We'd need to move the resolve off-main-thread. | ||
| Gus: Disable code generation from strings? Would data URLs get around this? | ||
| BF: That doesn't stop VM methods. Disabling code gen is better talked about in security WG. Not in scope of Modules WG. You could block it in the loader. | ||
| JH: Exports - static strings - but data URIs are content addressable - there is no way to rewrite them all. | ||
| BF: Dynamic strings are not supported in export maps. | ||
| GB: USe-cases. Given loader API is in flux, could we not change it to handle the use-cases tackled by data URLs? | ||
| BF: Loader could do it if they implement data URLs. Creating content addressable use-cases. Thenable trick might be possible with loader alone. | ||
| GB: You could have hashes of the source in the loader if you wanted. | ||
| BF: Don't think the result will be very different from data URLs at the end. Custom loaders can do this, but data URLs are more compatible. | ||
|
|
||
| ### nodejs/modules | ||
|
|
||
| * Loader Hooks [#351](https://github.com/nodejs/modules/issues/351) | ||
| BF: We took a long break on this from last year. Recently, this issue was opened. Now working with Issue creator Alex to record historical progress/intent. Alex is willing to do a lot of work on this. We talked about direct exposure of language hooks (HostImportModuleDynamically) take referring module + specifier string. The specifier may become an object in the future - due to TC39 proposals (assets + trusted types). Must return a Module Record - not necessarily a SourceText Module - could be WASM, JSON, HTML modules. Need a way to differentiate results. | ||
| Other type of hooks: decompose into specialized hooks. Want hooks to not need to implement entire resolution algorithm, e.g. CoffeeScript transform only modifies the text body and does not need to change the resolve. | ||
| Contention over whether to expose low level language hooks or higher-level specialized hooks. | ||
| Jan had a proposal to decompose into phases. | ||
| BF is a fan of the language hooks (the JS-specced hooks). | ||
| There is contention between exposing language and being comprehensive whilst being understandable. | ||
| History suggests we will do both, e.g. a default at the language levels that most high level loaders will not override. We have not discussed this. | ||
| Yarn has expressed desire for some hooks - Node has not had an answer for this. | ||
| Yarn would like a resolver that can do partial resolution - you stop at a point in time such as when you have a bare-name, rather than resolving all the way to what "main" is point to. | ||
| Gus: | ||
| Mael: We couled re-execute but it might not be what we want to do. | ||
| BF: This is also a problem for virtualized file-systems because the default resolver could not handle it. Cloud providers are considering these. Yarn/Tink/Entropic are also looking at virtualization. | ||
| GB: Does this intercept all fs.read ops? | ||
| BF: Yes, for embedded things. | ||
| Mael: We patch many of the filesystem methods - becomes indistinguishable. Yarn tried to do all of them. A Loader API would mean we could stop this. | ||
| GB: Do you want to know where a package is without looking inside? | ||
| Mael: Yes - we have part that is synchronous, but reading pkg.json needs file system access so might need to be async. We only care about the first one. | ||
| GB: If Node exposed pkg-only resolution is that useful? | ||
| Mael: Yes. | ||
| GB: You're not using node_modules resolution. So I guess that's not useful for you. We've talked about exposing ESM resolve API. But if you're not resolving into there, I don't know if it's useful. | ||
| Mael: node_modules bit we shortcut. Other part is resolving into index.js. Assume Node uses "modules" field, in which case Yarn overrides have it. We must match Node. If we could just resolve pkg.json and index.js that's fine by us. | ||
| GBB: Use-cases fell into two cases: 1. coffeescript transform. 2. resolve specifiers that may not be on disk, e.g. @ might refer to package root, or add a file extension. | ||
| BF: We haven't changed loaders in many months. Current in master are a subset of the language hooks. You can only return locations of module records. | ||
| GBB: Does this match your expectations? | ||
| BF: I expect both. Power users like Yarn want to take over the runtime. Then specialized hooks are for people who don't want to do that. If we improve the default resolve algorithm (e.g. policies) then you might break expectations, e.g. coffeescript will want those policies to be retained. So compatibility concerns. | ||
| Next steps: Alex and BF are working on a design doc we'll push the constraints back to the loader thread. Contentious topics are language vs specialized hooks. Then data design questions. Big desire for loader hooks to support in-memory resources. | ||
| GBB: Could someone write up language hooks vs specializer hooks? | ||
| BF: Imagine a constructor in a class. If you don't provide it, you get the default. It calls super() properly. We're talking about what that constructor does. With specialized hooks, we break it down inside that constructor, e.g. describing how super() is called. One is the overall operation. Other is a sub-operation. Specialized hooks may allow certain optimizations. People could think about which hooks they want. Please write up your desires/constraints and send to Bradley/Alex. | ||
|
|
||
|
|
||
| * Package Exports [#341](https://github.com/nodejs/modules/issues/341) | ||
| DEFERRED | ||
|
|
||
| ### Observer PRs | ||
|
|
||
| No objections to adding Mael/Devon/Darcy | ||
|
|
||
|
|