Package scoping fails when workspace glob has leading ./

[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

[chris-olszewski]

Thanks for the report! The package scoping is definitely a bug.

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

This is correct, directory based filters start with a ./ to indicate you're specifying a path and not a package name. See https://turbo.build/repo/docs/crafting-your-repository/running-tasks#filtering-by-directory