[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 [email protected] (running npm i updates package-lock.json with bumped workspace package versions) and [email protected] (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?

[robrez]

If this isn't the same underlying problem, please let me know and I will open a new issue.

When running npm version <v> -ws , only the "version" field in my packages is updated. A given package's dependency on another workspaces-aware-local package is not updated.

$ npm -v
9.5.1

$ npm init --yes
$ npm init -w ./packages/a --yes
$ npm init -w ./packages/b --yes
$ npm i --save b -w ./packages/a/
$ npm --workspaces --no-git-tag-version version major

$ cat packages/*/package.json

{
  "name": "a",
  "version": "2.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "dependencies": {
    "b": "^1.0.0"
  }
}
{
  "name": "b",
  "version": "2.0.0",
  "description": "",
  "main": "index.js",
  "devDependencies": {},
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC"
}

And, yes, package-lock is also not updated

cat package-lock.json

{
  "name": "xworkspaces",
  "version": "1.0.0",
  "lockfileVersion": 3,
  "requires": true,
  "packages": {
    "": {
      "name": "xworkspaces",
      "version": "1.0.0",
      "license": "ISC",
      "workspaces": [
        "packages/a",
        "packages/b"
      ]
    },
    "node_modules/a": {
      "resolved": "packages/a",
      "link": true
    },
    "node_modules/b": {
      "resolved": "packages/b",
      "link": true
    },
    "packages/a": {
      "version": "2.0.0",
      "license": "ISC",
      "dependencies": {
        "b": "^1.0.0"
      }
    },
    "packages/b": {
      "version": "2.0.0",
      "license": "ISC",
      "devDependencies": {}
    }
  }
}

I also tried, unsuccessfully, to get this working on the latest 8.x.x release, 18.19.4 at the time of writing. There I hit some other issues which have been reported elsewhere which related to my packages being private or unpublished.

If anyone has a clever workaround, please lmk. I'm trying to move away from lerna and this problem is the only real blocker.