Fix importModuleSpecifier: "project-relative" ignored when tsconfig paths are configured

[Copilot]

With project-relative and a tsconfig defining paths aliases, intra-project auto-imports were emitting the alias (e.g. @utils/helper) instead of a relative path (e.g. ../utils/helper).

Two regressions in getLocalModuleSpecifier (internal/modulespecifiers/specifiers.go) vs. the TS reference, both inside the RelativePreferenceExternalNonRelative branch:

• projectDirectory included the config filename. Used compilerOptions.ConfigFilePath directly instead of its directory, so sourceIsInternal/targetIsInternal were always false (no file path starts with …/tsconfig.json). This silently disabled the tsconfig-boundary check that decides when crossing the project root should prefer the alias.
• Conditional return relativePath. After the boundary checks confirm an intra-package import, TS returns relativePath unconditionally; the port gated it on len(fromPackageJsonImports) > 0 and otherwise fell through to the "fewer components wins" tiebreaker, which always chose the short paths alias over a deeper relative path.

Changes

• Compute projectDirectory as tspath.GetDirectoryPath(compilerOptions.ConfigFilePath).
• Drop the fromPackageJsonImports gate and return relativePath unconditionally at the end of the ExternalNonRelative block.
• Switch the source/target internal classification from strings.HasPrefix to tspath.Path.ContainsPath, which enforces a separator boundary so siblings like /project vs /project2 aren't conflated.
• Add fourslash regression TestImportModuleSpecifierPreferenceProjectRelativeWithPaths reproducing the issue scenario (tsconfig with paths, intra-project import, project-relative).

The pre-existing TestImportNameCodeFix_externalNonRelateive2 was baselining the buggy behavior; with the projectDirectory fix the boundary check now fires correctly and its existing assertions (alias for cross-boundary, relative for intra-package) hold without changes.

[jakebailey]

Seems like a bug? Not sure why projectDirectory would be the config file path, which is a filename, not a dir name.

[Copilot]

Pull request overview

Fixes a regression in module specifier selection so that ImportModuleSpecifierPreferenceProjectRelative correctly prefers relative paths for intra-project auto-imports even when tsconfig.json paths aliases exist.

Changes:

• Compute projectDirectory from the directory containing compilerOptions.ConfigFilePath (not the config filename itself).
• Always return the computed relativePath for intra-package imports in the RelativePreferenceExternalNonRelative branch.
• Add a new fourslash regression test + baseline for project-relative with paths aliases.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
internal/modulespecifiers/specifiers.go	Fixes project directory detection and ensures intra-package imports return relative specifiers under ExternalNonRelative.
internal/fourslash/tests/importModuleSpecifierPreference_test.go	Adds regression test covering project-relative with paths aliases.
testdata/baselines/reference/fourslash/autoImports/importModuleSpecifierPreferenceProjectRelativeWithPaths.baseline.md	Adds expected baseline showing a relative import is chosen.

[jakebailey]

@copilot consider

[Copilot]

Switched the boundary check from strings.HasPrefix to tspath.Path.ContainsPath in be9152f, which has a proper separator-boundary check so /project vs /project2 aren't conflated. The TS reference uses plain startsWith here so it has the same latent issue, but since both projectDirectory and the source/module paths are already-normalized tspath.Path values, Path.ContainsPath is the natural fit on the Go side.