[BUG] npm install of npm@next failing during container build (No matching version found for npm@next)

[vguaglione]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

We have a number of overnight builds that run to build node functionality. Our container began failing late last week and it was determined that the "npm install -g npm@next" command was the issue.

Container build is performed via standard "docker build" command.

Build output indicates the following:

#6 8.588 Run npm audit for details.
#6 8.589 npm notice
#6 8.589 npm notice New major version of npm available! 7.24.0 -> 8.0.0
#6 8.589 npm notice Changelog: https://github.com/npm/cli/releases/tag/v8.0.0
#6 8.589 npm notice Run npm install -g npm@8.0.0 to update!
#6 8.589 npm notice
#6 9.176 npm ERR! code ETARGET
#6 9.181 npm ERR! notarget No matching version found for npm@next.
#6 9.181 npm ERR! notarget In most cases you or one of your dependencies are requesting
#6 9.181 npm ERR! notarget a package version that doesn't exist.

How do we fix this issue?

Expected Behavior

Container builds successfully.

Steps To Reproduce

1. In this environment...
2. With this config...
3. Run '...'
4. See error...

Environment

• OS: ubuntu 18.04 container image
• Node: v16.10.0
• npm: next?

[ljharb]

usually next is always kept up to date so that it's either ahead of, or matching, latest - it seems like perhaps the tag got deleted?

[vguaglione]

@ljharb That's what I was thinking also. We definitely need to know what happened to that tag.

[ljharb]

@vguaglione in the meantime, you could just swap it to latest and you'll get the expected npm version.

[vguaglione]

@ljharb Yes, I have done that already, however, have been told that some of our user base requires that tag for their specific implementations. I'd like to know when the tag will be made available again, and if not, a recommendation for a permanent fix.

[ljharb]

Hopefully the CLI team can weigh in; if they aren't willing to restore the tag, though, the permanent fix could only be "switch to latest".

[lukekarrys]

The next tag was removed along with the lts (#3859 (comment)) tag when 8.0.0 was published. These changes weren't communicated properly and we're sorry that this broke things for you @vguaglione! We'll do better in the future to outline these changes in advance.

The next and latest tags had been the same for awhile, so the recommendation for a permanent fix is to switch to latest for anything that was using next. latest now points to 8.0.0, which has a few breaking changes, so if those changes aren't compatible with your specific implementations I'd recommend using npm@7 instead.

The next tag will probably be reserved in the future for when we want to publish something that is substantially different than latest, but we don't currently have any plans to do that.

[ljharb]

npm/documentation#43 (comment):

Just curious; why did the practice of "publish as next, wait a week or two, promote it to latest" go away?

[vguaglione]

The next tag was removed along with the lts (#3859 (comment)) tag when 8.0.0 was published. These changes weren't communicated properly and we're sorry that this broke things for you @vguaglione! We'll do better in the future to outline these changes in advance.

The next and latest tags had been the same for awhile, so the recommendation for a permanent fix is to switch to latest for anything that was using next. latest now points to 8.0.0, which has a few breaking changes, so if those changes aren't compatible with your specific implementations I'd recommend using npm@7 instead.

The next tag will probably be reserved in the future for when we want to publish something that is substantially different than latest, but we don't currently have any plans to do that.

@lukekarrys We have gone ahead and replaced npm@next with npm@7 to ensure compatibility with our user's components. I appreciate the detailed explanation.

[lukekarrys]

We have gone ahead and replaced npm@next with npm@7 to ensure compatibility with our user's components.

@vguaglione That sounds like a good short term plan since that should be exactly what npm@next was resolving too last week. I would recommend moving to npm@8 (or latest) eventually since that is what will be receiving updates in the future.