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] node_modules/.bin directory and symlinks no longer being created after upgrading from v6 to v8 #4308

Closed
2 tasks done
busticated opened this issue Jan 21, 2022 · 7 comments
Labels
Bug thing that needs fixing Priority 1 high priority issue Release 8.x work is associated with a specific npm 8 release

Comments

@busticated
Copy link

Is there an existing issue for this?

  • I have searched the existing issues

This issue exists in the latest npm version

  • I am using the latest npm

Current Behavior

After upgrading my project from v6.14.16 to v8.3.2, the node_modules/.bin directory and associated symlinks are no longer created when running npm i

Expected Behavior

node_modules/.bin directory and associated symlinks are created after running npm i, bare executable names are recognized when used within scripts - e.g. using a script like:

  "scripts": {
    "postinstall": "lerna bootstrap"
  },

...running npm run postinstall directly (or implicitly after npm i) works, the lerna name resolves to node_modules/.bin/lerna which inturn poinst to ../lerna/cli.js

Steps To Reproduce

  1. using [email protected] and [email protected] on macOS v12.0.1 (intel)
node --eval 'console.log(process.versions)'
{
  node: '16.13.2',
  v8: '9.4.146.24-node.14',
  uv: '1.43.0',
  zlib: '1.2.11',
  brotli: '1.0.9',
  ares: '1.18.1',
  modules: '93',
  nghttp2: '1.46.0',
  napi: '8',
  llhttp: '6.0.4',
  openssl: '1.1.1m',
  cldr: '39.0',
  icu: '69.1',
  tz: '2021a',
  unicode: '13.0'
}
  1. run npm i npm@8 --global
  2. run rm -rf node_modules
  3. run npm i
  4. run ls -la node_modules/.bin
  5. observe the error: No such file or directory

Environment

  • npm: v8.3.2
  • Node.js: v16.13.2
  • OS Name: macOS
  • System Model Name: Monterey (v12.0.1 intel)
  • npm config:
; "builtin" config from /usr/local/lib/node_modules/npm/npmrc

prefix = "/usr/local" 

; "user" config from /Users/me/.npmrc

//registry.npmjs.org/:_authToken = (protected) 

; node bin location = /usr/local/Cellar/node@16/16.13.2/bin/node
; cwd = /Users/me/code/particle/js-utils
; HOME = /Users/me
; Run `npm config ls -l` to show all defaults.
@busticated busticated added Bug thing that needs fixing Needs Triage needs review for next steps Release 8.x work is associated with a specific npm 8 release labels Jan 21, 2022
@busticated
Copy link
Author

ah, whoops - meant to also note that upgrading from v6.14.16 to v7.24.2, and then to v8.3.2 fixes the issue. when i diff the npm-shrinkwrap.json file, i see a number of changes like:

<       "dev": true
---
>       "dev": true,
>       "bin": {
>         "parser": "bin/babel-parser.js"
>       },
>       "engines": {
>         "node": ">=6.0.0"
>       }

...which seems to indicate that npm@7 is properly handling the migration but npm@8 is not

@ruyadorno
Copy link
Contributor

hi @busticated thanks for the thorough report! unfortunately I can't reproduce it, I set up a minimal example such as:

$ cat package.json
{
  "name": "test-lockfile",
  "version": "1.0.0",
  "dependencies": {
    "ruy": "^1.0.0"
  }
}

$ cat package-lock.json
{
  "name": "test-lockfile",
  "version": "1.0.0",
  "lockfileVersion": 1,
  "requires": true,
  "dependencies": {
    "ruy": {
      "version": "1.0.0",
      "resolved": "https://registry.npmjs.org/ruy/-/ruy-1.0.0.tgz",
      "integrity": "sha512-VYppDTCM6INWUMKlWiKws4nVMuCNU5h+xjF6lj/0y90rLq017/m8aEpNy4zQSZFV2qz66U/hRZwwlSLJ5l5JMQ=="
    }
  }
}

When I try to npm install (tried with multiple v7 - v8 versions) that also includes the current development branch:

$ npm install
npm WARN old lockfile
npm WARN old lockfile The package-lock.json file was created with an old version of npm,
npm WARN old lockfile so supplemental metadata must be fetched from the registry.
npm WARN old lockfile
npm WARN old lockfile This is a one-time fix-up, please be patient...
npm WARN old lockfile

added 1 package, and audited 2 packages in 558ms

found 0 vulnerabilities

$ cat package-lock.json
{
  "name": "test-lockfile",
  "version": "1.0.0",
  "lockfileVersion": 2,
  "requires": true,
  "packages": {
    "": {
      "name": "test-lockfile",
      "version": "1.0.0",
      "dependencies": {
        "ruy": "^1.0.0"
      }
    },
    "node_modules/ruy": {
      "version": "1.0.0",
      "resolved": "https://registry.npmjs.org/ruy/-/ruy-1.0.0.tgz",
      "integrity": "sha512-VYppDTCM6INWUMKlWiKws4nVMuCNU5h+xjF6lj/0y90rLq017/m8aEpNy4zQSZFV2qz66U/hRZwwlSLJ5l5JMQ==",
      "bin": {
        "ruy": "bin/index.js"
      }
    }
  },
  "dependencies": {
    "ruy": {
      "version": "1.0.0",
      "resolved": "https://registry.npmjs.org/ruy/-/ruy-1.0.0.tgz",
      "integrity": "sha512-VYppDTCM6INWUMKlWiKws4nVMuCNU5h+xjF6lj/0y90rLq017/m8aEpNy4zQSZFV2qz66U/hRZwwlSLJ5l5JMQ=="
    }
  }
}

I can see that the "bin" entry was properly generated in the lockfile and I can also confirm the file is there as expected:

$ ls node_modules/.bin/ruy
node_modules/.bin/ruy

So maybe there's something else particular to your environment and/or that project that is causing this? It would be super helpful if you could try to reproduce your problem using a minimal example (such as this one here) so that we could possibly have something to work with and possibly git bisect to find when the problem started.

@ruyadorno ruyadorno removed the Needs Triage needs review for next steps label Jan 24, 2022
@busticated
Copy link
Author

busticated commented Jan 25, 2022

thanks for taking a look 🙏

maybe there's something else particular to your environment and/or that project that is causing this?

it's always a possibility but given that i'm able to "fix" things by going from v6.14.16 to v7.24.2, and then to v8.3.2 (as opposed to going from v6.14.16 directly to v8.3.2) and that this is not without precedent (#2147, #3791, #4035) seems to cast some doubt on it being exclusively due to something unique in my environment.

that said, anything i should look for specifically? i'm working out of a lerna-driven monorepo (docs) but this issue happened in the root package which doesn't behave differently than a single-package repo (lerna bootstrap is run via the postinstall hook) as far as i can tell. npm is installed with node@16 via brew. pretty standard setup i think 🤷‍♂️

if you could try to reproduce your problem using a minimal example

i'll see what i can do but i'm unfortunately a bit overbooked here. one thing right off the top - i'm using npm-shrinkwrap.json not package-lock.json maybe that's playing a role?

@ruyadorno
Copy link
Contributor

it'd be super helpful if you can track some of the names of deps (possibly providing the full package-lock.json file if that's something you can do) that end up without the bin files (is it all of them?), from reading this comment it seems to me the problem might be related to a registry not returning a valid bin entry - I'd be interested to inspect the packument values returned by the registry for your packages that are missing .bin files

@TalMat
Copy link

TalMat commented Jan 30, 2022

Can confirm over here. Upgraded directly from node 14/npm 6 to node 16/npm 8. Running npm i -g no longer symlinks the packages in the global npm/node_modules directory and did not create the command, command.cmd, and command.ps1 files in the /npm. (note: this is for a custom script added to the package.json bin + preferGlobal: true, with a shebang in the .js file)

Uninstalled node. Reinstalled at v14. Upgrade npm to v7 and tested: still works. Upgraded to v8: now works properly. Upgraded node to v16 (npm already at 8.4.0) and it still works. Something about going through v7 sidestepped the problem.

lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 13, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 13, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 18, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 21, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 21, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 22, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 22, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 22, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 22, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 22, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 22, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 22, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 22, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 27, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 27, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 27, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 27, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
lilyinstarlight added a commit to lilyinstarlight/node2nix that referenced this issue Sep 27, 2022
Lockfile v2 mostly just has a bit of extra metadata and all dependencies
are hoisted to the top-level with path-specific keys in a new lock value
called "packages". This update emits enough of the format that NPM v7+
seem to be happy enough with it and does not try to rewrite it and cause
ENOTCACHED errors with the sandbox.

As of NPM v7+, it no longer links bins for the top-level project
automatically unless a global install is selected[1][2]. Given a global
install would cause more problems than it would solve, I added a simple
script to perform the linking ourselves and instructed `npm install` to
never link them for consistency.

Closes svanderburg#236, svanderburg#293, svanderburg#294

[1]: npm/cli@e46400c#diff-24c01909dabbe2fc000fb5b43d14b511fb335b2f0c2e8e7a671f7d567a33d577R17-R18
[2]: npm/cli#4308
@LeandroDG
Copy link

Has there been any update to this issue since last year? We've started experimenting this issue specifically in MacOS after doing the v6 to v8 upgrade. So far no luck on getting those .bin folders created running npm install.

Thanks a lot :-)

@wraithgar
Copy link
Member

Closing this one due to its age and the lack of a way to reproduce it. If someone comes up with a way for this to be reproduced we can look into fixing it.

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 8.x work is associated with a specific npm 8 release
Projects
None yet
Development

No branches or pull requests

5 participants