Inside ECMAScript : ajout d’une étape supplémentaire au standard JavaScript

• Le comité TC39 a ajouté une nouvelle étape, « 2.7 », afin de rendre le processus de mise à jour de JavaScript plus rapide et plus fluide
• Contexte de cette évolution
  • Depuis ECMAScript 2015, JavaScript reçoit une nouvelle mise à jour chaque année
  • Le comité TC39 a consacré d’importants efforts au travail de normalisation pour faire évoluer le langage
  • Un processus en plusieurs étapes a été introduit pour garantir une conception, des tests et une implémentation rigoureux des nouvelles fonctionnalités

Processus par étapes pour la qualité et la compatibilité

• Stage 0 : exploration de nouvelles idées de fonctionnalités et définition des problèmes
• Stage 1 : il faut un dépôt et un « champion » expliquant l’utilité de la fonctionnalité, avec une description claire et les problèmes potentiels
• Stage 2 : première ébauche de conception de la spécification. Le comité s’attend à ce que cette fonctionnalité fasse partie du langage
• Stage 3 : proposition candidate, la fonctionnalité est presque terminée, mais une expérience concrète est nécessaire via une implémentation dans un navigateur ou un runtime côté serveur
• Stage 4 : tout le travail sur la spécification est terminé et elle est prête à être intégrée à la spécification complète du langage. Étape d’approbation finale

Les tests comme jalon explicite

• Dans le processus d’origine, il arrivait qu’il faille réécrire les tests une fois Stage 3 atteint
• Cela rendait le retour à Stage 2 particulièrement plus pénible que de revenir à Stage 3, notamment pour les grandes propositions quand la conception devait être modifiée
• La rédaction des tests demande une charge de travail importante, donc devoir la faire deux fois rendait le passage entre les étapes plus douloureux que prévu
• La nouvelle Stage 2.7 a été introduite pour séparer l’étape des tests de celle de l’implémentation

Exigences de Stage 2.7

• La proposition a été approuvée « en principe », mais doit encore être validée
• Rédiger les tests est l’un des meilleurs moyens de prendre en compte toutes les conséquences de la conception d’une fonctionnalité. Certaines fonctionnalités peuvent nécessiter l’écriture de tests avant même que leur conception soit finalisée
• Il faut développer une suite de tests complète et un prototype, et acquérir suffisamment d’expérience pour montrer que l’implémentation est possible
• Le texte de la spécification de la fonctionnalité est achevé, et le comité TC39 ne demande plus de changements en dehors de ceux qui découleraient des tests, de l’implémentation et de l’usage
• Stage 2.7 réduit les tâches redondantes inutiles et aide les propositions à passer directement à Stage 3
• Stage 3 concerne désormais l’acquisition d’une expérience d’implémentation et la découverte de problèmes de compatibilité web ou d’intégration

Application concrète de Stage 2.7

• Lors de l’ajout de Stage 2.7, le comité TC39 a examiné toutes les propositions déjà en Stage 3 ; certains projets n’avaient pas encore intégré tous les tests, mais étaient presque prêts et sont donc restés en Stage 3
• Plusieurs propositions, comme deferred import et la méthode Math.sumPrecise, ont déjà atteint Stage 2.7
• Regexp.escape, qui permet de prendre en charge les échappements de chaînes dans les expressions régulières, a atteint Stage 2.7 puis est passé en Stage 3 avec sa suite de tests
• En revanche, la proposition « microwaits » (désormais nommée atomics.pause), pour laquelle il est difficile d’écrire des tests utiles, a récemment été déplacée vers Stage 2.7 ; l’essentiel des discussions portait sur les indications à inclure dans la spécification pour l’implémentation