En 2012 sort officiellement la version 0.8 de TypeScript, un langage open source porté par les équipes de Microsoft. TypeScript a depuis beaucoup évolué pour se faire une place non négligeable parmi les développeurs Web, mais pas que. Maintenant que TypeScript est supporté par node.js, il n’est pas rare de voir des projets backend développés sous ce langage.

Comme vous l’avez sans doute lu à beaucoup d’endroits, TypeScript est ce qu’on appel un surensemble (ou superset) de JavaScript, le langage le plus utilisé sur le Web aujourd’hui, et pour cause, c’est le seul utilisé par les navigateurs (hors HTML et CSS bien entendu). Cela indique que tout ce qui est écrit en JavaScript fonctionnera en TypeScript et que n’importe quelle bibliothèque ou librairie JavaScript (Angular, React, JQuery, …) sera utilisable avec TypeScript. Alors pourquoi s’embêter avec une surcouche ?

Qu’est-ce que TypeScript ?

Pour comprendre l’utilité de TypeScript, il faut déjà connaître les limitations de JavaScript et ce qui a amené les équipes de Microsoft à produire un composant comme TypeScript. JavaScript est avant tout un langage léger de script monothreading. Il est interprété par la version du moteur JavaScript présent dans le navigateur où il est exécuté. Il a été pensé en premier lieu pour ajouter des fonctionnalités multimédia à une page Web, de la validation de formulaire ou des animations. On est à ce moment là très loin d’un langage permettant de la POO (Programmation Orientée Objet), ici on travaille avec des objets et la seule notion d’héritage se fait via les prototypes. Le code devient alors très rapidement difficile à maintenir sur des projets de grande envergure. Des librairies comme JQuery ont permit de palier certains problèmes mais la gestion des bugs au runtime restait toujours compliquée à corriger. Il en va de même avec des framework comme Angular ou React.

Bien qu’une standardisation de JavaScript soit apparue avec l’ECMAScript pour limiter les écarts d’interprétation par les navigateurs, elle n’était pas immédiatement suivie par ceux-ci. C’est un peu moins vrai aujourd’hui avec une application plus régulière des standards surtout depuis que l’on peut produire du JavaScript côté serveur grâce à node.js. Mais un décalage subsiste. C’est là que TypeScript intervient.

TypeScript permet de produire un code orienté objet tel qu’on peut le rencontrer avec du code compilé comme Java ou C#. Un programmeur backend sera moins perdu par la permissivité de l’interprétation du JavaScript. Le typage statique du code va ainsi permettre d’éviter de nombreux bugs grâce à une intégration améliorée de TypeScript dans les IDE de développement comme par exemple avec Visual Studio Code, et surtout via la compilation du code. Enfin on devrait plutôt dire « transcompilation », car le code TypeSript produit finit par être transformé en JavaScript, les navigateurs n’ayant pas la capacité d’interpréter le TypeScript. Il est alors tout à fait possible d’utiliser les dernières avancés fournis par l’ECMAScript et de les transcompiler dans un format lisible par les anciens navigateurs, en l’occurrence l’ESCMAScript 5 ou ES5. Le compilateur de TypeScript se charge de fournir les librairies ou polyfill JavaScript permettant cette opération.

Comment fonctionne TypeScript ?

Ce qu’il faut bien comprendre c’est que TypeScript favorise le développement dans un environnement sécurisé et fortement typé, vous permettant d’attraper les bugs plus facilement avant de transcompiler le code vers JavaScript. Le code JavaScript fournit pour le runtime est donc à priori plus exposé aux bugs que votre code TypeScript, mais dans les faits, avec le code que vous avez produit via TypeScript, votre code JavaScript sera renforcé. De plus votre IDE vous indiquera les erreurs en amont de la transcompilation, et la transcompilation vérifiera l’exactitude du code produit.

Prenons l’exemple en TypeScript d’une classe qui retourne dans la console un Hello, World! :

interface IHelloWorld {
    write(name: string): void;
}

class HelloWorld implements IHelloWorld {
    constructor(private prefix = 'Hello') {}

    public write(name: string): void {
        console.log(this.build(name));
    }

    private build(name: string): string {
        return this.prefix + ', ' + name + '!';
    }
}

const callFn = (hw: IHelloWorld) => {
    hw.write('World');
};

callFn(new HelloWorld());

On décrit ici une interface IHelloWorld héritée par une classe HelloWorld qui attends une méthode write. Cette classe est ensuite instanciée via une méthode d’appelle callFn. On retrouve ici la structure classique d’une programmation orientée objet. Une fois le code transcompilé en ECMAScript 5 par le compilateur TypeScript, cela nous donne le code suivant :

"use strict";
 var HelloWorld = /** @class */ (function () {
     function HelloWorld(prefix) {
         if (prefix === void 0) { prefix = 'Hello'; }
         this.prefix = prefix;
     }
     HelloWorld.prototype.write = function (name) {
         console.log(this.build(name));
     };
     HelloWorld.prototype.build = function (name) {
         return this.prefix + ', ' + name + '!';
     };
     return HelloWorld;
 }());
 var callFn = function (hw) {
     hw.write('World');
 };
 callFn(new HelloWorld());

tsconfig.json

Le compilateur peut être paramétré via un fichier de configuration au format JSON nommé tsconfig.json. Vous pouvez ainsi indiquer sous quelle version de JavaScript vous souhaitez que le code soit transcompilé, activer des contrôles stricts supplémentaires et des linter, ou encore sélectionner quelle bibliothèque est utilisée pour la gestion des modules.

Exemple d’un fichier de configuration :

{
   "compilerOptions": {
     "target": "ES2015",
     "module": "commonjs",
     "strict": true,
     "esModuleInterop": true,
     "skipLibCheck": true,
     "forceConsistentCasingInFileNames": true
   },
   "$schema": "https://json.schemastore.org/tsconfig",
   "display": "Recommended"
 }

Vous pouvez retrouver l’ensemble des options disponibles depuis la documentation officielle de TypeScript.

Autre point intéressant, les équipes de Microsoft ont mis à disposition une page web permettant de compiler à la volée du code TypeScript en jouant sur les paramètres du fichier tsconfig.json. N’hésitez pas à tester le code HelloWorld ci-dessus et à modifier les options de configuration pour en voir les effets.

Le compilateur est-il fiable ?

Oui il l’est, Microsoft a fait un excellent travail, mais le compilateur peut facilement être dupé si le développeur n’écrit pas son code de la bonne manière. Prenons un exemple concret :

class Animal {}
class Dog extends Animal { legs: number = 4; }
class Cat extends Animal { wild: boolean = true; }

function addToCollection(animals: Animal[], animal: Animal) {
    animals.push(animal);
}

const dogs: Dog[] = [];
addToCollection(dogs, new Dog());
addToCollection(dogs, new Cat());
console.log(dogs);

Dans cet exemple, nous ajoutons un objet Cat dans une collection d’objets Dog. On pourrait penser que le compilateur de TypeScript nous alerte sur ce problème. Non seulement le code compile mais on se retrouve également avec un objet Cat dans notre collection. Ce n’est pas réellement une erreur de TypeScript mais la manière dont est perçu l’ajout, car dans les faits Dog et Cat héritent tout deux de la classe Animal et c’est bien une collection d’objets Animal qui est attendue par TypeSript. Si on souhaite explicitement que ce soit une collection d’un type spécifique il faut alors modifier la fonction addToCollection comme suit :

function addToCollection<T extends Animal>(animals: T[], animal: T) {
    animals.push(animal);
}

Cette fois, l’IDE devrait vous afficher une erreur de typage sur votre collection. Vous pouvez vous amuser à tester ce code sur la page TypeScript Playground pour voir de quelle manière réagit TypeScript.

Le développeur peut également abuser du type any pour omettre délibérément le type d’objet à transmettre dans une fonction mais cela va à l’encontre de la philosophie apporté par TypeScript. Heureusement cela peut aisément être contré en appliquant un paramètre de contrôle dans le fichier de configuration du compilateur et ainsi obliger le développeur à ne pas utiliser ce type.

Comment utiliser TypeScript ?

Pour démarrer un projet sous TypeScript, vous aurez besoin tout d’abord d’installer node.js. Je vous invite ensuite à regarder l’article suivant qui détaille tout le processus d’installation et d’utilisation du langage : Initialiser un projet Node.js sous TypeScript et ESLint

Conclusion

Pour un développeur provenant de l’univers BackEnd, TypeScript est l’outil idéal pour appréhender le développement FrontEnd, mais également pour les développements sous Node.js. Le développeur sera dans un environnement connu et sécurisé. Pour le développeur JavaScript, c’est l’occasion de tester un langage typé orienté objet. La transition sera plus compliquée car le développeur JavaScript n’a probablement pas l’habitude d’être encadré, mais pour des projets de grande envergure avec un nombre conséquent de dépendances, les outils fournis par TypeScript comme le typage statique, le compilateur, le débuggeur et la POO sont un vrai atout. Avec l’ajout de linter et de contrôles stricts, un projet sous TypeScript dispose d’une maintenance plus simple et d’un suivi de code plus pratique.

TypeScript n’est que l’avant goût de ce vers quoi tend JavaScript si ce n’est sont évolution futur prévu par le standard ECMAScript. Les plus grandes sociétés comme AWS rédigent leur code en TypeScript. Les framework FrontEnd comme Angular, React et Vue sont également développés et supportent TypeScript. Le nombre de projets poussé sur GitHub en TypeScript est en constante augmentation et l’intégration du langage est effective dans la plupart des IDE connues. La question n’est plus de savoir si vous devez utiliser TypeScript mais quand vous allez le faire.

Références


0 commentaire

Laisser un commentaire

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

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

Pourquoi utiliser TypeScript ?

par Cyrille P. temps de lecture : 7 min
0