#### Wednesday March 25th 2020

# Open RFC Deep Dive

### Attendees
- Darcy Clarke (@darcyclarke)
- Dominykas Blyžė (@dominykas)
- Ruy Adorno (@ruyadorno)
- Claudia Hernández (@claudiahdz)
- Wes Todd (@wesleytodd)
- Jordan Harband (@LJHarb)
- Michael Dawson (@mhdawson1)
- Isaac Z. Schlueter (@isaacs)
- Emelia Smith (@thisismissem)

### Agenda
1. **Housekeeping**
1. Introduction(s)
1. Code of Conduct Acknowledgement
1. Outline Intentions & Desired Outcomes
1. Announcements
1. **PR**: [#92 RFC: Add staging workflow for CI and human interoperability](https://github.com/npm/rfcs/pull/92)
1. Scope (initial support)
1. Usecases
1. Implementation details

### Notes
- There are a handful of different use cases, hence the need for a deep dive
- Need for publishing from CI and having an extra step where a person can promote the publish to production
- authentication/authorization should live server-side
- How to push out to beta? pre-release semver tags vs staged publishes
- Sharing inside my team vs outside my team
- Currently implemented in `npm-pick-manifest`: deprioritize staged versions
- There's a difference between using pre-release tags that are accesible to the public and a private staging environment that allows for testing and sharing with a limited amount of people
- Draft private publish (ex. wordpress/tumblr/medium draft) only installable by the publishers, only installable by people who the publish was shared with
- ability to install staged versions of specific deps that will make that dep and all it's deps pull the staged versions, instead of a single `staged` flag that applies to the whole tree
ex `npm i -staged=tap@next, nyc@next`
ex `npm install tap@15 --include-staged=tap`
- should explicitly opt-in (should make it difficult to get by accident)
- deleting things:
+ should staged versions be deleted automatically if they never get publish/promoted? in what time window?
+ when should staged versions be deleted?
+ can you have 2 same-numbered staged versions at the same time?
- Should staged versions be added to the package.lock?
+ lockfile could include two URLs - the staged one and the non staged alternative
- What if people depend on a package that is never promoted?
- npm should provide a way of warning the user about the usage of staged versions in their install