Collez un tsconfig et voyez quelles vérifications sont réellement actives. strict active neuf options et en laisse huit autres éteintes, chacune illustrée par le code qu’elle laisse passer. Rien n’est envoyé.

Votre tsconfig, ou seulement le bloc compilerOptions

Essayez :

strict: true
Vérifications couvertes par strict: 8 / 9
Vérifications qu’il ne couvre pas: 0 / 8

Désactivées à la main

Elles sont écrites à false dans votre configuration, et l’explicite l’emporte sur strict. Le compilateur ne signalera pas que vous avez demandé les deux.

noImplicitAny

Ce que strict active

Exactement ces neuf-là, lues dans le compilateur et non dans un article. Les définir vous-même est redondant, sauf pour en désactiver une.

noImplicitAnydésactivée · définie dans votre configuration
strictNullChecksactivée · par strict
strictFunctionTypesactivée · par strict
strictBindCallApplyactivée · par strict
strictPropertyInitializationactivée · par strict
strictBuiltinIteratorReturnactivée · par strict
noImplicitThisactivée · par strict
useUnknownInCatchVariablesactivée · par strict
alwaysStrictactivée · par strict

Ce que strict laisse de côté

Chacune de ces options attrape quelque chose que strict accepte. Chaque ligne montre un programme qui compile proprement avec strict et échoue dès que l’option est activée.

noUncheckedIndexedAccessdésactivée · non demandée
strict accepte ceci · cette option le rejette avec l’erreur TS2322
```
const xs: string[] = []
const first: string = xs[0]
export { first }
```
exactOptionalPropertyTypesdésactivée · non demandée
strict accepte ceci · cette option le rejette avec l’erreur TS2375
```
type User = { nickname?: string }
const u: User = { nickname: undefined }
export { u }
```
noImplicitOverridedésactivée · non demandée
strict accepte ceci · cette option le rejette avec l’erreur TS4114
```
class Base { save() {} }
class Row extends Base { save() {} }
export { Row }
```
noPropertyAccessFromIndexSignaturedésactivée · non demandée
strict accepte ceci · cette option le rejette avec l’erreur TS4111
```
type Env = { [key: string]: string }
declare const env: Env
export const url = env.DATABASE_URL
```

noFallthroughCasesInSwitchdésactivée · non demandée

strict accepte ceci · cette option le rejette avec l’erreur TS7029

export function rank(n: number) {
  switch (n) {
    case 1:
      console.log("one")
    case 2:
      return 2
  }
  return 0
}

noImplicitReturnsdésactivée · non demandée
strict accepte ceci · cette option le rejette avec l’erreur TS7030
```
export function sign(n: number) {
  if (n > 0) {
    return "positive"
  }
}
```
noUnusedLocalsdésactivée · non demandée
strict accepte ceci · cette option le rejette avec l’erreur TS6133
```
export function total(n: number) {
  const unused = n * 2
  return n
}
```
noUnusedParametersdésactivée · non demandée
strict accepte ceci · cette option le rejette avec l’erreur TS6133
```
export function greet(name: string, title: string) {
  return name
}
```

TypeScript 5.9.3

Lu dans le compilateur TypeScript avec lequel ce site est construit : la liste suit donc le compilateur, et non l’inverse.

Aussi disponible en : English · Español · Português · العربية

Ce que le mode strict de TypeScript active vraiment

Les neuf options que couvre strict, les huit qu’il ne couvre pas, et le code que chacune laisse passer — vérifié en compilant, pas en citant.

Que fait strict: true ?

Mettre strict à true dans le tsconfig est un raccourci : cela active un groupe fixe d’options distinctes du compilateur, ce n’est pas une vérification en soi. Dans TypeScript 5.9 ce groupe compte exactement neuf membres — noImplicitAny, strictNullChecks, strictFunctionTypes, strictBindCallApply, strictPropertyInitialization, strictBuiltinIteratorReturn, noImplicitThis, useUnknownInCatchVariables et alwaysStrict.

Mieux vaut lire cette liste dans le compilateur que dans un article, car elle s’allonge. strictBuiltinIteratorReturn est arrivée avec TypeScript 5.6 et la plupart des textes décrivent encore strict comme sept ou huit options. Cette page tire la liste des déclarations d’options du compilateur lui-même : elle suit donc TypeScript, et non l’inverse.

L’essentiel est ce qui n’est pas dans le groupe. TypeScript compte huit autres options qui attrapent de vraies erreurs et auxquelles strict ne touche pas — dont noUncheckedIndexedAccess, exactOptionalPropertyTypes et noImplicitOverride. Un projet avec strict activé n’est pas un projet avec toutes les vérifications activées, et l’écart est plus grand qu’on ne l’imagine.

Comment s’en servir

Collez votre tsconfig, ou seulement le bloc compilerOptions. Les commentaires et les virgules finales ne posent pas de problème : un tsconfig est du JSONC, pas du JSON, et la lecture se fait comme le fait tsc. Le fichier entier ou un simple objet d’options conviennent.
Lisez les deux compteurs. Combien des neuf options couvertes par strict sont actives, et combien des huit qu’il ne couvre pas. Ce que vous avez désactivé à la main figure à part, car l’explicite l’emporte sur strict et rien ne vous prévient.
Regardez les exemples de code sous les huit. Chacun est un programme qui compile proprement avec strict et échoue dès que l’option est ajoutée. Le bouton copie la configuration la plus stricte si vous voulez les dix-sept.

Les huit vérifications que strict laisse de côté

Chaque option de cette seconde liste est accompagnée d’un programme qui démontre l’écart, et chacun de ces programmes a été compilé deux fois lors de la construction de cette page : une fois sous strict, où il ne doit produire aucune erreur, et une fois l’option ajoutée, où il doit échouer. Un exemple n’apparaît que parce que le compilateur a donné les deux résultats : l’affirmation est une mesure, pas une opinion.

La première que l’on rencontre est noUncheckedIndexedAccess. Sous strict, lire xs[0] dans un tableau de chaînes renvoie une chaîne, alors même que le tableau peut être vide et la valeur undefined — l’indexation ment purement et simplement. En activant l’option, le type devient string | undefined et le compilateur commence à réclamer une vérification. C’est la première source de undefined à l’exécution dans des bases de code par ailleurs strictes.

exactOptionalPropertyTypes est la plus subtile. Avec un type { nickname?: string }, strict accepte sans broncher { nickname: undefined } : la différence entre une propriété absente et une propriété présente valant undefined disparaît, ce qui compte énormément si cet objet part en sérialisation ou se déverse sur une ligne de base de données. noImplicitOverride repère la méthode d’une sous-classe qui masque par accident celle du parent, façon dont un renommage cesse silencieusement d’appeler ce que vous croyiez. noPropertyAccessFromIndexSignature ramène env.DATABASE_URL à env["DATABASE_URL"], si bien qu’une faute de frappe dans un nom de variable d’environnement cesse de passer pour une chaîne.

Les quatre restantes relèvent moins des types que du code mort ou inatteignable : un case de switch qui déborde sur le suivant, une fonction qui renvoie une valeur sur un chemin et rien sur un autre, et des variables locales ou des paramètres que personne ne lit.

Limites assumées

L’explicite l’emporte sur strict, dans les deux sens, et c’est la partie qui mord en silence. Écrire strict à true à côté de noImplicitAny à false fait bel et bien taire les erreurs d’any implicite : le compilateur accepte la combinaison sans un mot, et une configuration héritée d’un vieux projet peut traîner un tel trou pendant des années. Cette page les liste à part, et tsc --showConfig le confirmera si vous voulez un second avis.

Elle ne suit pas extends. Un tsconfig qui hérite d’un fichier de base — le préréglage d’un framework, un paquet partagé — ne raconte que la moitié de l’histoire, et cette page lit ce que vous collez plutôt que de résoudre la chaîne. Lancez tsc --showConfig dans le projet pour obtenir le résultat résolu, puis collez-le ici.

La liste est liée à une version de TypeScript, affichée à côté du bouton de copie. Des options s’ajoutent : si votre compilateur est plus récent que celui de cette page, il peut en connaître une qui n’y figure pas. C’est pourquoi la liste est générée depuis le compilateur au lieu d’être saisie à la main, et pourquoi la version est écrite plutôt que sous-entendue.

Enfin, tout activer n’est pas automatiquement la bonne réponse. noUnusedLocals en particulier se dispute avec le travail en cours, et plusieurs équipes la gardent dans l’éditeur plutôt que dans la compilation. La page vous montre où vous en êtes et ce que coûte chaque option ; elle ne prétend pas que la réponse soit toujours oui.

Pourquoi est-ce gratuit ?

Tout se passe dans votre navigateur. Un tsconfig peut nommer des chemins internes, des registres de paquets et la structure du projet, et rien de cela n’est envoyé où que ce soit : le fichier ne quitte pas l’onglet.

Il n’y a aucun coût serveur à récupérer, donc pas de compte, pas de limite et pas de filigrane.