Gar

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

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`,...

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

So in the broken state where there is a entry in the lock that looks like this ```json "node_modules/@my-scope/my-package": { "resolved": "packages/some-folder/my-package", "link": true }, ``` Does `packages/some-folder/my-package` still exist?...

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

That is a very succinct reproduction case, thank you. How did you get the repo into that state?

I don't know that solution is the right one. It seems a little overwrought. "do the install twice based on new state Arborist is tracking for this single situation." feels...

Won't this still omit the package-lock if the package.json is an empty object?

It seems to me the root problem here is that the check for the existence of a package.json is happening too late. Arborist should never be given the task of...

This would need a test.