---
# System prepended metadata

title: Open RFC Meeting (npm)

---

#### 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: &#x60;registry:&#x60; 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: &#x60;registry:&#x60; 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.