2021-01-27.md

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)
   2. Code of Conduct Acknowledgement
   3. Announcements
2. File Path Resolution Review:
   1. Summary:
      • file: behaivour changed in v7 - no longer support installing dependencies of packages that are not nested
   2. Questions:
      • Do we agree with how it's working today?
      • How would we change it?
   3. Related Items:
      • Issue: #2145 [BUG] npm7 does not create transitive node_module folders for dependencies referenced via file:/
3. 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.
   2. Questions:
      • Do we agree with how it's working today?
      • How would we change it?
   3. Related Items:
      • Issue: #2339 npm v7 does not install linked packages dependencies
      • Issue: #301 [RRFC] Workspaces: support to version specifiers other than semver ranges
      • PR: #117 RFC: npm workspaces - Working with workspaces

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
2. 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 [email protected]. packages/b is v1.2.3. require('b') from within packages/a should refer to packages/b
       • packages/a depends on [email protected]. 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 [email protected]. packages/b depends on [email protected]. 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.
3. 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