Fix panic on CLI --typeRoots with relative path#3866
Conversation
…tions like typeRoots Agent-Logs-Url: https://github.com/microsoft/typescript-go/sessions/cda3a033-1c28-422d-a1b0-88ed96ae1aef Co-authored-by: jakebailey <5341706+jakebailey@users.noreply.github.com>
--typeRoots <relative>--typeRoots with relative path
There was a problem hiding this comment.
Pull request overview
Note
Copilot was unable to run its full agentic suite in this review.
Fixes a panic when CLI list options containing relative file paths (e.g. --typeRoots t) reach the VFS without being converted to absolute paths, by ensuring ConvertOptionToAbsolutePath handles the []any shape produced by the CLI list parser.
Changes:
- Add
[]anyhandling inConvertOptionToAbsolutePathto normalize string elements to absolute paths. - Add a new compiler test case for
typeRootswith a relative path plus corresponding baselines.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
internal/tsoptions/parsinghelpers.go |
Normalizes []any list option values containing file paths into absolute paths to prevent VFS panics. |
testdata/tests/cases/compiler/typeRootsRelativePath.ts |
Adds coverage for a relative typeRoots scenario (regression test). |
testdata/baselines/reference/compiler/typeRootsRelativePath.types |
Baseline output for the new test’s type display. |
testdata/baselines/reference/compiler/typeRootsRelativePath.symbols |
Baseline output for the new test’s symbol display. |
testdata/baselines/reference/compiler/typeRootsRelativePath.errors.txt |
Baseline output asserting the expected TS2688 error (instead of a panic). |
| if arr, ok := v.([]any); ok { | ||
| return core.Map(arr, func(item any) any { | ||
| if s, isStr := item.(string); isStr { | ||
| return tspath.GetNormalizedAbsolutePath(s, cwd) | ||
| } | ||
| return item | ||
| }), true | ||
| } |
There was a problem hiding this comment.
The reviewer was correct — the compiler test exercises the []string path via the test harness (which manually normalizes TypeRoots on lines 183-185 of harnessutil.go), not the []any CLI parser path. Added a unit test TestParseCommandLineTypeRootsRelativePath in 97e9f6b that calls ParseCommandLine with --typeRoots t and asserts the result is an absolute path, directly exercising the []any branch.
| return tspath.GetNormalizedAbsolutePath(item, cwd) | ||
| }), true | ||
| } | ||
| if arr, ok := v.([]any); ok { | ||
| return core.Map(arr, func(item any) any { | ||
| if s, isStr := item.(string); isStr { | ||
| return tspath.GetNormalizedAbsolutePath(s, cwd) | ||
| } | ||
| return item | ||
| }), true | ||
| } |
There was a problem hiding this comment.
That won't work, slices are invariant
There was a problem hiding this comment.
Right, Go slices are invariant so []any and []string can't share a common generic handler. The two branches are necessary.
…code path Agent-Logs-Url: https://github.com/microsoft/typescript-go/sessions/8ac80b14-1d54-4b55-b72c-26ee71043c72 Co-authored-by: jakebailey <5341706+jakebailey@users.noreply.github.com>
CLI list options with file paths (e.g.
--typeRoots t) panic becauseConvertOptionToAbsolutePathonly handles[]string, but the CLI parser produces[]anyfromparseListTypeOption. The type assertion silently fails, leaving relative paths unresolved before they hit the VFS.[]anyfallback inConvertOptionToAbsolutePathto normalize each element to an absolute pathtypeRootsRelativePath.tsTestParseCommandLineTypeRootsRelativePaththat callsParseCommandLinewith--typeRoots tand verifies the result is an absolute path, directly exercising the[]anycode path