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 43
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
refs: #528 closes: #528 refs: https://docs.google.com/document/d/1FLK3nkCpxF6D-JFuoZlGpovF0lpSQ_8TP3wini6FsB0/edit
- Loading branch information
Showing
1 changed file
with
71 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,71 @@ | ||
| # Node.js Modules Team Meeting 2020-06-17 | ||
|
|
||
| ## Links | ||
|
|
||
| * **Recording**: http://www.youtube.com/watch?v=hFfwRkR-L-I | ||
| * **GitHub Issue**: https://github.com/nodejs/modules/issues/528 | ||
| * **Minutes Google Doc**: https://docs.google.com/document/d/1FLK3nkCpxF6D-JFuoZlGpovF0lpSQ_8TP3wini6FsB0/edit | ||
|
|
||
| ## Present | ||
|
|
||
| * Modules team: @nodejs/modules | ||
|
|
||
| - Myles Borins (@MylesBorins) | ||
| - Jordan Harband (@ljharb) | ||
| - Darcy Clarke (@darcyclarke) | ||
| - Rob Palmer (@robpalme) | ||
|
|
||
| ## Agenda | ||
|
|
||
| ## Announcements | ||
|
|
||
| *Extracted from **modules-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting. | ||
|
|
||
| ### nodejs/node | ||
|
|
||
| #### Special treatment for package.json resolution and exports? [#33460](https://github.com/nodejs/node/issues/33460) | ||
|
|
||
| - MB: There are ways to get an entrypoint but it may not be the package root. So heuristics may be needed to find package.json | ||
| - JH: package.jsons can be copied so you can't know for sure. API for bare-identifier to package.json provides a way for tools to work. | ||
| - MB: We could publish an ecosystem package - find-package-json - would be siblings at the root of node_modules. This matters when I want my dependency's package.json. If that hierarchy is guaranteed, direct dependencies should be peers. | ||
| - JH: Use-case is I'm a tool used in a project I don't control. So answer won't be relative to the tool's location. | ||
| - MB: So I'm a dependency of the project. Maybe I'm bundling. Instrumented by the top-level package and I need to find other dependencies. You need to set the root. | ||
| - JH: You can put node_modules at the root of your disk. | ||
| - MB: Everything is resolved to yourself. If overlapping. | ||
| - JH: Node already has the logic. You don't know where your dependencies will come from. | ||
| - MB: Why is this different to the root of your resolve? | ||
| - JH: With exports, you can't know for sure. Will show an example offline. | ||
| - MB: Let's try the ecosystem package approach first. | ||
| - JH: If it can 100% work in userland that's fine. | ||
| - MB: Some people may want to prevent package.json leaking to users. Or maybe if people are ok with it being public, we just change our defaults. | ||
| - GB: Depends how many tools are impacted. Softly feeling we don't need to do anything. | ||
| - MB: If exports is used to generate import maps, maybe package.json shouldn't be available. It's easier to remember the rule that "only exports get exported". | ||
| - JH: README can be used a hint. | ||
| - GB: API to get package root would permit fs.readFile to grab package.json | ||
| - MB: Not 100% but the basic algorithm to resolve the file and then crawl will probably always work. | ||
| - JH: Babel has an option that duplicates package.json | ||
| - GB: You don't look for package.json - you look for node_modules | ||
| - MB: If we had module.resolve to give a path, with a changeable root, you could always go up to node_modules then back down. | ||
| - JH: It's possible. Resolve already needs to duplicate the whole algorithm. | ||
| - MB: If we expose resolve, that gives you everything you need. NODE_PATHS may confuse here. | ||
| - JH: Even if it is doable in userland, it seems silly to not put it in Node. | ||
| - MB: I think we need a meta-issue to discuss this. Bring up a series of APIs at once. Maybe we want to introduce a top-level resolve module. My gut is that we don't need a new API for this. | ||
| resolveType() resolveRoot() resolvePath(). resolveRoot() may be better because it is environment-agnostic. | ||
| - JH: I remain convinced we should have a resolvePackageRoot() somewhere. | ||
| - MB: Maybe a getPackageMetadata. It could be synchronous. There is a large cost to putting this API in core. | ||
|
|
||
|
|
||
| #### module: CJS exports detection [#33416](https://github.com/nodejs/node/pull/33416) | ||
|
|
||
| - GB: How do you define success? Maybe not everything was intended to be exported. | ||
| - MB: Maybe's there's a field in package.json to enable the heuristic? Less work than writing a wrapper. | ||
| - GB: We need to make it as good as possible then merge it in behind a flag to get feedback. | ||
| - JH: People are going to want to use this on abandoned packages. The heuristic is more likely to break due to a change in Babel that upsets the heuristic. | ||
| - MB: User research may be good - but biased responses to "do you want exports for CommonJS if it works X% of the time?" | ||
| - GB: Let's study guy's PR. | ||
| - MB: Releasing under an experimental flag seems worth exploring. | ||
| - GB: It uses a WASM library for parsing. | ||
| - MB: Can we land it non-observable when the flag is off? If so, let's do it. | ||
| - RP: Do we have many people complaining about lack of named exports for CJS? | ||
| - GB: Not really. A few issues. | ||
| - MB: Adding this experimental flag is nice. Combined with auto-extension flags, maybe that gives you the webpack experience as an opt-in mode. |