### npm v9.0.0

Hey folks,

Apologies for not jumping in before now but I have been following along behind the scenes & have talked through a variety of options with our team internally.

We have already [opened a PR](https://github.com/nodejs/node/pull/44756) with our most recent release candidates of npm 9 and have ensured that the Node.js test suite is green (& will continue to do so as we cut new RCs). We also ran CITGM multiple times. We've only identified a single change causing unexpected regressions and are in the process of fixing that for our next release candidate.

What we'd like to do here is take a phased approach in releasing npm 9 and integrating it into Node.js to ensure a high bar for quality & reduce the potential of unexpected breaking changes. Our intent is that upgrading from npm 8 -> npm 9 would be considered Semver-Minor for Node.js, and in general not significantly different than a regularly scheduled 8.x update.

With that in mind we are proposing the following criteria that npm 9 will meet to ensure it is not breaking for Node.js developers:

- Node.js CI remains green
- No new broken packages on CITGM
- `npm install` and `npm install -g` will not fail with npm 9 if it did not fail with npm 8
- Slight resolution changes may happen for correctness, this has historically happened in non semver-major npm versions previously
- If using `npm ci` there will be no new changes to a package-lock with npm 9, unless it would have changed with npm 8
- `npm install` will not update the lockfile version unless it was not previously defined
- This matches the behavior of npm 8 with the cavaet that it updates to v3 not v2
- v2 will remain backwards compatible, v3 is not. Customers can specify which version to use at install time or with a `.npmrc`

This should adhere to almost all of the requirements mentioned so far in the thread aside from the request regarding `.npmrc` credentials continuing to work across versions. We are making a change to supporting unscoped credentials at the system level for security reasons. More details can be found in [this issue](https://github.com/npm/statusboard/issues/485). These configuration settings can result sending crednetials to the wrong registry or a third party host. We strongly believe that this is the right thing to do for the ecosystem. If the project disagrees we can revisit this.

Below is a proposed timeline:

- **Wednesday Oct. 19th** (~3 weeks from today)
- Release `npm@9.0.0` & set dist-tags to `next` & `next-9`
- Continue cutting minors/patchs to address any feedback or unexpected issues arising from the outlined changes
- **Wednesday Nov. 9th** (~3 weeks from initial release)
- Exit criteria to ensure `npm@9.x` is considered "non-breaking" should be codified (collaboration between `npm` & the Release WG)
- Set dist-tags for `latest` for `npm@9.x`
- PR is open to land `npm@9.x` in `nodejs/node`'s `main` branch
- **Wednesday Dec. 7th** (~4 weeks after GA)
- PR is open to backport `npm@9.x` in `node@19`
- **Wednesday Jan. 18th** (~6 weeks after v19 backport)
- PR is open to backport `npm@9.x` in `node@18`

Notably, this path forward ensures ample time for `npm@9` to be consumed by the right audiences (ex. experimental/nightly consumers) before ever hitting LTS.

As it stands now these dates & ships decouple us from the LTS timeline under the assumption that v9 will be considered a Semver-Minor update.

Let me know if there's concerns with this strategy or the timing.