fix: Add better error message when lockfile is malformed

[Nokel81]

Sometimes when I am working with a monorepo of many workspaces with intermittencies I encounter the following error:

npm ERR! Cannot read properties of undefined (reading 'extraneous')

Which isn't very actionable. It also isn't very actionable with I add the --verbose option. All that does is point to @npmcli/arborist/lib/arborist/load-virtual.js:297:30.

Having added some logging manually I have been always able to fix up the lock file merely but removing the offending entry and then running npm install again.

[Nokel81]

I would like to have added a test case for this but I have never contributed to this repo before and don't know how to mock the relevant areas.

[wraithgar]

Can you go into more detail about how you fix up the lockfile?

[Nokel81]

sure,

I found I was in the state that the node_modules/@my-scope/my-package entry existed as an entry similar to:

"node_modules/@my-scope/my-package": {
  "resolved": "packages/some-folder/my-package",
  "link": true
},

but the corresponding entry with key "packages/some-folder/my-package" did not exist.

[wraithgar]

Is this the kind of thing we should be manually fixing up instead?

[Nokel81]

That would be even better, but I don't think I know enough about arborist to make that change.

[wraithgar]

We can start by building on your own reproduction case, which appears to be a good one.

If I'm understanding correctly you have a workspace that's properly linked into node_modules, and somehow the link gets removed in the tree?

If that's really the case then once you fix the lockfile and run npm install what does npm do? Does it rebuild the lockfile identically to before you removed that line and make the symlink?

[wraithgar]

Or is it the other way around, where the link still exists but the underlying package was moved?

[Nokel81]

if I'm understanding correctly you have a workspace that's properly linked into node_modules, and somehow the link gets removed in the tree?

If that's really the case then once you fix the lockfile and run npm install what does npm do? Does it rebuild the lockfile identically to before you removed that line and make the symlink?

npm install does indeed recreate the lockfile identically except it adds the node_modules/@my-scope/my-package entry back and it also adds the packages/some-folder/my-package entry with the name, version, license, dependencies, etc.. as expected.

[Nokel81]

And the link from the top level node_modules/@my-scope/my-package folder is created correctly too

[wraithgar]

So in the broken state where there is a entry in the lock that looks like this

"node_modules/@my-scope/my-package": {
  "resolved": "packages/some-folder/my-package",
  "link": true
},

Does packages/some-folder/my-package still exist? Is just the link missing?

[Nokel81]

No that entry in the lock file doesn't exist. And the symlink also doesn't exist

Which is why I think I see the initial error:

npm ERR! Cannot read properties of undefined (reading 'extraneous')

[wraithgar]

Ok, sorry I'm confused as to what the error state is. Is there a reproducible way to trigger it?

[Nokel81]

Yeah, let me try and make a repo

[Nokel81]

@wraithgar Here is the demo repo https://github.com/Nokel81/npm-cli-error-case

[wraithgar]

That is a very succinct reproduction case, thank you.

How did you get the repo into that state?

[Nokel81]

To make the demo I manually modified the package-lock.json. I don't remember how it happened for me the very first time.