I bet this would be a fascinating rule to figure out the details of... but it's blocked by the lack of a TypeScript assignability API: microsoft/TypeScript#9879.

As much as I love a good Chuck Norris reference, not much point to discussing here until we have a TypeScript assignability API. 😞

Related:

• Enhancement: Rule to prefer type annotation over type assertion when possible #709: not the same request, but in the same area of blocked functionality
• feature request: forbid unsafe downcasting #3226: somewhat a dup, but that's an old issue from before our blocked by external API label and has a less flavorful OP

Wow, I didn't know such an API didn't exist. I can't imagine how hard it must be to write rules without having a tool as basic as isTypeAssignableTo :/

In the meantime, for my use case, I can just use a noop function that takes care of this. Something like:

function safeAs<T>(x: T) {
  return x;
}

This allows you to do safeAs<string | undefined>('some text'), but prevents you from doing

const x: string | number = 42;
const y = safeAs<string>(x);

Playground link here :)

Anyways, thanks for your quick response @JoshuaKGoldberg ! I leave the decision up to you as to whether it makes sense or not to keep this issue open.

The satisfies operator will do the same check as a no-op function (but it doesn't change the type). A variable annotation also does the same safe checks (and it does change the type).

Thanks @bradzacher ! The issue with a variable annotation is that it requires a separate statement. I believe the place where I use as the most is in large objects in files with mock data for tests. I want to be able to have an object like

const bigObject = {
  name: 'Random',
  lastName: 'Guy',
  age: 42,
}

and then, in one test, do

bigObject.age = '42'; // BE sometimes sends age as a string

Since the objects are really large, I don't want to write the types myself. So, my "only" option is writing

const bigObject = {
  name: 'Random',
  lastName: 'Guy',
  age: 42 as string | number,
}

To use a variable annotation I would need to declare const age: string | number beforehand. And since I have many objects (and many properties which require these kind of annotations), doing that would be cumbersome 😅

I would love to see a eslint rule to disallow as entirely, or prefer satisfies over as — or something along those lines.

Does such a rule exist? I searched around but couldn't find it. Would the proposal in this issue cover that? Or would maintainers prefer I open a separate issue?

#709 😢 blocked on microsoft/TypeScript#9879

#709 😢 blocked on microsoft/TypeScript#9879

Thansk @JoshuaKGoldberg

I might take a custom linter into my own hands then. Do you foresee any issues if I wrote myself a custom eslint rule, which would simply look for the as operator and report an offense in 100% of cases?

In this codebase specifically, I'm okay saying that "if the author really knows what they're doing and needs to use as, they can eslint-disable directive comment for that line"

@TSMMark for disallowing as see https://typescript-eslint.io/rules/consistent-type-assertions

Note Typescript 5.4 made isTypeAssignableTo public:

• Make isTypeAssignableTo public on TypeChecker microsoft/TypeScript#56448
• Proposal: Type Relationship API microsoft/TypeScript#9879 (comment)

@JoshuaKGoldberg created a discussion stating that it will be usable in the next major: #7936

Does this mean a no-unsafe-type-assertion rule will be possible to add to typescript-eslint v8?

That should be right, yup! 🙌

🎉 For anyone that comes along after v8 is released, consider this "accepting PRs" (and please tag one of us to poke us so we can change the label)

Now that v8 is released, per #7936, we can mark this issue as unblocked! 🚀

I should mention, if anyone's looking for inspiration, there's this implementation by a third-party plugin: https://github.com/danielnixon/eslint-plugin-total-functions/blob/master/src/rules/no-unsafe-type-assertion.ts

Also, it'd be nice to properly document and teach alternatives to unsafe type-casts, here's the note I had in our internal linting docs:

// It takes an advanced TypeScript user to fully make sense of this rule
/**
 * It can sometimes be hard to make sense of this rule, but let's be strict!
 * Tips:
 * - Prefer coercion over assertion: e.g `String(value ?? '')` over `value as string | null`
 *   (this depends on your functional logic)
 * - Try to assign to an explicitly typed variable and TypeScript will tell you about the type difference!
 *     ie: `const newValue: ExpectedType = unsafeValue`
 * - If using TypeScript 4.9+, consider using the `satisfies` Operator:
 *     (https://devblogs.microsoft.com/typescript/announcing-typescript-4-9/#the-satisfies-operator)
 *     `const newValue = {a: "A", b: 2} satisfies ExpectedType`
 * - If using TypeScript 4.9+, consider using the `in` Operator to narrow unlisted properties:
 *     (https://devblogs.microsoft.com/typescript/announcing-typescript-4-9/#unlisted-property-narrowing-with-the-in-operator)
 *     `if ("name" in unsafeValue && typeof unsafeValue.name === "string") ...`
 * - Sometimes just casting as `Partial<>` is sufficient
 * - Double check that you are not accidentally removing `null | undefined` from the type when casting:
 *   - `inputEvent.target as Partial<HTMLInputElement>` <-- Oops!
 *   - `event.target as Partial<HTMLInputElement> | null` <-- Ok!
 */