[BUG] Pinned dependencies does not get packed up from workspace

[mxschmitt]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

➜  npm-bump-version-etarget git:(master) ✗ npm i
npm ERR! code ETARGET
npm ERR! notarget No matching version found for playwright-core@=1.20.1.
npm ERR! notarget In most cases you or one of your dependencies are requesting
npm ERR! notarget a package version that doesn't exist.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/max/.npm/_logs/2021-10-25T14_07_42_079Z-debug.log

Expected Behavior

It prioritises the package from the workspaces over the NPM registry

Steps To Reproduce

See here for a small repro https://github.com/mxschmitt/npm-bump-version-etarget and instructions.

Relates #3403 but this one is only about updating, mine is about installing.

Environment

• OS: MacOS 11.6
• Node: 14
• npm: 8.1.1

[fritzy]

@darcyclarke @isaacs Should we treat workspaces like a local registry? I'm leaning toward yes. This way, publishing a root package with spec'd dependencies that are a workspace will work for local dev and after being published when workspaces aren't vendored.

[CITguy]

Environment

• OS: MacOS 10.15
• Node: 14
• npm
  • npm 7.1.0 breaks (as mentioned above)
  • npm 7.2.0 through 7.20 all seem to work fine
  • npm 7.21.0+ also breaks

Additionally, I'm using lerna 4 (with hoisting) to update versions of packages/*/package.json in a monorepo for release purposes. After updating package versions using lerna, the root package-lock.json seems to no longer work, especially if no node_modules is present (likely in a CI environment).

Workarounds

Deleting and rebuilding the package-lock.json is the only way I've found to get around this issue

[mysterycommand]

I actually just ran into this myself and it appears to be a regression between npm@7.20.2 (running npm i updates package-lock.json with bumped workspace package versions) and npm@7.20.3 (doesn't install, ETARGET error as above) in case that helps debug or get someone around the issue. Oh oops, never mind me, it's as @CITguy described above.

[opeologist]

didn't experience this issue on latest npm version (currently 8.5.1), so this might've been silently resolved and it's safe to close this issue?