Utiliser Typescript

[mquandalle]

Roadmap migration :

• Tooling TypeScript #752
• utils (sitePaths, colours, etc.) TypeScript #752
• Redux-state Poursuite de la migration TypeScript #779
• Pages TypeScript #752
• Components Poursuite de la migration TypeScript #779
• fichiers yaml Typage du nom des règles #807
• Engine
• strict mode

---

L’écosystème d'outils autour de Typescript est maintenant vraiment mature et de nature à améliorer l’expérience de développement (refactoring, typage des libraire tierces, etc.) et de détecter des erreurs avec le typage statique.

La syntaxe étant très proche de celle de Flow, la migration ne devrait pas poser de problème majeur pour les types déjà existants. Par ailleurs, on peut configurer le tooling pour qu'une erreur de typage n'empêche pas la compilation mais se contente de sortir un warning dans la console et l'éditeur de texte (comme actuellement avec Flow) afin de ne pas ralentir le développement dans sa phase exploratoire. De plus l'inférence de type, et l'utilisation du type any facilite aussi la transition.

Je voulais proposer cette migration depuis un moment mais nous utilisions deux syntaxes incompatibles : les do expressions (que j'ai supprimées dans a1b99fd) et l'optional chaining ?. qui sera supporté dans Typescript 3.7 (et l'est déjà dans la beta).

Qu'en pensez-vous @johangirod @laem ?

[johangirod]

Plutôt d'accord. Je ne vois pas de futur amélioration ES@next qui nous soit absolument nécessaire (si l'optional chaining est supporté).

J'ai hâte d'avoir une meilleure intégration vscode et typage statique.

[mquandalle]

Concernant les améliorations ES@next, elles sont intégrées dans Typescript quand elles passent en stage-3 dans le process de standardisation du TC39. Certaines proposition comme le “pipeline-operator” pourraient être sympa à utiliser, mais il est quand même plus raisonnable d'attendre que la sémantique soit bien précisée et donc d'attendre que la feature passe en stage 3, plutôt que de fabriquer notre propose version du langage.

[mquandalle]

D'ailleurs avec l'optional chaining arrive aussi l'opérateur a ?? b qui permet de définir des valeurs par défaut. On utilise actuellement a || b mais ça peut poser problème pour les cas des chaînes vides ou du nombre 0 que l'on voudrait garder comme valeur et non remplacer par la valeur par défaut.

[mquandalle]

Le typage des modules JSON fonctionne bien en Typescript, ce qui nous serait utile par exemple pour avoir le contrôle des noms de règles et l'autocomplétion sur base.yaml, mais ça ne semble pas possible directement pour du yaml... Je me demande s'il faudrait persister un base.json sur le système de fichiers sans le commiter dans git et avoir une étape qui ré-écrit base.json à chaque fois que base.yaml change ?

https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-9.html#new---resolvejsonmodule