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

Package scoping fails when workspace glob has leading ./ #8599

@timostamm

Description

@timostamm

Verify canary release

  • I verified that the issue exists in the latest Turborepo canary release.

Link to code that reproduces this issue

https://github.com/timostamm/turbotest

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

npm

What operating system are you using?

Mac

Which canary version will you have in your reproduction?

v2.0.5 - there's no newer canary

Describe the Bug

In an npm project where workspaces are declared with a leading ./, Automatic Package Scoping is unable to locate the package.

package.json:

{
  "name": "turbotest",
  "workspaces": [
    "./packages/foo",
    "./packages/bar"
  ],
  "packageManager": "npm@9.8.1"
}
$ cd packages/bar
$ npx turbo run test
 WARNING  No locally installed `turbo` found. Using version: 2.0.5.
  × missing packageManager field in package.json

It looks like --filter requires the leading ./ as well:

npx turbo run test -F ./packages/bar
• Packages in scope: bar
...
 Tasks:    1 successful, 1 total

We do not get a match when omitting ./:

$ npx turbo run test -F packages/bar
  × No package found with name 'packages/bar' in workspace

Expected Behavior

I expect filters to match packages/foo regardless of the leading ./ declared in the workspace path, same as npm.

Ideally, ./packages/foo would match both forms. It appears that paths are already normalized (npx turbo run test -F ./packages/../packages/bar locates bar as expected), but don't normalize the leading ./.

To Reproduce

See https://github.com/timostamm/turbotest for a minimal reproducible example.

Additional context

Also see discussion #8514

Metadata

Metadata

Assignees

No one assigned

    Labels

    kind: bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions