π Search Terms
"ts-ignore", "ts-expect-error", "noUnusedLocals", "noUnusedLocals underscore", "noUnusedLocals prefix"
β
Viability Checklist
β 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:
- live with the warnings
- disable
noUnusedLabels for test code
- 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
- What do you want to use this for?
- I'd like to use to in my type validation tests.
- 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
- 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.
π Search Terms
"ts-ignore", "ts-expect-error", "noUnusedLocals", "noUnusedLocals underscore", "noUnusedLocals prefix"
β Viability Checklist
β 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
noUnusedLocalsfor your project, and selectively opting out for local types used for testing. Prior to this, you had a couple of less than idea solutions:noUnusedLabelsfor test code@ts-ignoreDepending 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-errorto assert invalid usages of your types in tests,@ts-ignorewould also cause typescript not to flag the type error you're trying to assert with@ts-expect-error.For example, a test like this:
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.
π» Use Cases
noUnusedLocalsnoUnusedLocalsin 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.