#### Meeting from: January 27th, 2021

# Open RFC Meeting (npm)

### Attendees
- Darcy Clarke (@darcyclarke)
- Christian Siebmanns (@christian24)
- Nathan LaFreniere (@nlf)
- Ruy Adorno (@ruyadorno)
- Isaac Z. Schlueter (isaacs)
- Wes Todd (@wesleytodd)
- Michael Garvin (@wraithgar)
- Rick Markins (@rxmarbles)

### Agenda

1. **Housekeeping**
1. Introduction(s)
1. [Code of Conduct Acknowledgement](https://www.npmjs.com/policies/conduct)
1. Announcements
1. **File Path Resolution Review:**
1. **Summary:**
* `file:` behaivour changed in v7 - no longer support installing dependencies of packages that are not nested
1. **Questions:**
* Do we agree with how it's working today?
* How would we change it?
1. **Related Items:**
* **Issue**: [#2145 [BUG] npm7 does not create transitive node_module folders for dependencies referenced via file:/](https://github.com/npm/cli/issues/2145)
1. **Workspaces Review:**
1. **Summary:**
* It's been brought up several times that the mental model we have today of "hoisting" dependencies should be re-examined as "sharing"; This aligns with some feedback/feature request we've already recieved to add `no-hoist` as a config to Workspaces. Reviewing & thinking critically about the behaivour of our existing strategy will help us lay a solid foundation/understanding before we start the next phase of work in this space.
1. **Questions:**
* Do we agree with how it's working today?
* How would we change it?
1. **Related Items:**
* **Issue**: [#2339 npm v7 does not install linked packages dependencies](https://github.com/npm/cli/issues/2339)
* **Issue**: [#301 [RRFC] Workspaces: support to version specifiers other than semver ranges](https://github.com/npm/rfcs/issues/301)
* **PR**: [#117 RFC: npm workspaces - Working with workspaces](https://github.com/npm/rfcs/pull/117)

### Notes

> Note: this is not a 1:1 notes of quotes, moreso paraphrased context/sentiment as close to as possible documented in realtime

1. **File Path Resolution Review**
* @isaacs we have options here in terms of making this more configurable
* @wesleytodd missing old behaivour of copying
* @isaacs may not want to resolve dependencies that already have lock file
* @wesleytodd has there ever been a consideration to link back to the consumer?
* @isaacs maybe we can treat a link target package-lock.json kind of like npm-shrinkwrap.json file?
* @isaacs might be able to say that we don't install linked dependencies but we have a great workspace experience
* @isaacs need an RFC on linked dependencies (referencing what we do/don't install & why)
* @isaacs then, review workspace implementation (ie. what should/shouldn't be shared)
* @wesleytodd like this because it punts this a bit
* @isaac action: will create the initial draft of the RFC outlining the current behaivour
1. **Workspaces Review:**
* @isaacs need the document of usecases, including the precursor drafted RFC from above
* @darcyclarke should we try to formulate some questions to be answered by these RFCs?
* **Questions:**
* Given a workspace within a project, for each of its dependencies, in which scenarios should that dependency be shared among all/some other workspaces within the project, in which should it reference a workspace within the project (if one exists), and in which should it be isolated from the other workspaces within the project?
* Leave aside any implementation approaches. We will figure out an optimal tree design once we have the set of behavioral design constraints established.
* Eg:
* `packages/a` depends on `b@1.x`. `packages/b` is v1.2.3. `require('b')` from within `packages/a` should refer to `packages/b`
* `packages/a` depends on `b@1.x`. `packages/b` is v2.3.4. `require('b')` from within `packages/a` should *not* refer to `packages/b`, because it is not a valid resolution.
* `packages/a` depends on `c@1.x`. `packages/b` depends on `c@1.x`. `require('c')` from within `packages/a` (should|should not) refer to the same thing as `require('c')` from within `packages/b`. (When should it? When should it not?)
* What configurations should impact the decision to share or isolate any given dep?
* Focus on behavior, not implementation.
1. **Import Maps**:
* @wesleytodd any interest in loaders/support for import maps
* ref. to originating issue: https://github.com/nodejs/modules/issues/477
* ref. to experimental loader project: https://github.com/node-loader/node-loader-import-maps
* would need an implementation to generate & then consume these import maps
* @darcyclarke can imagine we could help with generation, although it probably makes sense to try & ship import map consumption/support in node core
* @wesleytodd potentially, npm's support could help with standardization as that usually requires implementation
* @isaacs import maps may have a place in the story behind workspaces/linking dependencies
* @bnb good to note on how this works in regards to esm
* @bnb could help get away from `.js`