Allow leading underscore for types to bypass noUnusedLocals warning

[mostlylikeable]

🔍 Search Terms

"ts-ignore", "ts-expect-error", "noUnusedLocals", "noUnusedLocals underscore", "noUnusedLocals prefix"

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

Add support for leading underscore in type definition name to disable tsc noUnusedLocals warning ts(6196), like it does for other things.

📃 Motivating Example

Allows for easier testing of types by providing a way to enabled noUnusedLocals for your project, and selectively opting out for local types used for testing. Prior to this, you had a couple of less than idea solutions:

1. live with the warnings
2. disable noUnusedLabels for test code
3. use @ts-ignore

Depending on the method you're using for testing your types, you might not be able to use @ts-ignore. For example, if you were relying on usage of @ts-expect-error to assert invalid usages of your types in tests, @ts-ignore would also cause typescript not to flag the type error you're trying to assert with @ts-expect-error.

For example, a test like this:

type StringKeyOf<T extends Record<string, unknown>> = T extends T
  ? Extract<keyof T, string>
  : never;

type TestType = { s: unknown; 1: unknown; };

// NOTE: `expectFails` type will get flagged with unused warning, when `noUnusedLocals` is enabled,
//     and `@ts-ignore` is no help because it also suppresses the compile error we want to validate

// @ts-expect-error - validate type error will occur
type expectFails = Expect<Equals<StringKeyOf<TestType>, 's' | 1>>;

Previously, prefixing the local type with underscore would have no affect on the warning, but now you can update the code to include a leading underscore for the type name, and the warning will go away.

// @ts-expect-error
type _expectFails = Expect<Equals<StringKeyOf<TestType>, 's' | 1>>;

💻 Use Cases

1. What do you want to use this for?
   • I'd like to use to in my type validation tests.
2. What shortcomings exist with current approaches?
   • The current approaches do not provide a very good way to avoid ending up with a lot of warnings in tests, without disabling noUnusedLocals
3. What workarounds are you using in the meantime?
   • I'm currently disabling noUnusedLocals in my project's base tsconfig.json and enabling in tsconfig.build.json. This choice was made so the errors would not be present for developers working on test related code, and since the build config does not include tests, it applies the rule against production code. It results in a less than ideal developer experience though, because developers will see errors in build that don't present when viewing the source code, because vscode is using tsconfig.json.

[RyanCavanaugh]

When I proposed this everyone just said "You mean it doesn't already do that?"

Accepting PRs

[boernard]

Any idea when this will be pulled in?

[KubaJastrz]

Another use-case: zero-runtime exhaustive check from @mattpocock

type SatisfiesNever<T extends never> = never;

type _ = SatisfiesNever<typeof segment>;

[jonshea]

There was a PR addressing this that got some feedback, but it was later closed by the author without merging, and removed from the backlog. Was there a decision against this enhancement, or is it something that just slipped through the cracks? Should we resurrect @a-tarasyuk ’s PR?

[jakebailey]

No decision against it, I think he closed most everything when the Go port was announced. I am not sure why the PR got lost (though I recall that it wasn't quite correct when I last read it).

[jonshea]

Thanks. I took a stab at incorporating the feedback from the previous PR here. #62323