La mises à jour de valeurs précises calculées dans les tests unitaires
n'est pas une solution satisfaisante. Je le fait dans ce commit mais à
terme je pense qu'il faudra déléguer intégralité de ces tests sur des
valeurs précises aux tests de régressions `yarn run test-regressions`
qui peuvent être mis à jour facilement et conserver les tests unitaires
pour des cas où la valeur précise calculée n'importe pas.
Cela permet l'inférence de type à partir des fichiers js qui ne sont pas
encore convertis en TypeScript.
Par ailleurs suppression des dernières traces de Flow.
Ajout d'options plus strictes pour dans la config tsconfig.js
Gros changements en perspective :
- Supprime la notion de période, au bénéfice de celle d'unité
(`période : mensuelle` devient `unité: €/mois`)
- Améliore les rapports d'erreur avec des messages plus clair
- Ajoute un avertissement lorsque des types ne sont pas compatible
- Ajoute la conversion automatique d'unité dans le moteur
- Ajoute une notion d'unité par défaut de la simulation,
c'est l'unité vers laquelle les règles qui ne spécifient pas
d'unité seront converties
- Ajoute une notion d'unité par défaut des règles, qui spécifie
l'unité de la règle qui prévaut lorsque qu'il n'y a pas
d'unité par défaut de la simulation (utile pour les question ou
pour s'assurer du bon type d'une règle)
Outils
======
Ce commit retire le tooling de Flow, et ajoute le support de TypeScript
pour les fichiers .ts et .tsx. Il n'est pas nécessaire de tout migrer
d'un coup ce qui facilite la transition. On garde en effet le
compilateur Babel avec un preset TypeScript (ce qui permet donc de
retirer à la fois les types Flow et TypeScript) plutôt que d'utiliser le
compilateur standard pour la conversion du code. Cela permet aussi de
mieux s'intégrer avec d'autres outils, notamment les test-runners.
Ajout d'une nouvelle commande `yarn run type-check`, intégrée dans
CircleCI.
Par ailleurs ajout du support de l'opérateur ?? pour donner des valeurs
par défaut (nullish-coalescing-operator).
Typage des libraires tierces
============================
Les principales libraires que nous utilisons ont un typage TypeScript de
bon niveau, ce qui facilite l'intégration. J'ai mis à jour react-i18next
et i18next afin de corriger un problème de typage.
Typage du code
==============
Le typage est loin d'être complet dans ce commit, en particulier il
manque les types relatifs au state Redux, ainsi qu'au moteur (règle,
explication). Néanmoins le typage des contextes fonctionne, en
particulier sitePaths (avec un type récursif non trivial !) qui a déjà
permis de détecter un lien mort.
Le typage des "paths" (Components/, Règles/, etc.) fonctionne bien, y
compris avec l'auto-complétion automatique des import par Typescript.
TypeScript se révèle déjà bien agréable dans VSCode (auto-complétion,
refacto, etc.) ! Reste à migrer progressivement le reste du code !
* Définition à partir du nom complet en notation pointée (plutôt que
comme deux attributs indépendants "name" et "espace")
* Structure de données de premier niveau "dictionnaire" plutôt que liste,
s'aligne mieux avec notre contrainte d'unicité des noms
* Possibilité de définir les règles à partir d'une liste dans les tests,
dans ce cas il ne faut plus utiliser l'attribut "espace" mais renseigner
directement la notation pointée dans le "nom".
Supprime aussi redux-batched-action. Le code résultant est plus concis
(alors que l'on supprime une dépendance !), et plus clair car il y a moins
d'indirections pour se conformer aux API de redux-form.
Johan Girod
Maxime Quandalle
Marc Pasteur
Johan Girod
Mael