[BUG] There is no way to force "npm init" to get the latest version of the init package

[giltayar]

Current Behavior:

npm init <pkg> always runs whatever version of the <pkg> is installed and doesn't check whether
there's a later version. Moreover, there is no way to tell it to do that.

Expected Behavior:

npm init <pkg> should first check if there's an updated version of <pkg> and install that before running it.
Alternatively, there should be an option (--update?) that updates to the latest version before running it.

Steps To Reproduce:

1. Publish @scope/create (v1.0.0)
2. Run npm init @scope. It runs v1.0.0 as expected (which is OK).
3. Publish a new @scope/create (v1.1.0)
4. Run npm init @scope. It still runs v1.0.0 and there is no way to make it run v1.1.0.
5. The workaround I have is to npm exec @scope/create@latest, which does the right thing.
6. Even doing npm install -g @scope/create@latest doesn't help

Environment:

I'm guessing all versions, but specifically what I'm running on is:

OS: MacOS Big Sur
Node.js: 15.3.0.
NPM: 7.0.14

[wraithgar]

After a day of investigation this turns out to be a bug in (make-fetch-happen)[https://github.com/npm/make-fetch-happen] where it is not obeying what starts as --prefer-online in the cli (and becomes no-cache in make-fetch-happen). This affects at least npm init, npm exec, and npm install.

[wraithgar]

It turns out what I thought was a fetch bug is a logging quirk. If the registry itself sends a 304, the response the cli gets still looks like a cache hit, and logs in the output as (from cache)

The good news for you is that if you use --prefer-online in your npm init it should fetch the latest packument from the registry, regardless of if you already have it locally in your cache.

[giltayar]

@wraithgar I tried npm init --prefer-online ... and it's still bringing me the existing package and not checking whether that package was updated.

(BTW, using npm exec @scope/create@latest (even without --prefer-online) did figure out that there was a new version, and I'm using that now, but it's still a workaround.)

[wraithgar]

Glad you have a workaround. Re-opened the issue so we can take a closer look.

[mansona]

I think we should make sure that npm init package-name always makes use of the latest version by default (without the need for --prefer-online as a workaround). I'm pretty sure that this was the default behaviour in npm@6 and I know of plenty of documentation written to depend on this behaviour to set up repos 🤔

[wraithgar]

v7 should once again match v6 behavior in the next release (v7.5.2). Changing it further should probably involve an RFC discussion.

[daKmoR]

I'm on npm v8.5.1 and this seems to be back?

e.g. npm init @scope is not using the latest version
with that, the main benefit of npm init it's simplicity is gone 😭

now I finally get why many docs pages are using npx @scope/create@latest instead of npm init @scope

[beenotung]

I can confirm this bug in npm@8.19.1

[zetaraku]

The bug is still there.

Although the document says:

The init command is transformed to a corresponding npm exec operation as follows:

npm init foo -> npm exec create-foo

When I run npm exec create-slidev, the version shown is v0.49.16.
However, when I run npm init slidev, the version shown is still v0.42.4.

Both results should be the same.

[beenotung]

My workaround is to delete the npx cache inside .npm

[mansona]

so I have tended to always include an @latest in the package name when using npm init:

npm init release-plan-setup@latest for example, this way there is no stress about any caches 🤷