Migration Linear vers StyleX : navigation 30 % plus rapide
La migration Linear vers StyleX, qui a fait quitter styled-components aux applications React de l'entreprise en plus de 1 000 pull requests, s'est achevée début août 2026, a écrit l'ingénieur Kenneth Skovhus le 26 août 2026. Le travail a combiné un codemod déterministe, des agents de codage et une relecture humaine. Linear indique que les pages riches en vues effectuent désormais 20 % à 35 % de travail en moins sur le thread principal et que la navigation est environ 30 % plus rapide sur une machine de milieu de gamme : un produit plus rapide pour les clients, sans réécriture.
Pourquoi Linear a quitté styled-components
Linear avait deux problèmes avec son ancienne bibliothèque de styles : la vitesse et le contrôle. Le CSS-in-JS à l'exécution oblige le navigateur à générer des styles et à injecter des règles CSS pendant le rendu de l'application, et Linear en a nettement ressenti le coût après la mise à niveau vers le rendu concurrent de React 18, à l'époque où styled-components est passé en mode maintenance. Cody Olsen, de Sanity, a publié un fork optimisé qui a réduit de 40 pour cent les temps de rendu de Linear, mais il l'a qualifié de dernier recours.
Le second problème était l'encapsulation. Des schémas comme styled(Button) facilitaient la modification du style d'un composant depuis l'extérieur, et après une refonte, Linear s'est retrouvée à courir après une longue traîne de régressions d'interface. L'ingénieur Kenneth Skovhus a écrit que des frontières claires comptent d'autant plus que les agents de codage contribuent davantage au code.
Ce que Linear a choisi à la place et pourquoi
L'équipe a fixé des règles pour la prochaine bibliothèque : génération des styles à la compilation, stylisation à distance volontairement difficile, fusion prévisible entre fichiers, bon support de React et maintenance active. Elle a examiné la plupart des options de stylisation pour React. La plus proche, vanilla-extract, a été écartée pour son API fragmentée et ses fichiers de style séparés.
StyleX, la bibliothèque open source de CSS-in-JS atomique de Meta, l'a emporté. Elle déplace la génération des styles à la compilation, produit de petites classes atomiques sans collision et fait tourner Facebook, Instagram et WhatsApp sur le web. Elle garde les styles à côté des composants, a une API réduite et offre des contrats de style typés. Le prix à payer est la rigidité : les sélecteurs dépendant du parent, les sélecteurs globaux et la stylisation via des wrappers deviennent plus difficiles, et Linear a conservé les CSS Modules comme échappatoire pour les sélecteurs globaux.
Comment le codemod, les agents et les ingénieurs se sont réparti le travail
Le travail a commencé par un codemod déterministe plutôt que par des agents. Skovhus a construit styled-components-to-stylex-codemod sur une vaste suite de tests, avec l'aide d'agents pour l'étoffer ; il dispose d'un terrain de jeu en ligne et, selon InfoQ, dépasse désormais 500 pull requests et environ 100 000 lignes.
L'équipe a d'abord défini les variables StyleX et les primitives partagées, donné aux agents des périmètres étroits avec un lanceur de codemod, des exemples, des scripts de validation et une liste de contrôle, et migré les composants terminaux avant les composants partagés. Les agents restaient souvent bloqués sur la vérification des différences visuelles, comme les états de survol et les thèmes, ce qui a imposé beaucoup de tests manuels jusqu'au lancement de deux modèles plus récents, Fable et Sol, en cours de projet.
« Si nous commencions cette migration aujourd'hui, nous nous appuierions beaucoup plus sur Fable et Sol pour la réaliser directement. » Kenneth Skovhus, ingénieur chez Linear
Comment Linear a maintenu la migration en mouvement pendant des mois
Linear a poursuivi le travail produit pendant que les deux systèmes coexistaient, et s'est servie d'outils pour que les équipes continuent de migrer. Un compteur dans la barre d'outils des développeurs indiquait le nombre de styled-components de chaque page, un surligneur montrait quels composants étaient migrés, et un bot signalait les nouveaux styled-components dans les pull requests. Des règles Oxlint font désormais respecter les nouvelles conventions.
Le graphique d'avancement montre la courbe. Les fichiers styled-components représentaient 100 % des fichiers de style React la semaine du 8 mars 2026, 49 % au 7 juin et 0 % au 6 août. Les nouveaux fichiers styled-components sont passés d'un pic de 22 la semaine du 19 avril à zéro la plupart des semaines après le 31 mai.
Ce que la migration Linear vers StyleX a produit
Les résultats mesurés sont ceux de Linear. La migration a demandé plus de 1 000 pull requests et environ cinq mois, et s'est terminée début août 2026. Linear indique 20 % à 35 % de travail en moins sur le thread principal pour les pages riches en vues, une navigation environ 30 % plus rapide sur une machine de milieu de gamme, et aucune règle CSS injectée lors d'un changement de page.
Ce que cela dit aux entreprises qui ont de grandes applications web
Pour un éditeur de logiciels, la tâche est de remplacer une bibliothèque front-end centrale dans un code volumineux et actif, sans geler le travail produit. La réponse de Linear associe trois éléments : un codemod déterministe pour la masse répétitive, des agents aux périmètres étroits pour le reste, et des ingénieurs pour le jugement et les vérifications visuelles. Son propre avis est que les agents porteraient aujourd'hui une plus grande part du travail.
Le marché évolue dans le même sens. InfoQ rapporte que Cursor est passé de Tailwind à StyleX, et le podcast Syntax a conclu que la rigidité supplémentaire n'est pas très amusante pour les humains, mais que les agents s'y épanouissent.
Questions et réponses
Combien de temps la migration de Linear vers StyleX a-t-elle pris ?
Elle a pris environ cinq mois et plus de 1 000 pull requests. Linear a terminé début août 2026, et Skovhus a décrit le projet le 26 août 2026.
Pourquoi Linear a-t-elle choisi StyleX plutôt que vanilla-extract ?
Vanilla-extract offrait l'extraction statique et la sûreté de typage, mais Linear trouvait son API fragmentée et n'aimait pas les fichiers de style séparés. StyleX garde les styles à côté des composants et a une API plus réduite.
Les agents d'IA ont-ils fait la migration ?
En partie. Un codemod déterministe a fait l'essentiel du travail répétitif, les agents ont traité des tâches délimitées, et les ingénieurs ont géré les vérifications visuelles jusqu'à l'arrivée des modèles Fable et Sol en cours de projet.
Le regard de MOZGII
Comment nous le construirions
Ce cas est un bon modèle pour toute grande migration de code, car Linear n'a pas commencé par confier le travail à des agents. Elle a d'abord écrit un convertisseur à base de règles avec une grande suite de tests, utilisé des agents pour ce que le convertisseur ne savait pas traiter, et gardé des personnes sur ce que les machines font encore mal, comme juger si une page a le bon aspect. Nous suivrions le même ordre.
Si nous conduisions une migration de ce type, nous commencerions par la base commune : les design tokens et les composants de base que tout fichier converti doit utiliser. Le convertisseur traiterait les schémas courants et refuserait tout ce qu'il ne reconnaît pas, de sorte que les cas atypiques aillent à un agent ou à une personne au lieu d'être mal convertis. Les agents recevraient une petite tâche bien définie à la fois, avec des exemples et un script qui vérifie le résultat. Un compteur visible et un contrôle dans chaque pull request empêcheraient le retour du code à l'ancien style.
Il casserait sur les vérifications visuelles. Du code peut compiler et passer les tests alors qu'un état de survol ou un thème sombre est faux, et Linear a constaté que les agents peinaient justement là. Nous ajouterions des comparaisons de captures d'écran pour chaque composant converti et enverrions toute différence à une personne. L'indicateur que nous suivrions : la part des fichiers de style encore sur l'ancienne bibliothèque, semaine après semaine, à côté des nouveaux fichiers ajoutés dans l'ancien style.
Ensuite, nous ferions des règles de lint la norme du nouveau code, pour que la prochaine refonte parte sur une base propre.
Sources
D’où viennent les faits de cet article.