Vize
Prêt à la production
Vize est encore expérimental.
Ce n’est pas un avertissement derrière lequel se cacher. C’est une description de la phase actuelle.
L’objectif est de passer d’un projet expérimental à une chaîne d’outils prête à la production. La seule voie honnête est la validation réelle et les retours de la communauté.
Les applications jouets ne suffisent pas
De petits exemples sont utiles pour le développement.
Ils nous permettent d’isoler un comportement de règle, une transformation, une carte source, un seul comportement.
Mais les projets de production Vue ne sont pas de petits exemples. Ils contiennent :
Agencements inhabituels des ensembles
anciens et nouveaux modèles Vue ensemble
Aliases de chemin
Auto-importations
Macros
Préprocesseurs de style
Composants profondément imbriqués
Fichiers générés
Conventions-cadres
Comportement des plugins
Problèmes spécifiques à chaque plateforme
Une chaîne d’outils qui ne transmet que des exemples jouets n’est pas prête pour la production.
C’est un prototype avec une belle démo.
Les balayages exhaustifs comptent
Le travail ennuyeux compte le plus ici.
Vize doit parcourir les projets réels fichier par fichier, erreur par erreur, diagnostic par diagnostic, instantané par instantané.
Cela signifie vérifier :
Sortie de compilation
Sortie peluches
Sortie de contrôle de type
Stabilité de la formée
Emplacements sources
Résolution de chemin
Comportement dev-server
Comportement de construction en production
Différences entre Windows et Unix
Ce genre de travail exhaustif n’est pas glamour.
Mais c’est le travail qui transforme « ça fonctionne sur l’exemple » en « il survit dans un vrai dépôt ».
Les retours de la communauté sont l’élément principal
La communauté trouvera des cas que le mainteneur n’avait pas imaginés.
Ce n’est pas un échec. C’est justement le but.
Chaque rapport réel a de la valeur :
un projet qui ne compile pas
un faux positif qui rend une règle inutilisable
Un diagnostic techniquement correct mais peu utile
une falaise de performance dans CI
Une convention macro manquante
un problème de chemin uniquement Windows
une carte source qui déplace un jeton
Ces rapports ne sont pas des interruptions. Ce sont les données.
La bonne réponse est de les transformer en équipements, tests, instantanés et benchmarks.
Être prêt à la production est un comportement, pas une étiquette
« Prêt à la production » n’est pas quelque chose qu’un projet devient parce que le README le dit.
C’est un comportement qui s’écoule dans le temps :
Les requêtes de fixation deviennent des tests de régression
Les benchmarks couvrent de vrais flux de travail
Les notes de publication expliquent le risque
Les changements cassés sont intentionnels
L’IC représente les plateformes prises en charge
Les diagnostics restent suffisamment stables pour permettre l’automatisation
Les utilisateurs peuvent prédire ce que l’outil fera
C’est particulièrement important pour Vize car il aborde de nombreux niveaux. Un désaccord de compilateur, un faux positif inter, un défaut de vérification de type ou une carte source incorrecte peuvent tous nuire à la confiance de différentes manières.
La barre est élevée car la surface est élevée.
Pourquoi l’indépendance aide ici
Les outils officiels nécessitent un autre type de prudence.
Ils véhiculent immédiatement les attentes de l’écosystème. Ils ne peuvent pas expérimenter de manière trop agressive sans affecter une large base d’utilisateurs.
Vize est indépendant, ce qui lui donne une marge de manœuvre rapide :
Essaie les changements d’architecture
réécriture des composants internes
ajouter des diagnostics stricts
tester les backends alternatifs du compilateur
Supprimer les abstractions faibles
Goulots d’étranglement de performance de Chase
Apprenez à partir des rapports communautaires sans promettre une stabilité instantanée
Cette vitesse est utile, mais elle implique des responsabilités.
Le projet doit être clair sur son statut et être sérieux quant à la validation.
La feuille de route est en forme de rétroaction
La voie vers la préparation à la production ne se limite pas à une liste de fonctionnalités.
C’est une boucle de rétroaction :
Faites tourner Vize sur de vrais projets.
Enregistrez chaque défaillance comme test ou dispositif de fixation.
Corrigez le modèle sous-jacent, pas seulement le symptôme.
Comparez le comportement avec les outils officiels.
Gardez la performance visible.
Répétez jusqu’à ce que les cas surprenants deviennent ennuyeux.
C’est ainsi qu’une chaîne d’outils se développe.
Pas en faisant semblant d’avoir fini.
En laissant du code réel, de vrais utilisateurs et de réelles contraintes façonner le travail jusqu’à ce que le système devienne fiable.