Use a staged package: npm install foo@2 --include-staged (as long as 2.x versions are all in staging, like if it's a beta or somethign, and 1.x is the published versions).
When foo@2 is promoted, then npm install foo@2 --include-staged will pick up the promoted version.
If the staged foo@2 depends on a staged bar@3, then ok, that'll Just Work, because you're in "include staged" mode.
When the pkg is promoted and the resolved changes, the package lock doesn't break. (It might get slightly less canonical or cacheable, but then again, it might not. Maybe we want to have content-addresses in our tarball urls!)
If the staged version is overwritten with a new staged version, then the build will break (unless Pacote is taught to just handle this, which may be worthwhile, and would be possible.)
I don't see any DX issues that justify restricting the utility of staged packages, but maybe I'm missing something.
npm install foo@2 --include-staged(as long as2.xversions are all in staging, like if it's a beta or somethign, and 1.x is the published versions).foo@2is promoted, thennpm install foo@2 --include-stagedwill pick up the promoted version.foo@2depends on a stagedbar@3, then ok, that'll Just Work, because you're in "include staged" mode.I don't see any DX issues that justify restricting the utility of staged packages, but maybe I'm missing something.
Originally posted by @isaacs in https://github.com/npm/rfcs/issues/92#issuecomment-587129658