ESLint : l’introduction du linting multithread améliore jusqu’à 3 fois la vitesse sur les grands projets

Résumé essentiel

• Le linting multithread a été ajouté à ESLint v9.34.0, permettant de traiter plusieurs fichiers simultanément.
• L’objectif est de réduire de façon significative le temps de linting sur les grandes bases de code.
• Cette fonctionnalité, en préparation depuis plus de 10 ans, est désormais officiellement introduite.

Qu’est-ce qui s’est amélioré ?

• Les cœurs CPU sont mieux exploités grâce au traitement parallèle, ce qui réduit le temps total de linting.
• C’est particulièrement efficace pour les monorepos ou grands dépôts contenant un grand nombre de fichiers.

Mode d’utilisation

• Une option permettant de contrôler la concurrence (nombre de threads) est fournie dans la CLI (par ex. des paramètres liés à concurrency).
• Il est possible d’ajuster la valeur de concurrence selon le projet ou l’environnement CI afin de trouver le point optimal.

Contraintes et points d’attention

• Certains cas signalent que les performances peuvent être inférieures aux attentes lors d’une exécution via des wrappers ou outils d’intégration externes (cela varie selon la combinaison environnement/outils).
• Comme il s’agit d’une fonctionnalité récente, il est recommandé de vérifier à la fois les performances et la stabilité en CI comme en local lors de son adoption dans le flux de linting.

Conseils d’adoption

• Plutôt que de l’appliquer d’un coup à tout le dépôt, l’introduire progressivement par répertoire afin de trouver le bon niveau de concurrence.
• En CI, ajuster conjointement le cache et la stratégie de parallélisation, et examiner en priorité les règles/plugins qui créent les plus gros goulots d’étranglement (IO fichier, temps d’exécution des règles).

En une phrase

• « Le linting parallèle tant attendu : le moment est venu de viser un gain de temps réellement perceptible sur le lint des grands projets. »

[hso2341]

Je me demande quelle est la vitesse en comparaison avec Biome ?

[pmc7777]

Biome reste plus rapide. Mais si on ne regarde que la vitesse, oxlint de voidzero est encore plus rapide.

Comme Biome est plus pratique du point de vue de l’ergonomie et de la documentation, à moins que l’ESLint actuel ne devienne plus rapide avec la combinaison ESLint + ESLint Stylistic au lieu de ESLint + Prettier tout en se stabilisant en même temps, cette optimisation par multithreading est impressionnante, mais je me dis qu’il finira peut-être par être remplacé un jour.