[turborepo] "error performing lockfile operation" on 1.9.3

[jgoz]

What version of Turborepo are you using?

1.9.3

What package manager are you using / does the bug impact?

npm

What operating system are you using?

Mac

Describe the Bug

After upgrading to 1.9.3. from 1.8, I'm seeing the following warning when running any turbo command:

Issues occurred when constructing package graph. Turbo will function, but some features may not be available:  4 errors occurred:
        * error performing lockfile operation
        * error performing lockfile operation
        * error performing lockfile operation
        * error performing lockfile operation

I also see it on the canary builds. Turborepo operates the way it used to (from what I can tell) but I can't find a way to determine the actual nature of these errors. Increasing verbosity doesn't appear to help.

Expected Behavior

Expected to see a description of the actual lockfile error(s) so that they can be corrected.

To Reproduce

This happens whenever I run turbo <command>. Unable to share a repo link, as it's a private repository.

Reproduction Repo

No response

[chris-olszewski]

Can you provide a lockfile or a reproduction repo?

[jgoz]

Can you provide a lockfile or a reproduction repo?

Is there a way to share a private lock file with you directly?

[chris-olszewski]

Probably the easiest way would be to create a private repo with the lockfile and add me as a collaborator. Also,1.9.4-canary.7 should have a better error message that includes the underlying error which probably can point me in the right direction.

[jgoz]

I was setting up a bare repo for this lockfile, but I think I stumbled on the root of the issue. Npm adds lockfile entries for workspaces that look like this:

    "node_modules/@myscope/mypackage": {
      "resolved": "packages/mypackage",
      "link": true
    },

It's important to note that mypackage exists as both a workspace dependency and a registry dependency for...reasons. It seems that turbo doesn't like that this entry is missing a version even though that's valid for workspace dependencies because there is also an entry with the same package name that gets resolved as a non-workspace dependency:

* error performing lockfile operation: Missing version from non-workspace package: 'node_modules/@myscope/mypackage'

I discovered a couple more instances of private workspace packages that happened to have the same name as some deep transitive dependencies from 3rd parties, so the original 4 errors might all be related to this.

[chris-olszewski]

That sounds correct to me and this is enough information for me to get a repro! I'll work on getting a fix up today.

[chris-olszewski]

@jgoz I spoke too soon. I've been trying to recreate a failing example where there's both a workspace and registry dependency of the same package, but with no luck. When I was testing, package-lock.json kept producing both a node_modules/@myscope/mypackage as you described, but in the registry version would appear as node_modules/another_package/node_modules/@myscope/mypackage where another_package is a registry package that depends on @myscope/mypackage. Could you detail how the workspace version of @myscope/mypackage is referenced in your monorepo? e.g. "@myscope/mypackage": "*" in some package.json. Could you include any keys in the packages field of package-lock.json that have node_modules/@myscope/mypackage as a substring? (or if possible privately share your package-lock.json with me).

Thanks!

[jgoz]

@chris-olszewski Thank you, sent an invite. In general, yes workspace versions are referenced like this:

"@myscope/mypackage": "*"

Though they may also be referenced as both peer and dev dependencies for legacy reasons. We were early adopters of npm's workspaces feature and fought with it every step of the way, especially when strictPeerDependencies was turned on. I suspect there is some significant cleanup we could do around this, and being able to see the specific errors that turborepo has found would be a good first start.