Sélectionnez et configurez des outils de compilation en fonction des bonnes pratiques.
Aujourd'hui, web.dev lance une nouvelle initiative appelée tooling.report. Il s'agit d'un site Web qui offre aux développeurs Web un aperçu des fonctionnalités prises en charge par un ensemble d'outils de compilation populaires. Nous avons conçu ce site pour vous aider à choisir l'outil de compilation le plus adapté à votre prochain projet, à décider s'il vaut la peine de passer d'un outil à un autre ou à intégrer les bonnes pratiques à la configuration de vos outils et à votre code base. Les outils ont des domaines d'action différents et répondent à des besoins différents, ce qui signifie que la sélection et la configuration des outils impliquent des compromis. Avec Tooling.report, notre objectif est d'expliquer ces compromis et de documenter les bonnes pratiques à suivre avec n'importe quel outil de compilation.
Cela semble passionnant ? Accédez à tooling.report pour commencer à explorer ce site, ou continuez votre lecture pour en savoir plus sur les raisons qui nous ont poussés à développer ce site et sur la manière dont nous avons développé ce dernier.
Les outils de création perturbent souvent
Lors des GoogleChromeLabs, nous avons développé des applications Web comme Squoosh et Proxx, ainsi que des sites Web comme celui du Chrome Dev Summit 2019. Comme pour tout projet de développement Web, nous commençons généralement par parler de l'infrastructure du projet, telle que l'environnement d'hébergement, les frameworks et la configuration de notre outil de compilation. Cette infrastructure est mise à jour au fur et à mesure que le projet progresse: de nouveaux plug-ins sont ajoutés afin de s'adapter aux frameworks ou aux techniques que nous adoptons, ou la façon dont nous écrivons le code est modifiée pour que nos outils de compilation comprennent mieux ce que nous essayons d'atteindre. Tout au long de ce processus, nous avons souvent constaté que les outils que nous sélectionnons finissent par nous ennuyer.
Notre équipe s'efforce d'offrir la meilleure expérience Web aux utilisateurs, ce qui lui permet souvent d'ajuster la façon dont nos éléments de frontend sont assemblés et livrés. Par exemple, si un script de thread principal et un script de nœud de calcul Web partagent des dépendances, nous souhaitons les télécharger une seule fois au lieu de les regrouper deux fois pour chaque script. Certains outils sont compatibles par défaut, d'autres nécessitent des efforts de personnalisation importants pour modifier les comportements par défaut, et d'autres sont totalement impossibles.
Cette expérience nous a amenés à étudier les possibilités et interdictions des différents outils de compilation. Nous avions pour objectif de créer une checklist des fonctionnalités afin de pouvoir évaluer et choisir l'outil le mieux adapté à notre prochain projet.
Notre approche
Comment évaluer et comparer différents outils de compilation de façon centralisée ? Nous avons abordé la question en rédigeant des scénarios de test.
Notre équipe a discuté et conçu des critères de test qui, selon nous, représentent les bonnes pratiques en matière de développement Web. Nous nous sommes concentrés sur la manière de proposer des expériences utilisateur rapides, réactives et fluides, en excluant intentionnellement les tests liés à l'expérience des développeurs afin d'éviter de mesurer deux résultats incomparables.
Une fois la liste de tests créée, nous avons écrit un script de compilation pour chaque outil afin de vérifier s'il répond aux critères de réussite du test. Dans un premier temps, nous avons décidé d'examiner Webpack v4, Rollup v2 et Parcel v2. Nous avons également testé Browserify + Gulp, car un grand nombre de projets utilisent toujours cette configuration. Pour qu'un test réussisse, seules les fonctionnalités publiques de l'outil ou un plug-in de l'outil peuvent être utilisés. Une fois l'ensemble initial de tests écrit, nous avons collaboré avec les auteurs des outils de compilation pour nous assurer que nous utilisions leurs outils correctement et que nous les représentions de manière équitable.
Nous n'utilisons que ${tool_name}, est-ce que cela m'intéresse quand même ?
Dans de nombreuses équipes, des personnes sont chargées de la maintenance de l'infrastructure de compilation, et les autres membres de l'équipe n'ont peut-être jamais la possibilité de faire un choix en ce qui concerne le développement d'outils. Nous espérons que ce site vous sera toujours utile et qu'il vous aidera à définir vos attentes vis-à-vis des outils que vous utilisez. Pour chaque test, nous avons inclus une explication de l'importance du test, ainsi que des ressources supplémentaires. Si vous souhaitez adopter une bonne pratique avec l'outil de votre choix, la configuration de test dans notre dépôt contient les fichiers de configuration nécessaires.
Puis-je contribuer au site ?
Si vous pensez qu'une fonctionnalité qui manque actuellement à tester devrait être testée, veuillez la proposer dans un problème GitHub pour commencer la discussion. Notre objectif est d'encapsuler des cas d'utilisation concrets. Tout test supplémentaire permettant de mieux évaluer ces résultats est le bienvenu.
Si vous souhaitez écrire des tests pour des outils que nous n'avons pas inclus dans l'ensemble initial, nous vous invitons à le faire. Pour en savoir plus, consultez le fichier CONTRIBUTING.md.