Meilleures extensions VScode pour TypeScript pour assister le développeur TS avec vérification d'erreur, formateur de code, et thèmes colorés

Les meilleures extensions VS Code pour développer en TypeScript !

Vous débutez avec TypeScript et cherchez un environnement de développement à la fois simple et performant ? Alors Visual Studio Code (VScode, pour les intimes) est fait pour vous ! D'autant plus qu'avec lui, vous aurez accès à tout un tas d'extensions complémentaires également gratuites, qui vous permettront de transformer VS Code en une véritable machine de guerre TypeScript 😉

Du coup, dans cet article, je vous propose de passer en revue plusieurs extensions VS Code de base, incontournables, et essentielles pour bien développer en TypeScript (comme ESLint, Prettier, VSCode-Icons, et autre). Ainsi, vous verrez comment elles pourront vous aider à développer du code TS, pour une meilleure productivité et qualité de codage ! Ça vous dit ? Alors en avant !

Remarque : je complèterai cette liste d'extensions dans le temps. Là, je vous mets juste les "principales", pour commencer ! Au passage, n'hésitez pas à partager les vôtres en zone commentaire, au bas de cet article. Merci !

Salut ! Bienvenue sur LeCoinTS, où je partage des tutos TypeScript gratuits et sans pub. Envie de me soutenir dans cette aventure, avec un café ? ☕

Offrez moi un café LeCoinTS

Pourquoi installer des extensions VScode, lorsqu'on développe en TypeScript ?

En fait, nativement, VScode est un simple éditeur de code. C'est d'ailleurs sa simplicité d'usage qui en partie a fait sa popularité ! Mais il y a toujours moyen de faire mieux, surtout du côté "assistance au programmeur", avec des détecteurs d'erreurs et de syntaxes, des outils de formatage automatique, des aides visuelles. Et ça, c'est le genre de services que les extensions VS Code peuvent nous rendre !

En fait, pour nous, développeur TypeScript, l'idéal serait d'avoir un éditeur qui sache :

  • interpréter tous les types TS que nous allons spécifier (qu'on ne retrouve pas sur du simple JavaScript, donc)
  • vérifier les erreurs de typage (mélange de types, types manquants, etc)
  • détecter les éventuelles incohérences dans notre code (comme le fait d'attendre quelque chose en retour d'une fonction, et ne jamais rien retourner !)
  • faire du formatage automatique, adapté à TypeScript
  • et nous aider visuellement dans le code, pour rapidement corriger toute erreur qui se serait glissée !

Du coup, pourquoi installer des extensions VS Code lorsqu'on développe en TypeScript ? Eh bien pour "enrichir" VScode, de telle manière qu'il soit totalement adapté au développement TypeScript ! Ainsi, on va gagner en temps de développement et en confort de programmation, et ainsi, réduire nos erreurs de codage. D'ailleurs, que vous soyez débutant ou pro, ces types d'outils (VSCode + ses extensions) sont incontournables ! Alors autant en profiter au maximum, surtout que c'est totalement gratuit 🙂

À présent, je vous propose d'entrer dans le vif du sujet, et donc de voir plusieurs extensions VScode populaires et incontournables, pour nous, développeurs TS (nota : pour rappel, je complèterai cette liste dans le temps, si d'autres idées d'extensions me viennent à l'esprit !).

Remarque : pour la suite de l'article, je vais partir du principe que vous savez utiliser Visual Studio Code, et savez comment installer une extension dessus, avec l'icône de la barre de menu, côté gauche (raccourcis clavier, sur Windows : Ctrl + Shift + X). Si ce n'est pas le cas, je vous glisse ci-dessous un aperçu de mon écran VScode, pour que vous voyez quelques extensions de bases installées !

Aperçu menu extensions VScode pour TypeScript, avec ESlint, Prettier, vscode-icons, et plus encore pour optimiser et améliorer son développement TS

Extension VScode #1 : TypeScript (base)

Comme le nom de cette extension l'indique, c'est fait pour nous, développeurs TypeScript ! Mais ici, en fait, il n'y a rien à faire ! Car de base, cette extension est installée par défaut avec VS Code (on peut même dire qu'elle est intégrée à VScode, maintenant !).

Au passage, cette extension (basée sur le moteur TypeScript) active IntelliSense (l'aide à la saisie semi-automatique du code), l'auto-complétion, et les diagnostics d’erreurs pour TS. Pour être plus clair, en pratique, cette extension permet de repérer les erreurs de typage en temps réel, et suggère des corrections. Sympa, non ?

Remarque : pour ceux qui veulent tester les nouveautés typescript, vous pouvez installer l'extension "JavaScript and TypeScript Nightly". Mais cela s'adresse plus aux utilisateurs avancés qui souhaitent tester les dernières fonctionnalités de TypeScript avant leur sortie, plutôt qu'aux débutants ! Du coup, mon conseil si vous débutez : évitez tout ce qui est nouveautés pour l'instant, d'autant plus que la prise en charge de celles-ci par les navigateurs n'est pas garantie !

Extension VScode #2 : ESLint (détection d'erreurs et problèmes de syntaxe)

Peut-être avez-vous déjà entendu parler du terme "linter". En fait, un linter est un outil d'analyse de code, permettant de détecter les erreurs et les problèmes syntaxiques. Au final, il permet donc de vérifier la qualité et la cohérence de notre code !

Et le plus populaire, selon moi, reste ESLint ! Du coup, c'est lui que je vous propose d'installer dans VScode. Pour cela, il suffira de taper "eslint" dans le champ de recherche des extensions (cf. image ci-dessus), puis de sélectionner ESLint et de cliquer sur "Install", pour qu'il s'intègre dans l'environnement VScode.

Une fois fait, il faudra ouvrir le terminal VS Code à la racine de votre projet, et taper eslint --init dedans, pour créer une configuration par défaut pour le linter. Attention : vous aurez toute une série de questions importantes concernant votre projet qui vous sera posée par ESLint, alors prenez bien le temps de lire les choses, afin de faire les bons choix.

Pour info, voici la liste des questions (Q) et réponses (R) possibles que pose eslint, au moment où j'ai rédigé cet article (nota : à titre d'exemple, je vais vous noter les choix que j'ai fait de mon côté, en sachant que varie d'un projet à l'autre, attention). Comme c'est écrit en anglais, je vous l'ai mis tel quel ; en sachant que la traduction française n'est pas bien compliquée à faire ici 😉

  • Q: How would you like to use ESLint ?
    • R: To check syntax only <--- mon choix
    • R: To check syntax and find problems
  • Q: What type of modules does your project use ?
    • R: JavaScript modules (import/export) <--- mon choix
    • R: CommonJS (require/exports)
    • R: None of these
  • Q: Which framework does your project use ?
    • R: React
    • R: Vue.js
    • R: None of these <--- mon choix
  • Q: Does your project use TypeScript ?
    • R: No
    • R: Yes <--- mon choix
  • Q: Where does your code run ?
    • R: Browser
    • R: Node <--- mon choix
  • Q: Would you like to install them now ? (il vous listera, à cette occasion, les packages qu'il prévoit d'installer)
    • R: No
    • R: Yes <--- mon choix
  • Q: Which package manager do you want to use ?
    • R: npm <--- mon choix
    • R: yarn
    • R: pnpm
    • R: bun

Une fois cette configuration achevée, un fichier eslint.config.mjs sera créé à la racine de votre projet, signifiant que la configuration d'ESlint est finalisée (cf. partie haute de l'image ci-dessous).

À présent, il ne vous reste plus qu'à fermer/réouvrir VScode, afin qu'il prenne cette nouvelle configuration en compte. Ainsi, voici ce que ça donne de mon côté, avec un exemple test montrant une variable initialisée, mais non utilisée ensuite (cf. partie basse de l'image ci-dessous) :

Fichier de configuration ESLint vscode autogénéré, avec exemple de code TypeScript montrant variable non utilisée générant une erreur par le linter

Voilà ! Vous êtes à présent au top pour programmer, avec le linter "ESLint" pour vous aider 😉

Juste une remarque, pour ceux qui veulent aller plus loin (ne prenez pas en compte ce qui suit, si vous voulez rester sur des choses simples, ou vous débutez !) : vous pouvez également ajouter le script suivant dans votre package.json : "lint": "eslint . --ext .ts", comme j'ai fait ici, de mon côté :

{
  "name": "lecoinsts",
  "version": "1.0.0",
  "main": "index.js",
  "scripts": {
    "lint": "eslint . --ext .ts"       <---------
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "description": "",
  "devDependencies": {
    "eslint": "^9.23.0",
    "globals": "^16.0.0",
    "typescript-eslint": "^8.28.0"
  }
}

Cela permet de rajouter une commande à npm, qui vous permettra de linter votre projet dans la console. Pour ce faire, il suffira d'exécuter la commande npm run lint. Ainsi, votre code sera "linté" dans votre terminal texte, en dehors de VS Code. Voici ce que ça donne, visuellement parlant :

ESlint dans terminal VS Code avec exemple test de variable non utilisée, erreur remontée par le linter au niveau de la constante créée et initialisée

À vous de choisir, au final, si vous souhaitez utiliser uniquement VScode pour linter vos fichiers, ou passer par les commandes en ligne ! Du reste, je vous ai seulement partagé les bases d'ESlint ici, afin de ne pas vous noyer d'informations. Mais sachez qu'il y aurait énormément de choses à voir et à dire sur le fichier de configuration ESLint (eslint.config.mjs), notamment au niveau des paramètres de type "rules" ! Mais bon, chaque chose en son temps 😉

Extension VScode #3 : Prettier (formateur de code)

Autre extension incontournable, et super utile : Prettier ! En fait, Prettier est un outil de formatage de code ; c'est à dire qu'il va proprement aligner (indenter) les éléments du code, mettre en forme le code (en mettant les sauts à la ligne qui vont bien etc), et appliquer des règles sur le code en lui-même (comme systématiquement mettre des doubles guillemets à la place des simples ou vice-versa, mettre des points virgules à chaque fin d'instruction ou pas, etc.). En clair, Prettier est un formateur de code automatique, qui imposera un style cohérent à vos programmes TypeScript (et JavaScript et tout et tout, bien entendu !).

Pour être plus parlant, avant de voir comment l'installer, voici un exemple de mise en forme qu'il est capable de faire :

// Avant Prettier
function saluer(nom:string){return "Salut "+nom}

// Après Prettier
function saluer(nom: string) {
  return "Salut " + nom;
}

En sachant que, encore une fois, les règles de formatage appliquées ici peuvent être modifiées, selon ses préférences, avec un fichier de configuration personnalisé ! Le but final de Prettier étant d'obtenir un code le plus lisible possible ! Alors voyons à présent comment l'installer, dans VSCode et sur son projet !

Vous aimez cet article ? LeCoinTS reste gratuit et sans pub grâce à vos dons.
Motivez-moi à en faire plus ! ☕

Offrez moi un café LeCoinTS

Installer Prettier dans VScode

À présent, voyons comment installer et paramétrer Prettier dans VS Code. Alors, comme souvent, cela se passe en deux ou trois étapes :

  • il faut tout d'abord installer l'extension Prettier dans VSCode
  • il faut ensuite installer Prettier dans votre projet, à l'aide de votre gestionnaire de package (npm, par exemple)
  • et il faut paramétrer VS Code pour qu'il utilise ce nouveau formateur de code

Alors commençons par la première étape : installer cette extension dans VS Code ! Pour cela, il suffit de faire comme d'habitude, à savoir : cliquer sur l'icône des extensions, taper le nom de l'extension que vous recherchez, puis la sélectionner une fois trouvée, et cliquer sur Install pour l'installer. En image, ça donne ça :

Installation Prettier VScode via extension sous Windows, pour le formatage automatique de code TypeScript ou Javascript automatiquement

Une fois fait, vous devrez ouvrir un terminal à la racine de votre projet, et taper la commande suivante dedans : npm install --save-dev prettier. Ainsi, Prettier sera également greffé à votre projet.

Enfin, il faudra aller dans les paramètres (settings) de VScode, en cliquant sur l'icône en forme d'engrenage en bas à gauche, dans la barre latérale (et cliquer sur le sous-menu "Paramètres" ou "Settings", selon si vous êtes en français ou en anglais). Une fois fait, il ne vous restera plus qu'à cliquer sur l'icône en haut à droite (en forme de fichier), afin d'ouvrir le fichier "settings.json" de VS Code. En image, le chemin à suivre donne cela :

Accès settings vscode depuis menu paramètres, avec icone pour ouvrir settings.json ensuite, afin de pouvoir accéder au détail de la configuration

Une fois le fichier settings.json ouvert (qui peut être vide de votre côté, ou déjà rempli), il faudra le modifier (ou ajouter des lignes, si absentes) selon vos besoins. Ici, concernant Prettier, voici les lignes que je vous recommande de mettre :

"editor.defaultFormatter": "esbenp.prettier-vscode",
"editor.formatOnSave": true,
"[javascript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[typescript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
}

Pour info, "editor.defaultFormatter" permet de dire à VS Code qu'il devra utiliser Prettier pour le formatage de vos fichiers, et "editor.formatOnSave" demande à VS Code de refaire un formatage document à chaque enregistrerment.

Nota : si votre fichier settings.json était vide, il faut mettre l'ensemble des lignes ci-dessus entre accolades { }.

Du reste, pensez à fermer puis réouvrir VS Code avant de passer à la suite, afin que tous ces changements soient bien pris en compte.

Configurer Prettier pour son projet en particulier

Avec ce que nous venons d'installer précédemment, Prettier fonctionne à merveille !

Mais Prettier fonctionne ici selon des règles générales, et peut-être voudrez-vous des comportements différents dans votre projet. Pour ce faire, il vous suffit de créer un fichier nommé .prettierrc, à la racine de votre projet. Dedans, vous pourrez par exemple mettre le code suivant :

{
  "printWidth": 150,
  "semi": false,
  "singleQuote": false,
  "tabWidth": 2,
  "trailingComma": "es5"
}

Avec ces lignes de paramètres spécifiques, vous direz à Prettier :

  • qu'un retour à la ligne soit fait, si une ligne fait plus de 150 caractères (printWidth=150)
  • que vous ne souhaitez pas de point virgule à la fin de chaque ligne de votre code (semi=false)
  • que vous ne voulez pas de guillemets simples (singleQuote=false), et donc, que vous voulez des guillemets doubles
  • que chaque tabulation fasse 2 espaces de large (tabWidth=2)
  • et que vous souhaitez qu'une virgule soit mise même sur le dernier élément d'une liste ou d'un objet, selon la norme ECMAScript 5 (trailingComma=es5)

Là encore, il faudra peut-être fermer puis rouvrir VSCode, afin que tous ces changements soient pris en compte.

Voilà ! Je ne vous détaille pas plus les choses ici, pour ne pas vous perdre ! À présent, passons à l'amélioration visuelle de votre explorateur de fichiers VS Code !

Extension VScode #4 : vscode-icons (coloration icônes fichiers/dossiers)

Encore une autre extension très utile : vscode-icons ! Ici, il s'agira d'appliquer un thème aux icônes de VS Code, afin de mieux repérer ses fichiers et dossiers particuliers, au niveau de l'explorateur de fichiers.

Pour que ce soit plus parlant pour vous, voici le style basique de VSCode (à gauche) versus le style plus coloré de "vscode-icons" (à droite) :

Application thème icônes VScode dans l'explorateur de fichiers et dossiers, affichage coloré agréable et efficace pour s'organiser

Alors, pour l'installer cette nouvelle extension, il suffit de cliquer sur l'icône "Extensions" (sur le menu flottant à gauche dans VScode), puis taper "vscode-icons" dans le champ de recherche, puis cliquer sur la ligne "vscode-icons" (la "bonne" extension, si plusieurs s'affichent à l'écran, est celle notée avec "VSCode Icons Team" dessous), et enfin, de cliquer sur Install.

Une fois l'installation achevée, il reste à appliquer ce nouveau thème VScode, à la place de l'ancien. Pour ce faire, il suffit de cliquer, dans VS Code, sur Fichier > Préférences > Thème > Thème d'icône de fichier ("File Icon Theme", en anglais) ; là, une liste déroulante s'ouvre en haut / au centre de VScode, avec plusieurs thèmes applicables. Ici, sélectionnez "vscode-icons", et le tour est joué !

Comme d'habitude : n'hésitez pas à fermer / réouvrir VS code, afin que les changements soient bien pris en compte 😉

Bonus : configurer "tsc" pour un TypeScript au top !

Pour tirer le meilleur parti de toutes les extensions vues précédemment, je vous conseille également de configurer le compilateur "tsc", c'est à dire l'outil qui nous permet de transformer nos fichiers sources .ts en fichiers exécutables .js.

Pour ce faire :

  • vérifiez tout d'abord que le compilateur TypeScript (nommé "tsc") est bien installé au niveau de votre projet, en tapant la commande suivante dans le terminal : npx tsc -v ; si jamais une erreur est remontée du fait que tsc n'est pas installé, alors tapez npm install typescript --save-dev, pour corriger cela
  • puis tapez npx tsc --init pour générer le fichier de configuration "tsconfig.json" de base

Maintenant, si vous ouvrez ce fichier tsconfig.json, vous verrez qu'il contient les choses suivantes (ou quelque chose du genre, suivant votre version !) :

{
  "compilerOptions": {
    /* Visit https://aka.ms/tsconfig to read more about this file */

    /* Projects */
    // "incremental": true,                              /* Save .tsbuildinfo files to allow for incremental compilation of projects. */
    // "composite": true,                                /* Enable constraints that allow a TypeScript project to be used with project references. */
    // "tsBuildInfoFile": "./.tsbuildinfo",              /* Specify the path to .tsbuildinfo incremental compilation file. */
    // "disableSourceOfProjectReferenceRedirect": true,  /* Disable preferring source files instead of declaration files when referencing composite projects. */
    // "disableSolutionSearching": true,                 /* Opt a project out of multi-project reference checking when editing. */
    // "disableReferencedProjectLoad": true,             /* Reduce the number of projects loaded automatically by TypeScript. */

    /* Language and Environment */
    "target": "es2016",                                  /* Set the JavaScript language version for emitted JavaScript and include compatible library declarations. */
    // "lib": [],                                        /* Specify a set of bundled library declaration files that describe the target runtime environment. */
    // "jsx": "preserve",                                /* Specify what JSX code is generated. */
    // "libReplacement": true,                           /* Enable lib replacement. */
    // "experimentalDecorators": true,                   /* Enable experimental support for legacy experimental decorators. */
    // "emitDecoratorMetadata": true,                    /* Emit design-type metadata for decorated declarations in source files. */
    // "jsxFactory": "",                                 /* Specify the JSX factory function used when targeting React JSX emit, e.g. 'React.createElement' or 'h'. */
    // "jsxFragmentFactory": "",                         /* Specify the JSX Fragment reference used for fragments when targeting React JSX emit e.g. 'React.Fragment' or 'Fragment'. */
    // "jsxImportSource": "",                            /* Specify module specifier used to import the JSX factory functions when using 'jsx: react-jsx*'. */
    // "reactNamespace": "",                             /* Specify the object invoked for 'createElement'. This only applies when targeting 'react' JSX emit. */
    // "noLib": true,                                    /* Disable including any library files, including the default lib.d.ts. */
    // "useDefineForClassFields": true,                  /* Emit ECMAScript-standard-compliant class fields. */
    // "moduleDetection": "auto",                        /* Control what method is used to detect module-format JS files. */

    /* Modules */
    "module": "commonjs",                                /* Specify what module code is generated. */
    // "rootDir": "./",                                  /* Specify the root folder within your source files. */
    // "moduleResolution": "node10",                     /* Specify how TypeScript looks up a file from a given module specifier. */
    // "baseUrl": "./",                                  /* Specify the base directory to resolve non-relative module names. */
    // "paths": {},                                      /* Specify a set of entries that re-map imports to additional lookup locations. */
    // "rootDirs": [],                                   /* Allow multiple folders to be treated as one when resolving modules. */
    // "typeRoots": [],                                  /* Specify multiple folders that act like './node_modules/@types'. */
    // "types": [],                                      /* Specify type package names to be included without being referenced in a source file. */
    // "allowUmdGlobalAccess": true,                     /* Allow accessing UMD globals from modules. */
    // "moduleSuffixes": [],                             /* List of file name suffixes to search when resolving a module. */
    // "allowImportingTsExtensions": true,               /* Allow imports to include TypeScript file extensions. Requires '--moduleResolution bundler' and either '--noEmit' or '--emitDeclarationOnly' to be set. */
    // "rewriteRelativeImportExtensions": true,          /* Rewrite '.ts', '.tsx', '.mts', and '.cts' file extensions in relative import paths to their JavaScript equivalent in output files. */
    // "resolvePackageJsonExports": true,                /* Use the package.json 'exports' field when resolving package imports. */
    // "resolvePackageJsonImports": true,                /* Use the package.json 'imports' field when resolving imports. */
    // "customConditions": [],                           /* Conditions to set in addition to the resolver-specific defaults when resolving imports. */
    // "noUncheckedSideEffectImports": true,             /* Check side effect imports. */
    // "resolveJsonModule": true,                        /* Enable importing .json files. */
    // "allowArbitraryExtensions": true,                 /* Enable importing files with any extension, provided a declaration file is present. */
    // "noResolve": true,                                /* Disallow 'import's, 'require's or '<reference>'s from expanding the number of files TypeScript should add to a project. */

    /* JavaScript Support */
    // "allowJs": true,                                  /* Allow JavaScript files to be a part of your program. Use the 'checkJS' option to get errors from these files. */
    // "checkJs": true,                                  /* Enable error reporting in type-checked JavaScript files. */
    // "maxNodeModuleJsDepth": 1,                        /* Specify the maximum folder depth used for checking JavaScript files from 'node_modules'. Only applicable with 'allowJs'. */

    /* Emit */
    // "declaration": true,                              /* Generate .d.ts files from TypeScript and JavaScript files in your project. */
    // "declarationMap": true,                           /* Create sourcemaps for d.ts files. */
    // "emitDeclarationOnly": true,                      /* Only output d.ts files and not JavaScript files. */
    // "sourceMap": true,                                /* Create source map files for emitted JavaScript files. */
    // "inlineSourceMap": true,                          /* Include sourcemap files inside the emitted JavaScript. */
    // "noEmit": true,                                   /* Disable emitting files from a compilation. */
    // "outFile": "./",                                  /* Specify a file that bundles all outputs into one JavaScript file. If 'declaration' is true, also designates a file that bundles all .d.ts output. */
    // "outDir": "./",                                   /* Specify an output folder for all emitted files. */
    // "removeComments": true,                           /* Disable emitting comments. */
    // "importHelpers": true,                            /* Allow importing helper functions from tslib once per project, instead of including them per-file. */
    // "downlevelIteration": true,                       /* Emit more compliant, but verbose and less performant JavaScript for iteration. */
    // "sourceRoot": "",                                 /* Specify the root path for debuggers to find the reference source code. */
    // "mapRoot": "",                                    /* Specify the location where debugger should locate map files instead of generated locations. */
    // "inlineSources": true,                            /* Include source code in the sourcemaps inside the emitted JavaScript. */
    // "emitBOM": true,                                  /* Emit a UTF-8 Byte Order Mark (BOM) in the beginning of output files. */
    // "newLine": "crlf",                                /* Set the newline character for emitting files. */
    // "stripInternal": true,                            /* Disable emitting declarations that have '@internal' in their JSDoc comments. */
    // "noEmitHelpers": true,                            /* Disable generating custom helper functions like '__extends' in compiled output. */
    // "noEmitOnError": true,                            /* Disable emitting files if any type checking errors are reported. */
    // "preserveConstEnums": true,                       /* Disable erasing 'const enum' declarations in generated code. */
    // "declarationDir": "./",                           /* Specify the output directory for generated declaration files. */

    /* Interop Constraints */
    // "isolatedModules": true,                          /* Ensure that each file can be safely transpiled without relying on other imports. */
    // "verbatimModuleSyntax": true,                     /* Do not transform or elide any imports or exports not marked as type-only, ensuring they are written in the output file's format based on the 'module' setting. */
    // "isolatedDeclarations": true,                     /* Require sufficient annotation on exports so other tools can trivially generate declaration files. */
    // "erasableSyntaxOnly": true,                       /* Do not allow runtime constructs that are not part of ECMAScript. */
    // "allowSyntheticDefaultImports": true,             /* Allow 'import x from y' when a module doesn't have a default export. */
    "esModuleInterop": true,                             /* Emit additional JavaScript to ease support for importing CommonJS modules. This enables 'allowSyntheticDefaultImports' for type compatibility. */
    // "preserveSymlinks": true,                         /* Disable resolving symlinks to their realpath. This correlates to the same flag in node. */
    "forceConsistentCasingInFileNames": true,            /* Ensure that casing is correct in imports. */

    /* Type Checking */
    "strict": true,                                      /* Enable all strict type-checking options. */
    // "noImplicitAny": true,                            /* Enable error reporting for expressions and declarations with an implied 'any' type. */
    // "strictNullChecks": true,                         /* When type checking, take into account 'null' and 'undefined'. */
    // "strictFunctionTypes": true,                      /* When assigning functions, check to ensure parameters and the return values are subtype-compatible. */
    // "strictBindCallApply": true,                      /* Check that the arguments for 'bind', 'call', and 'apply' methods match the original function. */
    // "strictPropertyInitialization": true,             /* Check for class properties that are declared but not set in the constructor. */
    // "strictBuiltinIteratorReturn": true,              /* Built-in iterators are instantiated with a 'TReturn' type of 'undefined' instead of 'any'. */
    // "noImplicitThis": true,                           /* Enable error reporting when 'this' is given the type 'any'. */
    // "useUnknownInCatchVariables": true,               /* Default catch clause variables as 'unknown' instead of 'any'. */
    // "alwaysStrict": true,                             /* Ensure 'use strict' is always emitted. */
    // "noUnusedLocals": true,                           /* Enable error reporting when local variables aren't read. */
    // "noUnusedParameters": true,                       /* Raise an error when a function parameter isn't read. */
    // "exactOptionalPropertyTypes": true,               /* Interpret optional property types as written, rather than adding 'undefined'. */
    // "noImplicitReturns": true,                        /* Enable error reporting for codepaths that do not explicitly return in a function. */
    // "noFallthroughCasesInSwitch": true,               /* Enable error reporting for fallthrough cases in switch statements. */
    // "noUncheckedIndexedAccess": true,                 /* Add 'undefined' to a type when accessed using an index. */
    // "noImplicitOverride": true,                       /* Ensure overriding members in derived classes are marked with an override modifier. */
    // "noPropertyAccessFromIndexSignature": true,       /* Enforces using indexed accessors for keys declared using an indexed type. */
    // "allowUnusedLabels": true,                        /* Disable error reporting for unused labels. */
    // "allowUnreachableCode": true,                     /* Disable error reporting for unreachable code. */

    /* Completeness */
    // "skipDefaultLibCheck": true,                      /* Skip type checking .d.ts files that are included with TypeScript. */
    "skipLibCheck": true                                 /* Skip type checking all .d.ts files. */
  }
}

En fait, vous avez là un aperçu de l'ensemble des paramètres TSC que vous pouvez personnaliser. Et franchement, y'en a un paquet !

Bien sûr, vous pouvez supprimer les lignes commentées, si vous n'en n'avez pas besoin. Ainsi, vous vous retrouverez avec un fichier bien plus court, et bien plus parlant ! Pour vous illustrer cela, voici un exemple de config "tsconfig.json" que j'utilise dans un projet (en gardant à l'esprit que cela est propre à un de mes projets, et qu'il pourra être bien différent dans les vôtres) :

{
  "compilerOptions": {
    "target": "ESNext",
    "module": "ESNext",
    "outDir": "./dist",
    "strict": true,
    "esModuleInterop": true,
    "moduleResolution": "node"
  },
  "include": ["src"],
  "exclude": ["dist", "node_modules"],
  "tsc-alias": {
    "resolveFullPaths": true,
    "replacers": {
      "base-url": {
        "enabled": false
      }
    }
  }
}

Parmi les choses intéressantes qu'on peut voir ici, j'ai indiqué au compilateur que les fichiers .ts à compiler se trouve dans le répertoire src, et qu'il faudra qu'il enregistre les fichiers compilés (.js donc) dans un répertoire nommé dist.

Du reste, je ne vais pas m'étaler plus que ça au sujet du fichier tsconfig.json, car il y aurait de quoi en faire tout un article ! En tout cas, n'hésitez pas à creuser/personnaliser ce fichier de configuration si vous le souhaitez, afin qu'il soit le plus possible adapté à votre projet !

Conclusion

Avec ces extensions (ESLint pour la qualité, Prettier pour le style, vscode-icons pour le visuel), VS Code deviendra votre meilleur allié pour coder en TypeScript ! Et surtout, cela vous permettra d'écrire du code proprement, rapidement, et sans stress 🙂

Voili voilou ! Il ne me reste plus qu'à vous dire "bon codage !", et à bientôt ! Et encore une fois, pour ceux qui voudraient me soutenir, n'hésitez pas à faire un petit don (chaque euro compte, pour financer ce site !).

Merci,
Jérôme.

Merci d’avoir lu cet article ! LeCoinTS reste gratuit et sans pub grâce à vous.
Un petit don pour soutenir le site ? ☕

Offrez moi un café LeCoinTS
Site LeCoinTS.fr

JEROME

Passionné par tout ce qui touche à la programmation informatique en TypeScript, sans toutefois en être expert, j'ai à coeur de vous partager ici, peu à peu, tout ce que j'ai appris, découvert, réalisé, et testé jusqu'à présent ! En espérant que tout cela puisse vous servir, ainsi qu'au plus grand nombre de francophones possible !

(*) Mis à jour le 14/04/2025

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Résolvez cette soustraction :

34 - ____ = 28

Soutenir LeCoinTS

×

Soutenez le site LeCoinTS en offrant un café symbolique, afin que celui-ci reste 100% gratuit et sans pub, et pour me motiver à faire d'autres articles !
1 café = 5 € environ
Plusieurs cafés = au top !!!

→ Via Logo PayPal
Soutenir avec PayPal
→ Via Logo Stripe
Soutenir avec Stripe
Merci à vous ❤️