Rule proposal: use satisfies over type annotation

[jgoux]

Before You File a Proposal Please Confirm You Have Done The Following...

• I have searched for related issues and found none that match my proposal.
• I have searched the current rule list and found no rules that match my proposal.
• I have read the FAQ and my problem is not listed.

My proposal is suitable for this project

• My proposal specifically checks TypeScript syntax, or it proposes a check that requires type information to be accurate.
• My proposal is not a "formatting rule"; meaning it does not just enforce how code is formatted (whitespace, brace placement, etc).
• I believe my proposal would be useful to the broader TypeScript community (meaning it is not a niche proposal).

Description

My rule would check that variables with type annotation should instead use the new satisfies operator.

Fail Cases

const setting: Setting = { color: "blue" };

Pass Cases

const setting = { color: "blue" } satisfies Setting;

Additional Info

Since satisfies is available it seems like its usage is often more correct than type annotation. Hopefully, typescript-eslint could help enforce its usage to have better type safety. 😄

[JoshuaKGoldberg]

🤔 hmm. We generally try not to take in rules that ban swathes of TypeScript syntax. You can achieve this rule (minus auto-fixing) with no-restricted-syntax: https://typescript-eslint.io/play#ts=4.9.3&sourceType=module&showAST=es&code=MYewdgzgLgBBCmUoEswHMBcMDKiXpgF4YBvGUAGxACcsAiAIwoFd46YBfAbgCgg&eslintrc=N4KABGBEBOCuA2BTAzpAXGUEKQHYHsBaaFAF2gEsBjUxAE0OQE9dSBDAD3TAG1xsciaNHzRIAGn4DIANTaU2AIyQARRFXjy2pUWAB8YAJJ1ErCgDMKQnqSYAHRAEFcBdqQr5cAXUhSwX-gBfEECgA&tsconfig=N4KABGBEDGD2C2AHAlgGwKYCcDyiAuysAdgM6QBcYoEEkJemy0eAcgK6qoDCAFutAGsylBm3TgwAXxCSgA

{
  "rules": {
    "no-restricted-syntax": [
      "error",
      {
        "message": "Prefer using the satisfies operator, not explicit type annotations.",
        "selector": "VariableDeclarator > Identifier[typeAnnotation]"
      }
    ]
  }
}

I think we should leave this open for a little while and see if there's a lot of demand for it. You might consider publishing a standalone ESLint plugin with a custom rule if you want auto-fixing.

[bradzacher]

it seems like its usage is often more correct than type annotation

Could you expand on what you mean here?
The only case I can think of when it is more correct is if you're making sure an object satisfies a record type.
Otherwise (unless I'm mistaken) there shouldn't be any difference between the two.

[jgoux]

it seems like its usage is often more correct than type annotation

Could you expand on what you mean here? The only case I can think of when it is more correct is if you're making sure an object satisfies a record type. Otherwise (unless I'm mistaken) there shouldn't be any difference between the two.

Yes, the object satisfying a record type is the use case I have in mind. And as you said otherwise there is no difference, that's why I would prefer enforcing satisfied in my codebase over type annotation. 👍

[bradzacher]

In that case - as Josh said - you can achieve this with no-restricted-syntax

https://typescript-eslint.io/linting/troubleshooting#how-can-i-ban-specific-language-feature

[bmish]

Just to spell out a bit more of the difference between them, satisfies allowed me to ensure a variable met my type requirements without losing the more-specific type information from the actual initialization in this example: bmish/eslint-doc-generator#249

[bradzacher]

@bmish yes that's really the intended usecase of satisfies really - it allows you to validate that a type is assignable to some other type without coercing it to that type.

The motivating usecase for it was really to replace useless no-op generic functions people would use.

fuction asOptions<T extends Record<string, boolean>>(arg: T): T {
  return arg;
}

// bad as you lose the keys
const foo = {prop: true} as Record<string, boolean>;

// old style - Bad because useless fn call
const bar = asOptions({prop: true});

// new style - good - no runtime code for type check
const baz = {prop: true} satisfies Record<string, boolean>;

playground

---

To be clear - we're not saying that there aren't uses for satisfies - not at all! It's a great tool to be used in the right places.

Instead all we're saying is that we don't want to include rules that are simple syntax bans unless there's additional value we can add in the rule (like auto or suggestion fixers)