[BUG] `npm` commands can fail with `ERR_INVALID_ARG_TYPE` when normalizing manifests including a `directories.bin` field

[tubacoopa]

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

When installing a package whose registry-provided manifest includes a directories.bin field, but not a bin field, installation fails with the error:

npm error code ERR_INVALID_ARG_TYPE
npm error The "paths[0]" argument must be of type string. Received undefined

This appears to stem from @npmcli/package-json@7.0.0 adding the 'bindir' step to normalization, creating a potential branch where the package path is expected to be defined. When fetching the manifest however, pacote instantiates a PackageJson in such a way that the path is not defined, which can result in the noted error when normalization occurs immediately afterward.

Because the npm public registry appears to calculate the effective bin field for packages only specifying directories.bin, this issue may be specific to users installing from self-hosted/alternative/mirror registries.

Expected Behavior

Installation should succeed for manifests including a directories.bin entry, but not a bin entry.

Steps To Reproduce

1. Run npm install <package> for a package whose registry-provided manifest includes a directories.bin field, but not a bin field
   *(may require installing from a self-hosted/alternative/mirror registry)
2. See error like:

0 verbose cli C:\Program Files\nodejs\node.exe C:\Users\tubacoopa\AppData\Roaming\npm\node_modules\npm\bin\npm-cli.js
1 info using npm@11.6.2
2 info using node@v24.11.0
3 silly config load:file:C:\Users\tubacoopa\AppData\Roaming\npm\node_modules\npm\npmrc
4 silly config load:file:C:\Users\tubacoopa\test\.npmrc
5 silly config load:file:C:\Users\tubacoopa\.npmrc
6 silly config load:file:C:\Users\tubacoopa\AppData\Roaming\npm\etc\npmrc
7 verbose title npm install sshpk
8 verbose argv "install" "sshpk"
9 verbose logfile logs-max:10 dir:C:\Users\tubacoopa\AppData\Local\npm-cache\_logs\2025-11-04T17_16_19_939Z-
10 verbose logfile C:\Users\tubacoopa\AppData\Local\npm-cache\_logs\2025-11-04T17_16_19_939Z-debug-0.log
11 silly logfile start cleaning logs, removing 1 files
12 silly packumentCache heap:4496293888 maxSize:1124073472 maxEntrySize:562036736
13 silly logfile done cleaning log files
14 silly idealTree buildDeps
15 silly fetch manifest sshpk@*
16 silly packumentCache full:(protected)/sshpk cache-miss
17 http fetch GET 200 (protected)/sshpk 1219ms (cache revalidated)
18 silly packumentCache full:(protected)/sshpk set size:6507 disposed:false
19 silly placeDep ROOT sshpk@ OK for:  want: *
20 verbose stack TypeError [ERR_INVALID_ARG_TYPE]: The "paths[0]" argument must be of type string. Received undefined
20 verbose stack     at Object.resolve (node:path:199:9)
20 verbose stack     at asyncSteps (C:\Users\tubacoopa\AppData\Roaming\npm\node_modules\npm\node_modules\@npmcli\package-json\lib\normalize.js:479:57)
20 verbose stack     at normalize (C:\Users\tubacoopa\AppData\Roaming\npm\node_modules\npm\node_modules\@npmcli\package-json\lib\normalize.js:605:9)
20 verbose stack     at PackageJson.normalize (C:\Users\tubacoopa\AppData\Roaming\npm\node_modules\npm\node_modules\@npmcli\package-json\lib\index.js:276:11)
20 verbose stack     at RegistryFetcher.manifest (C:\Users\tubacoopa\AppData\Roaming\npm\node_modules\npm\node_modules\pacote\lib\registry.js:134:9)
20 verbose stack     at async #fetchManifest (C:\Users\tubacoopa\AppData\Roaming\npm\node_modules\npm\node_modules\@npmcli\arborist\lib\arborist\build-ideal-tree.js:1227:20)
20 verbose stack     at async #nodeFromEdge (C:\Users\tubacoopa\AppData\Roaming\npm\node_modules\npm\node_modules\@npmcli\arborist\lib\arborist\build-ideal-tree.js:1065:19)
20 verbose stack     at async #buildDepStep (C:\Users\tubacoopa\AppData\Roaming\npm\node_modules\npm\node_modules\@npmcli\arborist\lib\arborist\build-ideal-tree.js:929:11)
20 verbose stack     at async Arborist.buildIdealTree (C:\Users\tubacoopa\AppData\Roaming\npm\node_modules\npm\node_modules\@npmcli\arborist\lib\arborist\build-ideal-tree.js:182:7)
20 verbose stack     at async Promise.all (index 1)
21 error code ERR_INVALID_ARG_TYPE
22 error The "paths[0]" argument must be of type string. Received undefined
23 silly unfinished npm timer reify 1762276580954
24 silly unfinished npm timer reify:loadTrees 1762276580956
25 verbose cwd C:\Users\tubacoopa\test
26 verbose os Windows_NT 10.0.26100
27 verbose node v24.11.0
28 verbose npm  v11.6.2
29 verbose exit 1
30 verbose code 1
31 error A complete log of this run can be found in: C:\Users\tubacoopa\AppData\Local\npm-cache\_logs\2025-11-04T17_16_19_939Z-debug-0.log

Environment

• npm: 11.6.2
• Node.js: 24.11.0
• OS Name: Windows 11
• System Model Name: Dell OptiPlex 7090
• npm config:

; "builtin" config from C:\Users\tubacoopa\AppData\Roaming\npm\node_modules\npm\npmrc

prefix = "C:\\Users\\tubacoopa\\AppData\\Roaming\\npm"

; "user" config from C:\Users\tubacoopa\.npmrc

registry = "(protected)"

; node bin location = C:\Program Files\nodejs\node.exe
; node version = v24.11.0
; npm local prefix = C:\Users\tubacoopa\test
; npm version = 11.6.2
; cwd = C:\Users\tubacoopa\test
; HOME = C:\Users\tubacoopa
; Run `npm config ls -l` to show all defaults.

[philippdvorak]

Same issue for me, reverting to an older npm version (in my case 11.5.0) resolved this issue

[lorenzogrv]

I'm researching if this affects us. Some notes:

At first we were struggling with ERESOLVE and thought something was messed-up with peerDependencies, until we noticed npm was resolving to @undefined 🤔 . Neither the main error or the debug log were useful to diagnose the problem

npm error code ERESOLVE
npm error ERESOLVE unable to resolve dependency tree
npm error
npm error While resolving: @scope/package-one@2.0.0
npm error Found: @scope/package-two@undefined  

As usual with this kind of hard-diagnosing problems, we ended-up researching for a possible cache problem.

$ npm cache add @scope/package-two
npm error code ERR_INVALID_ARG_TYPE
npm error The "paths[0]" argument must be of type string. Received undefined
npm error A complete log of this run can be found in: __REDACTED__/.npm/_logs/2025-11-05T10_09_22_797Z-debug-0.log

Verbose stack at debug log suggests something happens during packageJSON normalization:

0 verbose cli __REDACTED__/.nvm/versions/node/v22.13.1/bin/node __REDACTED__/.nvm/versions/node/v22.13.1/bin/npm
1 info using npm@11.6.2
2 info using node@v22.13.1
3 silly config load:file:__REDACTED__/.nvm/versions/node/v22.13.1/lib/node_modules/npm/npmrc
4 silly config load:file:__REDACTED__/repos/hapuna-alt/.npmrc
5 silly config load:file:__REDACTED__/.npmrc
6 silly config load:file:__REDACTED__/.nvm/versions/node/v22.13.1/etc/npmrc
7 verbose title npm cache add @scope/package-two
8 verbose argv "cache" "add" "@scope/package-two"
9 verbose logfile logs-max:10 dir:__REDACTED__/.npm/_logs/2025-11-05T10_09_22_797Z-
10 verbose logfile __REDACTED__/.npm/_logs/2025-11-05T10_09_22_797Z-debug-0.log
11 silly logfile start cleaning logs, removing 1 files
12 silly cache add args [ '@scope/package-two' ]
13 silly cache add spec @scope/package-two
14 silly logfile done cleaning log files
15 http fetch GET 200 https://gitlab.com/api/v4/packages/npm/@scope%2fpackage-two 558ms (cache miss)
16 verbose stack TypeError [ERR_INVALID_ARG_TYPE]: The "paths[0]" argument must be of type string. Received undefined
16 verbose stack     at Object.resolve (node:path:1186:7)
16 verbose stack     at asyncSteps (__REDACTED__/.nvm/versions/node/v22.13.1/lib/node_modules/npm/node_modules/@npmcli/package-json/lib/normalize.js:479:57)
16 verbose stack     at normalize (__REDACTED__/.nvm/versions/node/v22.13.1/lib/node_modules/npm/node_modules/@npmcli/package-json/lib/normalize.js:605:9)
16 verbose stack     at PackageJson.normalize (__REDACTED__/.nvm/versions/node/v22.13.1/lib/node_modules/npm/node_modules/@npmcli/package-json/lib/index.js:276:11)
16 verbose stack     at RegistryFetcher.manifest (__REDACTED__/.nvm/versions/node/v22.13.1/lib/node_modules/npm/node_modules/pacote/lib/registry.js:134:9)
16 verbose stack     at async RegistryFetcher.resolve (__REDACTED__/.nvm/versions/node/v22.13.1/lib/node_modules/npm/node_modules/pacote/lib/registry.js:55:5)
16 verbose stack     at async __REDACTED__/.nvm/versions/node/v22.13.1/lib/node_modules/npm/lib/commands/cache.js:181:7
16 verbose stack     at async Promise.all (index 0)
16 verbose stack     at async Cache.add (__REDACTED__/.nvm/versions/node/v22.13.1/lib/node_modules/npm/lib/commands/cache.js:176:5)
16 verbose stack     at async Cache.exec (__REDACTED__/.nvm/versions/node/v22.13.1/lib/node_modules/npm/lib/commands/cache.js:102:16)
17 error code ERR_INVALID_ARG_TYPE
18 error The "paths[0]" argument must be of type string. Received undefined
19 verbose cwd __REDACTED__
20 verbose os Linux 5.15.0-139-generic
21 verbose node v22.13.1
22 verbose npm  v11.6.2
23 verbose exit 1
24 verbose code 1

We have also noticed npm publish after 11.6.2 upgrade sets bin: {} under the described situation: directories.bin exists but bin doesn't
Relevant section of package metadata fetching:

{
  "name": "@scope/package-two",
  "versions": {
     // ...
     "1.5.0": {
      "bin": {}, // there is no "bin" defined for package.json, but it's here
      "directories": {
        "bin": "bin"
      },
      "dist": {
        // not relevant
      },
      "name": "@scope/package-two",
      "version": "1.5.0",
      "devDependencies": {
        // not relevant
      },
      "peerDependencies": {
        // not relevant
      }
    }
  },
  "dist-tags": {
    "latest": "1.5.0"
  }

Note @scope/package* are not real packages

[lorenzogrv]

@tubacoopa I would suggest removing "npm install can fail with" from this Issue's title

[lorenzogrv]

After corrections on senseless "directories" / "bin" metadata at the offending package, and after publishing the fixed version npm installs and works as expected. This specific package does not have executables, so there's no point on including that directories.bin data at all.

IMHO this is more about a misleading error message than a bug itself, and either:

• The error message should explain better the problem root cause,
• npm publish should not introduce { bin: {} },
• PackageJson.normalize should be enhanced

[tubacoopa]

Same issue for me, reverting to an older npm version (in my case 11.5.0) resolved this issue

Reverting does appear to be the only viable workaround at the moment. 11.6.0 and earlier do not have this issue

[tubacoopa]

• npm publish should not introduce { bin: {} },

This alone wouldn't fix the error described here, although it may be worth a separate issue.

sshpk provides a good example of the specific case required to hit this error. In its package.json, no bin field is defined, only a directories.bin. Some registries (including the isolated mirror that I use), will provide a response that directly reflects this information, triggering the noted error:

"1.18.0" : {
      "name" : "sshpk",
      "description" : "A library for finding and using SSH public keys",
      "version" : "1.18.0",

...

      "directories" : {
        "bin" : "./bin",
        "lib" : "./lib",
        "man" : "./man/man1"
      },

...

    }

Using the public registry however, a bin appears to be resolved and reported in the manifest, which coincidentally happens to prevent the noted error from occurring:

"1.18.0": {
      "name": "sshpk",
      "description": "A library for finding and using SSH public keys",
      "version": "1.18.0",

...

      "bin": {
        "sshpk-conv": "bin/sshpk-conv",
        "sshpk-sign": "bin/sshpk-sign",
        "sshpk-verify": "bin/sshpk-verify"
      },
      "directories": {
        "bin": "./bin",
        "lib": "./lib",
        "man": "./man/man1"
      },

...

    }

[lorenzogrv]

• npm publish should not introduce { bin: {} },

This alone wouldn't fix the error described here, although it may be worth a separate issue.

sshpk provides a good example of the specific case required to hit this error. In its package.json, no bin field is defined, only a directories.bin. Some registries (including the isolated mirror that I use), will provide a response that directly reflects this information, triggering the noted error:

Which "bin" of the specific version returns your isolated mirror medatada endpoint?
I.E. At public registry https://registry.npmjs.org/sshpk it includes:

[tubacoopa]

One of the registries I utilize returns a manifest like what I noted earlier, where no bin is present:

"1.18.0" : {
      "name" : "sshpk",
      "description" : "A library for finding and using SSH public keys",
      "version" : "1.18.0",

...

      "directories" : {
        "bin" : "./bin",
        "lib" : "./lib",
        "man" : "./man/man1"
      },

...

    }

To be clear though, this is just an explanation as to why the error is not observed when using the public registry; not a root cause of the bug itself.

[lorenzogrv]

Oh, I see; misunderstood your previous comment.

Some information after other findings:

• My previous diagnose about npm publish introducing bin: {} was not correct.
• Our private registry introduces the bin: {}, but the gziped package json is correct (has only directories.bin)
• Our private package registry is the gitlab integrated one

Looking at traces at this issue seems the place where the bug triggers is https://github.com/npm/cli/blob/v11.6.2/node_modules/pacote/lib/registry.js#L134 and the reason behind the bug seems that package manifest is initialized someway with undefined path; so path.join complains during actual normalization. Did not dig more though.

That said, seems clear to me this is not a bug with npm install but with registry data response normalization

[chabb]

Same issue here, we've a custom registry. Using the npmjs registry for standard package fixed the issue. I think our custom registry add 'something' that makes fail npm. Reverting to an older npm version fixes the issue too

[Thoompa]

I had the same issue: ERR_INVALID_ARG_TYPE in @npmcli/package-json/lib/normalize.js line 479