Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
giltayar opened this issue Dec 21, 2020 · 11 comments
Assignees
Labels
Bug thing that needs fixing Priority 1 high priority issue Release 7.x work is associated with a specific npm 7 release

Comments

@giltayar
Copy link

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

@giltayar giltayar added Bug thing that needs fixing Needs Triage needs review for next steps Release 7.x work is associated with a specific npm 7 release labels Dec 21, 2020
@wraithgar wraithgar added Priority 2 secondary priority issue and removed Needs Triage needs review for next steps labels Jan 21, 2021
@wraithgar wraithgar self-assigned this Jan 21, 2021
@wraithgar wraithgar added Priority 1 high priority issue and removed Priority 2 secondary priority issue labels Jan 23, 2021
@wraithgar
Copy link
Member

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.

@darcyclarke darcyclarke added this to the OSS - Sprint 23 milestone Jan 25, 2021
@wraithgar
Copy link
Member

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
Copy link
Author

@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 wraithgar reopened this Jan 27, 2021
@wraithgar
Copy link
Member

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

@mansona
Copy link
Contributor

mansona commented Feb 1, 2021

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
Copy link
Member

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

@daKmoR
Copy link

daKmoR commented Feb 21, 2022

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
Copy link

I can confirm this bug in npm@8.19.1

beenotung added a commit to beenotung/create-ts-liveview that referenced this issue Sep 19, 2022
This is related caching behavior of "npm init", more discussion see npm/cli#2395
@zetaraku
Copy link

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
Copy link

My workaround is to delete the npx cache inside .npm

@mansona
Copy link
Contributor

mansona commented Jul 15, 2024

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 🤷

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug thing that needs fixing Priority 1 high priority issue Release 7.x work is associated with a specific npm 7 release
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants