

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# TypeScripten AL2 023
<a name="typescript"></a>

**Note**  
 Ce document fournit les informations essentielles sur son environnement d' TypeScript exécution basé sur Node.js. Il couvre également un flux de travail de développement typique et explique comment TypeScript il est intégré dans AL2 023 pour fournir un environnement de développement cohérent et reproductible. 

 [https://www.typescriptlang.org/](https://www.typescriptlang.org/)(TS) est un langage de programmation basé sur JavaScript (JS) qui offre toutes les fonctionnalités de JS et l'[étend également avec un système de types](https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html). Dans un scénario typique, les programmes écrits en TS sont d'abord traduits dans le code JS, puis exécutés comme n'importe quel autre programme JS normal parNode.js. Dans la terminologie spécifique de TS, ce processus de traduction est appelé [« compilation » et est effectué par un « compilateur »](https://www.typescriptlang.org/docs/handbook/typescript-tooling-in-5-minutes.html), appelé *tsc*. Le compilateur *tsc* lui-même est écrit en JS, donc pour fonctionner, il a également besoin d'un environnement d'exécution JS, tel queNode.js. Contrairement à d'autres environnements d'exécution JS, il ne dispose Node.js actuellement que d'un support TS expérimental et léger. Un support TS complet, y compris la vérification de type, nécessite toujours l'utilisation de packages tiers, tels que le [tapuscript](https://www.npmjs.com/package/typescript). La méthode attendue pour obtenir *tsc* (le compilateur TS) pour l'environnement Node.js d'exécution consiste à installer le module de nœud typescript. Cela peut être fait à l'aide de l'un des gestionnaires de packages, généralement *npm*. Il existe deux manières d'installer le compilateur TS à l'aide de *npm* : globalement et dans un projet. [La méthode officiellement recommandée consiste à installer](https://www.typescriptlang.org/download/) le compilateur TS par projet, ce qui garantit la cohérence et la reproductibilité à long terme des projets. Cependant, l'installation globale du compilateur TS peut toujours être utile, car il fournit la même version pour l'ensemble de l'hôte et son environnement d'exécution JS, et donc pour les projets sur lesquels aucun compilateur TS n'est installé localement. C'est précisément ainsi que les packages RPM disponibles sur Amazon Linux, tels que `nodejs20-typescript` ou `nodejs22-typescript` installent un compilateur TS : globalement au niveau du système, et séparément pour chaque Node.js version prise en charge. 

 Le *tsc* ne dépend directement d'aucune Node.js version. [Le compilateur attend un certain niveau de fonctionnalités d'exécution, qui sont définies dans un fichier spécial (*tsconfig.json*) via des options telles que [target](https://www.typescriptlang.org/tsconfig/#target) et lib.](https://www.typescriptlang.org/tsconfig/#lib) Les valeurs de ces options représentent une version de la norme [ECMAScript](https://en.wikipedia.org/wiki/ECMAScript_version_history)(ES), qui peut (ou non) être prise en charge par l'environnement d'exécution JS. Différentes versions Node.js prennent en charge différentes versions de la norme ES. Plus la version de est récenteNode.js, plus la version standard ES prise en charge est performante et complète. Si *tsconfig.json* n'existe pas dans le répertoire racine d'un projet, l'ensemble d'options de configuration par défaut sera utilisé. Le tableau de compatibilité avec les différentes versions Node.js et les fonctionnalités prises en charge par les différentes versions standard ES est disponible sur [node.green](https://node.green/). Le *tsc* comporte plus de 100 options différentes, qui peuvent être définies dans le *tsconfig.json*. Le chaînage de configuration est également pris en charge lorsque certaines options de configuration sont définies dans un autre fichier puis incluses dans le fichier principal. Cette approche permet d'installer une [base TS Config](https://github.com/tsconfig/bases) compatible avec une certaine version deNode.js, puis de l'étendre avec des options spécifiques au projet. Heureusement, les configurations de base TS pour Node.js sont disponibles sous forme de modules de nœuds qui peuvent être installés dans un dossier de projet à l'aide de *npm*. Voici le code source de la configuration pour les Node.js versions [18](https://github.com/tsconfig/bases/blob/main/bases/node18.json), [20](https://github.com/tsconfig/bases/blob/main/bases/node20.json) et [22](https://github.com/tsconfig/bases/blob/main/bases/node22.json). 

 La conception d'exécution Node.js basée sur un environnement d'exécution présente un certain point faible : elle ne prend en charge qu'une seule version de l'environnement d'exécution sur un hôte et exige la reproductibilité et la cohérence de toutes les dépendances au niveau du projet. Cela a conduit à l'approche commune suivante TypeScript : le compilateur TS, la configuration de base TS pour la Node.js version actuelle et toutes les dépendances logicielles sont installés localement, dans un projet. Bien que les modules de nœuds installés globalement soient censés être uniquement des outils CLI, tels que *npm*, *tsc*, qui est également un outil CLI, est rarement installé globalement. Heureusement, les installations globales (à l'échelle du système) et locales (au sein d'un projet) de *tsc* peuvent coexister sans problème et peuvent également être des versions différentes utilisées indépendamment. *Notez qu'un *tsc* installé localement doit être exécuté à l'aide de l'outil *npx*, qui est installé avec npm.* Ainsi, même avec un compilateur système TS, les utilisateurs ont la possibilité de choisir des versions des composants du moteur d'exécution, par exemple Node.js (en changeant la version active via des alternatives), un compilateur TS (en l'installant localement ou globalement et en changeant également la version active via des alternatives), et en le configurant pour les besoins spécifiques. 

 Amazon Linux empaquète un compilateur TS de la même manière que les autres modules de nœuds installés dans le monde entier, tels que *npm*, sur une base par Node.js version. Les packages et les fichiers binaires sont dotés d'un espace de noms et contiennent la version majeure de dans leur Node.js nom. Le nom exécutable par défaut du compilateur, *tsc*, est géré au moment de l'exécution par l'outil alternatives et indique la version actuellement active Node.js pour laquelle il a été installé et par laquelle il sera exécuté. Cette sélection ne dépend pas de la version Node.js d'exécution actuelle. Il est possible que l'exécutable *du nœud* pointe vers Node.js 20 et que *tsc* soit configuré pour être interprété par le Node.js 22. Il est également possible d'utiliser les noms avec espaces de noms d'un compilateur TS, par exemple *tsc- \$1MAJOR\$1VERSION\$1* indépendamment de ce pour quoi le nom *tsc* par défaut est configuré. 

**Quelques commandes utiles pour gérer la version active d'un compilateur TS**

1. Vérifiez quelles *alternatives* sont configurées pour

   ```
   alternatives --list
   ```

1. Vérifiez la *configuration actuelle de tsc*

   ```
   alternatives --display tsc
   ```

1. Modifier la version de manière interactive tsc

   ```
   alternatives --config tsc
   ```

1. Passez en mode manuel et sélectionnez une version spécifique

   ```
   alternatives --set tsc /usr/bin/tsc-{MAJOR_VERSION}
   ```

1. Revenir en mode de sélection automatique des versions

   ```
   alternatives --auto tsc
   ```

 Exemple d'installation et d'utilisation de plusieurs versions de Node et d'un compilateur TS sur le même système : 

```
# Check the AL2023 release
$ cat /etc/amazon-linux-release
Amazon Linux release 2023.9.20250929 (Amazon Linux)

# Install a TypeScript compiler for Node.js 20 and 22
# Node.js 20 and 22 will be installed automatically
$ sudo dnf install -qy nodejs20-typescript nodejs22-typescript

# Check what was installed
$ rpm -q nodejs20 nodejs20-typescript nodejs22 nodejs22-typescript
nodejs20-20.19.5-1.amzn2023.0.1.x86_64
nodejs20-typescript-5.9.2-1.amzn2023.0.1.noarch
nodejs22-22.19.0-1.amzn2023.0.1.x86_64
nodejs22-typescript-5.9.2-1.amzn2023.0.1.noarch

# Check the active version of Node.js - it is version 20
$ alternatives --display node
node - status is auto.
 link currently points to /usr/bin/node-20
/usr/bin/node-20 - priority 100
 slave npmrc: /usr/lib/nodejs20/lib/node_modules/npm/npmrc
 slave npm: /usr/bin/npm-20
 slave npx: /usr/bin/npx-20
 slave node_modules: /usr/lib/nodejs20/lib/node_modules
/usr/bin/node-22 - priority 100
 slave npmrc: /usr/lib/nodejs22/lib/node_modules/npm/npmrc
 slave npm: /usr/bin/npm-22
 slave npx: /usr/bin/npx-22
 slave node_modules: /usr/lib/nodejs22/lib/node_modules
Current 'best' version is /usr/bin/node-20.

# Check the active JS runtime version for TypeScript
# Currently, the tsc compiler will be executed by Node.js 22
$ alternatives --display tsc
tsc - status is auto.
 link currently points to /usr/bin/tsc-22
/usr/bin/tsc-22 - priority 100
 slave tsserver: /usr/bin/tsserver-22
/usr/bin/tsc-20 - priority 100
 slave tsserver: /usr/bin/tsserver-20
Current 'best' version is /usr/bin/tsc-22.

# Check versions printed by executables
$ node -v
v20.19.5

$ tsc -v
Version 5.9.2

# while the node is 20, tsc is executed by node 22 anyway
$ head -1 /usr/bin/tsc
#!/usr/bin/node-22

# However, instead of default executable names, e.g. node or tsc,
# we can use namespaced names to target any installed version
$ node-20 -v
v20.19.5

$ node-22 -v
v22.19.0

$ tsc-20 -v
Version 5.9.2

$ tsc-22 -v
Version 5.9.2

$ head -1 /usr/bin/tsc-20
#!/usr/bin/node-20

$ head -1 /usr/bin/tsc-22
#!/usr/bin/node-22
```