Meeting from: February 10th, 2021

Open RFC Meeting (npm)

Attendees

Darcy Clarke (@darcyclarke)
Gar (@wraithgar)
Wes Todd (@wesleytodd)
Ruy Adorno (@ruyadorno)
Christian Siebmanns (@christian24)
Jordan Harband (@ljharb)
Isaac Z. Schlueter (@isaacs)
Bradley Farias (@bmeck)

Housekeeping
1. Introduction(s)
2. Code of Conduct Acknowledgement
3. Outline Intentions & Desired Outcomes
4. Announcements
PR: #317 Publish set the tag accordingly to the semver version number - @Divlo
PR: #314 RFC: `registry:` dependency specifiers - @isaacs
PR: #117 RFC: npm workspaces - Working with workspaces - @ruyadorno

Notes

PR: #317 Publish set the tag accordingly to the semver version number - @Divlo
- @wesleytodd: currently uses dist-tags this way - could potentially blow up based on what the semver semantics
- @isaacs: having the dist-tag name be in the version number is not a great idea
- @ljharb: thre are suboptimal dist-tag management workflows currently, such as backporting use case, forgetting to manually setting the correct dist-tags, etc
- @bmeck: uses dist-tags to reperesent different builds/environments - ref: https://github.com/godaddy/warehouse.ai
- @ljharb: making up dist-tags on the fly might be problematic to the current ecosystem
- @ljharb: 3 diff ideas/RFCs to improve this story:
  - publish prompts (already has an approved RFC)
  - tag selection for latest safe by default
  - config for automatic dist-tag selection
- @darcyclarke publishing multiple tags would also improve a lot the story, would ideally require registry changes to allow for setting multiple tags with a single request
- @wraithgar
  - no way to publish without a tag today (ex. --no-tag turns into --tag='false')
  - multiple tags would be nice (ie. --tag=latest -- tag=v3-latest)
- @wesleytodd --save-exact doesn't save the spec but will save the version from a dist-tag (ex. npm foo@next --save-exact resolves to foo:1.2.3)
  - potentially have a --save-spec(?)
PR: #314 RFC: `registry:` dependency specifiers - @isaacs
- @isaacs: potential leakage of registry config, although not more information then you'd leak today with package names
- @bmeck: recent
- @wesleytodd:
- @isaacs: goal of this is to try to mitigate npm v6 from installing packages with this spec
- @bmeck: ideally, want to exclude tarball urls - should look into how AWS migrated S3 urls https://aws.amazon.com/blogs/aws/amazon-s3-path-deprecation-plan-the-rest-of-the-story/
- @isaacs:
- @wesleytodd: need to be mindful of how this gets rolled out & the documentation around how to use this so that when someone can not install a package because an older version of npm cannot understand it (should be very clear as to why)
- @isaacs: action: followed up on feedback (updated RFC)
- @ruyadorno: spoke with Mael (of Yarn), & asked if there could be a follow-up session on this, will try & capture feedback in the PR thread itself
PR: #117 RFC: npm workspaces - Working with workspaces - @ruyadorno
- @ruyadorno: @isaacs noted we should consider a poitional argument (ie. top-level command) vs. a flag
- @isaacs: yes, top-level command makes a lot of scenarios easier
- @ruyadorno: action: will update RFC for next week
- @isaacs: let's talk about how we want to organize the semantics of workspace projects before doing too much on the implementation/UX here
- @ljharb: terse explanation: exactly the same as running npm install in the root, then running npm install in all the other workspaces, plus sharing peerdeps and workspace dependencies without hoisting to the root.
- @christian24: considering workspace packages vs. root-level dev tools, current hosting behaivour can be problematic based on how node module resolution works (ref. issue in webpack webpack-contrib/mini-css-extract-plugin#631)
- @ljharb: this seems to me like, in the world where we have the workspaces impl i describe, you could indicate "webpack" or "react" etc should be maximally shared, as if it was a peer dep or a workspace project, and that would solve it.