Builds rapides pour JavaScript Monorepos – La nouvelle pile

Alors que de nombreux magasins de logiciels semblent migrer vers les monorepos comme moyen de stocker du code, les outils de gestion de construction qu’ils utilisent – en particulier pour JavaScript/TypeScript – semblent être trop lents pour ces nouveaux environnements.

Mais il y a un inconvénient au monorepos. La commodité de stocker tout le code dans un seul référentiel est compensée par le temps de construction supplémentaire nécessaire pour parcourir ce code chaque fois qu’une nouvelle modification est ajoutée.

C’est le problème que le développeur Jared Palmer a rencontré lors de la création de sa propre application (un runtime TypeScript, TSDX). Il construisait ce projet dans un monorepo, où tout le code, y compris les dépendances, était situé dans un référentiel unique, et il voulait structurer TSDX afin qu’il puisse également être géré dans un monorepo. Lorsqu’il a exprimé ses frustrations en ligne, il a découvert que beaucoup d’autres ressentaient la même chose.

Il a donc créé Turborepo, un outil de construction monorepo open source qui, selon Palmer, pourrait augmenter les vitesses de construction d’environ 65% à 85%. Dans quelques cas périphériques, il a réduit une construction de 30 minutes à 100 millisecondes, a affirmé Palmer.

“Turborepo est vraiment bon dans ce qu’il fait : des constructions ridiculement rapides”, enthousiaste un ingénieur sur Twitter.

De plus, Palmer a conçu le logiciel pour qu’il soit super intuitif pour les développeurs individuels et les petites équipes. Turborepo a en effet suscité les éloges des critiques à cet égard par rapport à NX, un projet similaire créé par d’anciens ingénieurs de Google.

Tellement impressionné par le logiciel, Vercel a acquis la technologie, complétant son portefeuille de technologies de développement Web, qui comprend également le framework frontal de nouvelle génération Svelte et la bibliothèque Next.js pour augmenter le framework React avec des capacités de rendu côté serveur.

Le gros problème de code

Le problème de la gestion uniforme de grandes quantités de code existe depuis un certain temps et a été exacerbé par l’explosion du développement Web, qui s’appuie sur une diversité de packages open source et une certaine rapidité de livraison.

Pourquoi a-t-on besoin d’un système de construction pour JavaScript ? Bien que JavaScript puisse être exécuté directement dans le navigateur, cela se fait rarement plus longtemps, a expliqué Palmer. Les bibliothèques telles que React nécessitent plusieurs outils tels que JSX qui doivent être compilés. Mais si plusieurs équipes logicielles utilisent JSX, l’organisation dans son ensemble se retrouve rapidement avec plusieurs instances de JSX, parfois conflictuelles, ce qui est un cauchemar logistique et de sécurité.

La réponse à laquelle les géants de l’informatique sont parvenus est de tout stocker dans un référentiel géant (le “monorepo”). En plus de mieux gérer le code lui-même, un dépôt unique ouvre la voie à un style de codage et à des tests uniformes dans toute l’organisation.

Google, Facebook et Uber ont tous emprunté cette voie, tout comme les gardiens de React lui-même.

Cependant, les outils de construction généraux n’ont pas suivi cet environnement en évolution. Alors que les géants du Web Facebook et Google ont tous deux développé des ensembles d’outils internes pour résoudre le problème de latence (open source comme Bazel et Buck, respectivement), ces outils nécessitaient une configuration étendue et ont été conçus pour les grandes organisations à forte ingénierie.

Palmer était plus intéressé par la création d’un outil qui serait plus facilement utilisé par les petites équipes. Entrez Turborepo.

Mise en cache et parallélisation

Les temps de construction plus rapides proviennent de différentes manières.

L’un est la mise en cache intelligente. Pour cela, le logiciel emprunte une technique à Bazel de Google, construite autour du stockage adressable par le contenu.

Turbo examine “l’état de votre base de code”, a expliqué Palmer. Il enregistre également les commandes exécutées pour créer le logiciel, en créant une empreinte digitale qui sert à indexer le travail fini. Lorsque le développeur tape la même séquence de commandes, Turbo peut alors fournir rapidement la version en cache plutôt que de répéter le travail.

“Turbo construit un graphique de dépendances, à la fois des dépendances externes des registres de packages, ainsi que des dépendances internes au sein de votre base de code”, a expliqué Palmer. Le développeur fournit les informations de dépendance dans un turbo.json fichier de configuration la racine du projet.

Dans les environnements collaboratifs, le cache de chaque développeur est partagé, de sorte qu’un développeur peut réutiliser le travail de ses pairs.

Comparez cela au vénérable make , qui ne regarde que les heures de modification des fichiers ou dossiers spécifiés, plutôt que l’empreinte digitale de l’artefact réel. Différents ordinateurs produiront des horodatages différents pour exactement la même heure, ce qui fera que les systèmes de construction manqueront des fichiers autrement identiques.

En plus d’utiliser le travail mis en cache, Turborepo recherche également des emplacements pour diviser la construction en opérations parallèles.

Le pipeline du développeur, ou graphe de tâches, fournit “un moyen très concis pour les développeurs d’exprimer les relations entre les scripts qu’ils doivent exécuter pour construire leur base de code”, a expliqué Palmer.

Turborepo utilise ces informations pour déterminer quelles opérations peuvent être exécutées en parallèle, en réduisant le temps de construction en exécutant plusieurs tâches en même temps, lorsque cela est possible. C’est quelque chose qui ne peut pas être fait facilement avec les outils de construction JavaScript traditionnels. “Ils n’exécutent les choses que dans l’ordre des dépendances”, a déclaré Palmer. Ils ne disposent pas des informations supplémentaires nécessaires pour comprendre comment ces tâches sont liées les unes aux autres.

Voici un exemple de fichier de configuration de pipeline json (à partir de la documentation) :

L’interface de ligne de commande Turbo est open source et fonctionne à partir du référentiel. L’utilisateur final peut héberger l’index de cache distant ou utiliser le service géré de Vercel, qui comprend des fonctionnalités supplémentaires telles que des visualisations basées sur des métriques.

Également unique à Turborepo, il peut être adopté progressivement. D’autres systèmes de construction peuvent “imposer des contraintes sur votre base de code et sur son fonctionnement et sur la façon dont il doit être façonné. Et bien que ces contraintes puissent être importantes à certaines échelles, elles peuvent être très coûteuses et coûteuses et risquées à migrer », a déclaré Palmer. En revanche, Turborepo vise à «rencontrer les développeurs là où ils se trouvent déjà, avec des outils qu’ils utilisent déjà. Et donc il est conçu pour être adopté, et à certains égards également supprimé. ”

Il est encore tôt pour Turborepo, admet Palmer. (La dernière version est la 1.1.16). La configuration est toujours compliquée et nécessite un peu de polissage, selon au moins un utilisateur.

« Turborepo est un projet vraiment cool. Et ce n’est pas seulement cool, c’est vraiment nécessaire – il manquait clairement un outil comme celui-ci car les monorepos sont de plus en plus populaires », a écrit l’architecte frontend Štěpán Granát dans un article de blog, tout en ajoutant que les incohérences du logiciel indiquent que le travail doit encore être fait pour une utilisation en production. “Je ferais toujours mieux d’exécuter notre pipeline de versions principal sans aucune mise en cache car je veux être sûr que quelque chose n’est pas mis en cache alors qu’il ne devrait pas l’être car cela pourrait vraiment être un gros problème.”