---
# System prepended metadata

title: Open RFC Meeting (npm)

---

#### 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`
