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

1. **Housekeeping**
1. Introduction(s)
1. [Code of Conduct Acknowledgement](https://www.npmjs.com/policies/conduct)
1. Outline Intentions & Desired Outcomes
1. Announcements
1. **PR**: [#317 Publish set the tag accordingly to the semver version number](https://github.com/npm/rfcs/pull/317) - @Divlo
1. **PR**: [#314 RFC: `registry:` dependency specifiers](https://github.com/npm/rfcs/pull/314) - @isaacs
1. **PR**: [#117 RFC: npm workspaces - Working with workspaces](https://github.com/npm/rfcs/pull/117) - @ruyadorno

### Notes

1. **PR**: [#317 Publish set the tag accordingly to the semver version number](https://github.com/npm/rfcs/pull/317) - @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](https://github.com/npm/rfcs/blob/592826ca1fb46f5dea0c0e77e9afc58e031778cb/accepted/0028-publish-prompt.md))
* 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`(?)

1. **PR**: [#314 RFC: `registry:` dependency specifiers](https://github.com/npm/rfcs/pull/314) - @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

1. **PR**: [#117 RFC: npm workspaces - Working with workspaces](https://github.com/npm/rfcs/pull/117) - @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` https://github.com/webpack-contrib/mini-css-extract-plugin/issues/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.