这是indexloc提供的服务,不要输入任何密码
Skip to content

Dep graph does not support mix of internal/external dependencies with same name #796

@thebanjomatic

Description

@thebanjomatic

What version of Turborepo are you using?

1.1.4

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

pnpm, Yarn v1, Yarn v2/v3 (node_modules linker only)

What operating system are you using?

Windows

Describe the Bug

I have a monorepo for some build tools, and a lot of the packages in the monorepo are bootstrapped and built using a previous version of the library (technically using a published canary release, but same story). When turbo tries to build the dependency graph, it doesn't consider the specified version/range of the dependency, it just assumes that if that package name exists in the workspace it must be an internal dependency. Because of this the cycles are detected and the process hangs.

Expected Behavior

Turbo should identify if the dependency's semver range matches the version of the workspace package before adding the node as an internal dependency and should be considered external if the range does not match. Some additional work would probably need to be done to support parsing of protocols such as workspace: and npm:.

The npm: protocol is a little tricky also because by default (with yarn at least) it will still use the workspace version if the specified range matches local package. This can be controlled with the yarn option enableTransparentWorkspaces, but it would seem like a decent first pass at this would just infer an internal dependency for the npm: protocol if the semver range matches the local package.

To Reproduce

I can't easily share the reproducer to this since the packages involved are private, but the basic idea is:
packages/package-a/package.json:

{
  "name": "package-a",
  "version": "1.1.0",
  "devDependencies": {
    "package-b": "1.1.0"
  }
}
{
  "name": "package-b",
  "version": "1.1.0",
  "devDependencies": {
     "package-a": "1.0.0"
  }
}

If you are ignoring the versions, this looks like a cycle, but package-b doesn't actually have to wait for package-a to build because its being sourced from node_modules

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions