Don't use noErrorTruncation when printing types with maximumLength set
#62091
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR fixes an issue where TypeScript was not properly respecting the maximumLength parameter when printing types, due to the noErrorTruncation compiler option taking precedence. The fix ensures that when a maximumLength is explicitly set, truncation can still occur even if noErrorTruncation is enabled.
- Modified the logic in
typeToTypeNodeto only applynoErrorTruncationwhen nomaximumLengthis specified - Added a test case to verify the fix works correctly with long type definitions
Reviewed Changes
Copilot reviewed 2 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| src/compiler/checker.ts | Updated truncation logic to respect maximumLength parameter over noErrorTruncation setting |
| tests/cases/fourslash/quickinfoVerbosityNoErrorTruncation1.ts | Added test case with long type definition to verify truncation behavior |
| out?: WriterContextOut, | ||
| ): string { | ||
| const noTruncation = compilerOptions.noErrorTruncation || | ||
| const noTruncation = !maximumLength && compilerOptions.noErrorTruncation || |
There was a problem hiding this comment.
alternatively, compilerOptions.noErrorTruncation could increase the maximumLength to its usual limit - but I think this small solution is a better way out of this
There was a problem hiding this comment.
with this, the another user who reported the problem here gets:
and they agree it's an improvement but they still can't expand this type in VS Code - when they can expand other types
fixes #62032
cc @gabritto