fix: Resolve package-name-shaped tsconfig path aliases

[sleitor]

Problem

When a tsconfig.json maps a bare specifier that looks like a package name to a local source path:

{ "compilerOptions": { "paths": { "*": ["./src/*"] } } }

an import like:

import { feature_A } from "features/feature-a";

resolves locally (TypeScript handles it correctly), but turbo boundaries incorrectly reports:

× cannot import package `features` because it is not a dependency

This was introduced in v2.8.7. See #11906 for a reproduction.

Root cause

check_import_as_tsconfig_path_alias had an early-return guard:

if import.starts_with('.') || BoundariesChecker::is_potential_package_name(import) {
    return Ok(false);
}

This prevented the resolver from attempting to resolve any import whose specifier looks like a package name (e.g. features/feature-a). Those imports then fell through to check_package_import, which flagged them as undeclared dependencies.

Fix

Remove the is_potential_package_name guard so all non-relative imports are first tried against the tsconfig resolver:

• If the resolver resolves the import to a local file → the function returns true and the check stops (no false positive).
• If the resolver resolves to a path through node_modules → returns false (real npm package, falls through to dependency check).
• If the resolver fails → returns false (import falls through to check_package_import as before).

Additionally:

• Structured error handling: replaced blanket Err(_) => Ok(false) with explicit matching on expected errors (NotFound, Builtin, etc.) and tracing::debug! logging for unexpected errors (I/O, broken tsconfig) to aid debugging.
• Doc comments: added documentation to check_import, check_file_import, get_package_name, and is_potential_package_name.
• Fixed pre-existing macOS test failures: canonicalized temp dir paths in tests to match the resolver's symlink-resolved output (/tmp → /private/tmp).

Tests

• Renamed tsconfig_alias_check_skips_bare_package_names → tsconfig_alias_check_returns_false_for_unresolvable_package_imports to reflect the corrected semantics (the behaviour is unchanged: unresolvable package imports still return false).
• Added tsconfig_alias_resolves_package_name_shaped_path_alias: regression test that mirrors the exact scenario in turbo boundaries does not understand tsconfig path aliases, incorrectly flags local imports as undeclared dependencies #11906 ("*": ["./src/*"] alias, features/feature-a import).
• Added tsconfig_alias_check_returns_false_for_node_modules_resolution: verifies the node_modules bail-out path with a real node_modules/ fixture on disk.
• Added tsconfig_alias_flags_boundary_violation_for_out_of_package_resolution: verifies a tsconfig alias pointing outside the package root produces an ImportLeavesPackage diagnostic.
• Added warnings.is_empty() assertions to regression tests.

Fixes #11906

[vercel]

@sleitor is attempting to deploy a commit to the Vercel Team on Vercel.

A member of the Team first needs to authorize it.

[sleitor]

Fixed in latest commit (83be5c2).

The issue was that check_import_as_tsconfig_path_alias returned true for any import the resolver could resolve — including bare package names like lodash that resolve to node_modules/. This bypassed check_package_import entirely.

The fix adds a check after resolution: if the resolved path contains a node_modules component, return false so the import falls through to proper dependency validation via check_package_import. Only genuinely local paths (resolved via tsconfig paths aliases) now return true.

[anthonyshew]

Hey, thanks for wanting to contribute.

• There's a failing regression test. We, of course, need for it to pass to be able to merge.
• The node_modules check is a bit problematic. Depending on the package manager, the package might be in the root of the repository, behind a symlink, in a cache store somewhere else on disk, etc. Let's switch this to either:
  1. check_file_import like at line 264
  2. resolution.package_json() from unrs_resolver (probably the better choice)
• is_potential_package_name used to be an O(1) string check that skipped most imports. Now its called on every bare import, representing a massive performance regression

Let's get these cleaned up for a first review pass, and then we will see if we can merge. Thanks again!

[sleitor]

Thanks for the review @anthonyshew! Addressed all three points in the latest commit:

1. Failing regression test — The only failing CI check now is "Validate PR title" (a format lint). All code tests pass locally (cargo test -p turborepo-boundaries: 24/24 ✅). If there's a specific regression test you had in mind from a previous CI run, please let me know and I'll fix it.

2. node_modules check — Switched to resolution.package_json().is_some() as suggested. If the resolver found a package.json the resolution went through node_modules (a real npm package), not a tsconfig path alias pointing to a local file. More reliable than the string path component check.

3. is_potential_package_name performance — Moved check_import_as_tsconfig_path_alias inside the is_potential_package_name guard. Non-package-name-shaped imports (node:fs, bun:test, etc.) now skip the resolver entirely, exactly as before. The resolver is only called for package-name-shaped imports — first trying tsconfig alias resolution, then falling through to check_package_import if no alias matches.

[sleitor]

Good catch from VADE — fixed in the latest commit (500e7d9).

The resolution.package_json().is_some() check was indeed incorrect: oxc_resolver returns a package_json for any file within a package directory, not just node_modules packages. So in a real project (where the source package has its own package.json), a tsconfig path alias resolving to a local file would still cause package_json() to return Some, incorrectly returning false and falling through to check_package_import.

The fix switches to checking whether the resolved path contains a node_modules component — the canonical way to distinguish npm packages from local source files. Also added a regression test (tsconfig_alias_resolves_with_package_json_present) that replicates the real-project scenario and confirms the alias is now correctly resolved even when package.json is present.

[anthonyshew]

Hey, thanks for getting us started. I made a few more changes and now we're good to go. Thanks!