Repository navigation
[BUG] unable to publish when using publishConfig option - ERR_INVALID_ARG_TYPE #2834
Description
Current Behavior:
When running npm publish the following error appears:
npm ERR! code ERR_INVALID_ARG_TYPE
npm ERR! The "path" argument must be of type string. Received undefined
npm ERR! A complete log of this run can be found in:
npm ERR! /home/xx/.npm/_logs/2021-03-06T09_10_43_193Z-debug.log
The debug trace shows:
23 verbose stack TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received undefined
23 verbose stack at validateString (internal/validators.js:124:11)
23 verbose stack at join (path.js:1039:7)
23 verbose stack at flatten (/home/xx/.nvm/versions/node/v14.16.0/lib/node_modules/npm/lib/utils/flat-options.js:50:10)
23 verbose stack at Publish.publishConfigToOpts (/home/xx/.nvm/versions/node/v14.16.0/lib/node_modules/npm/lib/publish.js:140:12)
23 verbose stack at Publish.publish (/home/xx/.nvm/versions/node/v14.16.0/lib/node_modules/npm/lib/publish.js:58:32)
Expected Behavior:
npm publish to continue working as it did in version 6
Steps To Reproduce:
- In this environment...
Ubuntu 20.04
Node 14.16.0
npm 7.6.1 - With this config...
The package is configured to be published to github as per: github instrutions
package.json includes:
"publishConfig": {
"registry": "https://npm.pkg.github.com"
},
- Run
npm publish - See error:
npm ERR! code ERR_INVALID_ARG_TYPE
npm ERR! The "path" argument must be of type string. Received undefined`
Environment:
Ubuntu 20.04
Node 14.16.0
npm 7.6.1
Possible cause
The issue seems to be related to changes made to the flatten() method in utils/flat-options.js
This is being called with the publishConfig which only contains a registry property.
However flatten (line 50), tries to use join() to create a path from the non-existent'cache property, hence the error (I believe).
Looking at the changes, it seems that v6 used to read the npm config for the cache value.
Workaround
My temporary workaround for this is to add a cache property to the publishConfig section, using the default cache value:
"publishConfig": {
"cache": "~/.npm",
"registry": "https://npm.pkg.github.com"
},
As others have noted, this workaround has the side-effect of creating a ~/.npm directory in the root of the project. My solution to this was then simply to add ~/.npm to .gitgnore
I guess that you could name this cache directory whatever you like. I used the default value simply to make publish work again. Note that my suggestion is purely a workaround and doesn't resolve the actual issue. Although I could see in the v7 code where the change has been made that is causing this issue, unfortunately I was unable to understand why that change was made.
Activity
FingalP commentedon Mar 8, 2021
We had the same issue. The workaround works for now, thanks @waitem
Fadoli commentedon Mar 9, 2021
Having the same issue here,
an other workaround (if you don't want to modify all your publish config) is to modify line 51 of flat-options.js to
fix attempt according to npm/cli#2834
johnthad commentedon Mar 12, 2021
This workaround does create a local directory
~with the cache info (macOS 10.15.7).yellowtailfan commentedon Mar 12, 2021
I just encountered this bug, and the
"cache": "~/.npm",work around caused a side-effect where the cache was written in the project folder (<project>/~/.npm) instead of my home directory. So I've reverted back to NPM 6.x instead. I'm using NPM in WSL2.Remove obsolete publishConfig (causing publishing issues)
stheine commentedon Mar 15, 2021
experienced the same in
npm 7.6.3andnode v14.16.0. found a workaround by completely removing thepublishConfigsection from thepackage.json.fix(publish): handle case where multiple config list is present
lorenzogrv commentedon Mar 15, 2021
Hi everybody. I can confirm this issue too. Proposed workaround (adding
publishConfig.cache) helped to step over, same side-effect as @yellowtailfan explains.In this particular case I can't remove
publishConfigfrompackage.jsonas it's need to publish against gitlab's package registry, as suggested by @stheine .Did not downgrade to
6.xto test.I'm glad to see the pull request over this comment. Keep up the good work.
$ uname -srv Linux 5.4.0-66-generic #74~18.04.2-Ubuntu SMP Fri Feb 5 11:17:31 UTC 2021 $ npm --version 7.6.3 $ node --version v12.21.0I suggest future readers
"cache": "cache.npm"or the like so you don't accidentally try torm -r ~within your project, which may have fatal effects within your user's homelorenzogrv commentedon Mar 15, 2021
Hi again. Just noticed the workaround has another side-effect: It will publish with
--tagset toundefinedCheck
npm show @scope/package-nameto see if side-effect affects you.npm publish --tag latestworks as expected, after the needed version bump.150 remaining items
## 9.0.37
## 4.0.30
## 5.0.6
## 5.0.6
## 6.0.38
## 5.0.28
UCC: (feature) Add fix to publish package npm/cli#2834
Add the need for the tag option into publish
Gauhar commentedon Mar 31, 2021
I can confirm that this issue was happening on my end as well on
npm version 7.6.3andnode version v15.12.0. Since we I am publishing a public package then you can get rid ofpublishConfigyairEO commentedon Apr 10, 2021
I also confirm this issue occurs as of right now, using
npmversion7.9.0,nodeversionv12.21.0I've removed the
publishConfigproperty from thepackage.jsonfile and now I am able to publish.workaround for NPM bug - npm/cli#2834
Remove `publishConfig`
# @ctx-core/s3
chore: workaround for NPM cache issue
chore: workaround for NPM cache issue