satisfies, ou vérifier sans élargir satisfies, or check without widening

L'annotation vérifie mais élargit. Le as garde mais ne vérifie pas.The annotation checks but widens. The as keeps but doesn't check.

Pour une valeur qu'on écrit soi-même — un objet de config, une palette, une table de routes — on veut deux choses : qu'elle respecte une forme attendue, et qu'on garde le type précis que TypeScript infère (les clés exactes, le type fin de chaque propriété). L'annotation donne la vérification mais élargit tout vers le type déclaré. Le as garde la forme mais ne vérifie rien et peut mentir. On est coincé entre sûreté-sans-précision et précision-sans-sûreté — jusqu'à satisfies, épaulé d'un as const quand on veut aussi figer les littéraux.For a value you write yourself — a config object, a palette, a route table — you want two things: that it respects an expected shape, and that you keep the precise type TypeScript infers (the exact keys, each property's narrow type). The annotation gives the check but widens everything to the declared type. The as keeps the shape but checks nothing and can lie. You're stuck between safety-without-precision and precision-without-safety — until satisfies, backed by as const when you also want the literals frozen.

// annotation : vérifie, mais ÉLARGIT — clés exactes et littéraux perdus
const routes: Record<string, string> = { home: "/", admin: "/admin" };
routes.home;   // string (pas "/") — précision perdue
routes.typo;   // string — aucune erreur sur une clé inventée !

// as : garde la forme voulue, mais NE VÉRIFIE PAS
const r2 = { home: "/" } as Record<"home" | "admin", string>;  // admin manque — passe quand même

// as const (Vol 4.3) fige les littéraux ; satisfies vérifie la forme
const routes = { home: "/", admin: "/admin" } as const satisfies Record<string, string>;

routes.home;   // "/"  — littéral conservé (par as const)
routes.typo;   // ✗ 'typo' n'existe pas — satisfies a gardé les clés exactes
// et une clé manquante, ou { admin: 42 }, serait refusée : la conformité EST vérifiée

Ils se ressemblent — mais as force, et satisfies vérifie.They look alike — but as forces, and satisfies checks.

Les deux se posent après une valeur, suivis d'un type — on les croit interchangeables. Ils sont opposés. as est une assertion : il déclare un type sans le vérifier, et si l'on s'est trompé, le bug revient au runtime (Vol 4.3). satisfies est un contrôle : il exige que la valeur soit assignable au type, refuse sinon, et — c'est là le cadeau — laisse intact le type précis que TypeScript a inféré. Même syntaxe de surface, sécurité inverse.Both sit after a value, followed by a type — you think them interchangeable. They're opposites. as is an assertion: it declares a type without checking it, and if you got it wrong, the bug returns at runtime (Vol 4.3). satisfies is a check: it requires the value to be assignable to the type, refuses otherwise, and — here's the gift — leaves intact the precise type TypeScript inferred. Same surface syntax, opposite safety.

const config = {
  host: "localhost",     // ✗ port oublié…
} as { host: string; port: number };   // …mais 'as' FORCE le type — aucune erreur

config.port.toFixed();   // 💥 port est undefined : as a menti, crash au runtime

as dit au compilateur « c'est un { host: string; port: number } », et il le croit — alors que port n'existe pas. Aucune erreur, le mensonge passe, et .toFixed() explose à l'exécution. C'est l'assertion du Vol 4 : forcer, pas prouver. (as ne refuse que l'absurde flagrant — un string vers un number déclenche TS2352 ; tout ce qui pourrait coller, comme une propriété manquante, passe.)as tells the compiler "this is a { host: string; port: number }", and it believes it — even though port doesn't exist. No error, the lie passes, and .toFixed() blows up at runtime. It's the Vol 4 assertion: force, don't prove. (as only refuses the blatantly absurd — a string to a number triggers TS2352; anything that could fit, like a missing property, goes through.)

Trois outils, une valeur : seul satisfies vérifie et rend le type de la valeur.Three tools, one value: only satisfies checks and returns the value's type.

La mécanique tient à une question : que devient le type de l'expression ? L'annotation et le as donnent tous deux le type déclaré T — l'un en vérifiant, l'autre en forçant. satisfies fait autrement : il vérifie l'assignabilité de la valeur à T, puis donne à l'expression le type de la valeur elle-même, pas T. C'est un contrôle qui rend son entrée inchangée. D'où la conservation des clés exactes et du type fin de chaque propriété : la valeur n'a jamais été remplacée par T. Les littéraux, eux, s'élargissent comme dans toute inférence — c'est as const qui les fige, pas satisfies.The mechanic comes down to one question: what does the expression's type become? Both annotation and as give the declared type T — one by checking, the other by forcing. satisfies does otherwise: it checks the value's assignability to T, then gives the expression the value's own type, not T. It's a check that returns its input unchanged. Hence the preservation of exact keys and each property's narrow type: the value was never replaced by T. Literals, though, widen as in any inference — as const freezes them, not satisfies.

const v = { home: "/", admin: "/admin" };

const a: Record<string, string> = v;          // annotation → type : Record<string,string>
const b = v as Record<string, string>;         // assertion  → type : Record<string,string>
const c = v satisfies Record<string, string>;  // satisfies  → type : { home: string; admin: string }
//                                                 ↑ seul satisfies garde les clés exactes : c.typo ✗

// La règle, en une phrase :
//   satisfies VÉRIFIE que v est assignable à T (sinon : erreur),
//   puis donne à l'expression le type de v — PAS celui de T.
//
//   annotation : v assignable à T ?  →  type = T        (élargi)
//   as         : (aucune vérif)      →  type = T        (forcé)
//   satisfies  : v assignable à T ?  →  type = typeof v  (préservé)

Le as mis pour « faire respecter » une forme — là où satisfies la vérifie vraiment.The as used to "enforce" a shape — where satisfies actually checks it.

Le contre-exemple obligatoire : poser un as sur un objet qu'on écrit, en croyant lui « imposer » une forme. Mais as n'impose rien — il affirme, sans vérifier, et laisse passer une valeur du mauvais type. C'est exactement l'emploi que satisfies remplace : on voulait contrôler, on a forcé. Deux nuances closent le sujet : satisfies n'est pas toujours le bon choix, et il ne touche jamais aux données du dehors.The mandatory counter-example: putting an as on an object you write, thinking you 'impose' a shape on it. But as imposes nothing — it asserts, without checking, and lets a wrong-typed value through. It's exactly the use satisfies replaces: you meant to check, you forced. Two nuances close the topic: satisfies isn't always the right choice, and it never touches outside data.

// "Forcer" la conformité d'un objet de thème avec as :
type Theme = Record<"primary" | "spacing", string | number>;
const theme = {
  primary: "#0a0a0a",
} as Theme;   // ✗ spacing oublié — mais as ne dit rien

theme.spacing.toString();   // 💥 undefined.toString : as a forcé un mensonge

On a posé as pour « garantir » que le thème a ses deux clés — mais spacing manque, et as n'a rien vu. « Imposer » avec as est une illusion : il déclare, il ne contrôle pas. Le crash attend .toString().You put as to "guarantee" the theme has both its keys — but spacing is missing, and as saw nothing. "Enforcing" with as is an illusion: it declares, it doesn't check. The crash waits at .toString().