Fix normalizePath rooting a relative path that begins with ./ followed by a slash

[Osamaali313]

Fixes #63588

Problem

simpleNormalizePath (the allocation-free fast path added in #60812) strips a leading ./ before checking whether the next character is itself a separator:

let simplified = path.replace(/\/\.\//g, "/");
if (simplified.startsWith("./")) {
    simplified = simplified.slice(2);
}

For an input like .//a, the /./ cleanup is a no-op, then startsWith("./") is true and slice(2) removes ./ and leaves /a — but that second / was a redundant separator, not a root. /a then re-tests clean and is returned, so a relative path is silently turned into a rooted one:

input	before	expected
.//a	/a	a
.//a/b	/a/b	a/b
././/a	/a	a

This affects both normalizePath and getNormalizedAbsolutePath. The slow-path component walker (the documented oracle) returns the correct relative result; only the fast path is wrong.

Reproduction (real compiler, esbuild-bundled)

getNormalizedAbsolutePath(".//a", "")  ->  "/a"    (expected "a")
normalizePath(".//a")                  ->  "/a"    (expected "a")

Fix

Only strip the leading ./ when it is an actual . segment — i.e. when the character after it is not another separator; otherwise fall through to the slow path, which normalizes correctly:

if (simplified.startsWith("./") && simplified.charCodeAt(2) !== CharacterCodes.slash) {
    simplified = simplified.slice(2);
}

Verification

• RED→GREEN confirmed on the bundled compiler for the cases above.
• Exhaustive differential over all strings up to length 8 from {'.', '/', 'a'} (9,840 inputs), original vs patched: 172 differing results, every one a ./-followed-by-separator case where the patched output drops the spurious leading / to match the slow path; zero changes elsewhere.

Test

Adds .//a, .//a/b, ././/a assertions to the getNormalizedAbsolutePath unit test in src/testRunner/unittests/paths.ts.

[typescript-automation]

This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise.

[typescript-automation]

This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[RyanCavanaugh]

@Osamaali313 what coding agent are you using?

[Osamaali313]

I use Claude Code (an AI coding assistant). I review every change myself and verify each fix RED→GREEN against the real code before opening a PR — for this one I esbuild-bundled the compiler and ran an exhaustive differential over all strings up to length 8 from {'.','/','a'} (9,840 inputs): 172 results change, every one a ./-then-separator case corrected to match the slow path, with zero changes elsewhere.

I've opened #63588 describing the bug, per the automation bot. Happy to adjust the fix or tests however you'd prefer.

[RyanCavanaugh]

@Osamaali313 Any idea why Claude Code didn't read https://github.com/microsoft/TypeScript/blob/main/AGENTS.md#-do-not-create-coding-prs-for-this-repository ?

[Osamaali313]

You're right, and that's on me — I didn't read AGENTS.md before opening the PR; I went straight to the fix without checking this repo's agent policy, which is exactly the gap you're pointing at. Apologies for the noise. I understand TypeScript is in maintenance mode and a general bug fix like this isn't one of the accepted categories, so I won't open further PRs here and will direct anything like this to typescript-go instead. I've closed the linked issue (#63588) as well.