port @typescript-eslint/consistent-type-assertions

[redbmk]

I often find it dangerous to use return x as X as it signals to typescript that you know more than it does. That might be fine for smaller libraries but on larger projects refactoring can be sketchy if you can't trust the compiler.

There's an eslint plugin @typescript-eslint/consistent-type-assertions that can not only enforce style (e.g. <Type>thing vs thing as Type) but can also prevent you from using it at all.

The formatter could handle enforcing consistency. For example if you have assertionStyle: 'angle-bracket':

return x as Type;

becomes

return <Type>x;

The linter could also ensure that you don't force types. Examples of errors:

return <Type>x;
return x as Type;

Examples of valid code (as const is still OK):

const x = { hello: 'world' } as const satisfies Record<string, string>;
const x = { hello: 'world' } as const;
const x: Record<string, string> = { hello: 'world' } as const;

In some cases typescript will still raise an error when trying to cast something that doesn't look correct but a real-world example where it wouldn't catch it is a fetch call where json() returns Promise<any>. Typescript will let you cast it without doing any actual validation:

const response = await fetch(url);
const value = await response.json();
return value as Type

It would be safer to use a validation library (e.g. zod) for any/unknown/untrusted data.

[freeatnet]

Hey @redbmk! I've added noUnsafeTypeAssertion, which should allow you to ban type assertions, except for as const. There is no support for style preference at this time. It's available as a nursery rule in v2.5.9. Here are the docs and examples: https://biomejs.dev/linter/rules/no-unsafe-type-assertion/ Try it out and let me know if it works well in your codebase — feedback is appreciated!