Depuis quelque temps déjà, je travaille dur pour augmenter les performances de l'ensemble de l'écosystème. Généralement en nettoyant les anciennes arborescences de dépendances, en réduisant les empreintes d'installation et en améliorant les performances CPU/mémoire des dépendances couramment utilisées.
Ce billet de blog n'est que ma brève tentative d'expliquer une partie du parcours qui a mené à l'e18e et au nettoyage de l'écosystème.
Les micro-utilitaires contribuent largement à la taille de l'installation et, plus encore, à la complexité de l'arborescence des dépendances de nombreux projets.
Les packages tels que is-number et is-nan entrent dans cette catégorie.
Il est important de noter que bon nombre de ces packages sont utiles dans certaines situations, mais certainement pas dans le cas d'utilisation courant.
Habituellement, ils peuvent être remplacés dans ces situations :
Par exemple, is-number détermine si une valeur est un nombre ou une chaîne semblable à un nombre qui n'est pas NaN ou +/-Infinity.
Dans certains projets, il s'agit d'un élément répété de validation qui peut être mieux extrait dans son propre module ou package.
Cependant, dans le cas courant, de nombreux consommateurs n'ont jamais eu besoin de la validation NaN et Infinity, ni même de prendre en charge les chaînes de type numérique.
Cela ouvre la voie à des améliorations possibles dans divers projets. Nous pouvons remplacer l'utilisation de ce package dans ces projets par une logique en ligne beaucoup plus simple (par exemple, dans de nombreux projets du monde réel, nous sommes passés en toute sécurité à typeof n === 'number' puisque ces projets ont ensuite supposé et se sont appuyés sur la valeur comme étant une valeur réelle). numéro quand même).
Vous pouvez tester que quelque chose est une expression régulière en utilisant instanceof : v instanceof RegExp.
Cependant, dans certaines situations (par exemple en utilisant des contextes virtuels), cela ne fonctionnera pas puisque RegExp n'est pas la même classe dont v est issu. Dans ces cas, nous devons utiliser quelque chose comme ceci :
Object.prototype.toString.call(obj) === '[object RegExp]'
Si vous ne souhaitez pas intégrer un tel code et avez besoin de prendre en charge des contextes virtuels ou similaires, une bibliothèque a peut-être du sens.
Cependant, dans de nombreux cas, les projets ne prenaient pas en charge les contextes virtuels de toute façon (et ne voulaient pas le faire). Cela nous ouvre des possibilités de simplifier à nouveau en une simple instance de.
Un autre domaine potentiel d'amélioration est celui de la prise en charge des anciens runtimes.
De nombreux packages très populaires ont des arbres de dépendances très profonds de divers modules de type polyfill. Ceux-ci existent généralement pour l’une ou les deux raisons suivantes :
Beaucoup d'entre nous n'ont pas besoin de ce niveau de compatibilité ascendante et pourraient obtenir d'importants gains de performances si nous pouvions le supprimer.
Il est important de noter, bien sûr, qu'il y a encore des gens qui ont besoin de travailler dans ces contraintes. C'est pourquoi dans ce domaine, nous avons souvent proposé des forks ou des alternatives plutôt que d'essayer de modifier les packages existants (qui ne seraient de toute façon pas ouverts à de tels changements).
J'ai commencé à réfléchir à ces domaines particuliers vers 2018 environ, après avoir constaté à quel point mes node_modules étaient grands et profondément imbriqués, même pour les plus petits projets.
Mes premières tentatives de changement ont consisté à créer une sorte de plugin ESLint capable de détecter ces packages et de suggérer leur suppression. Tous les mois, j'avais la même idée et j'essayais à nouveau, mais je n'arrivais jamais vraiment là où je voulais être.
Pendant cette période, je contribuais au moins à divers grands projets pour nettoyer et améliorer ce que je pouvais (par exemple, celui auquel je contribue depuis longtemps est un livre d'histoires).
J'ai ensuite créé le nettoyage de l'écosystème, un référentiel permettant d'identifier d'éventuelles améliorations de performances dans l'ensemble de l'écosystème (essentiellement un outil de suivi des problèmes). Encore une fois, il s’agissait essentiellement de moi et de mon propre outil de suivi des problèmes pendant un certain temps, mais au moins, c’était visible au grand jour.
Peu de temps après, j'ai commencé à voir des gens se présenter sur les problématiques et contribuer aux projets en amont. J'étais si heureux de voir cela, car j'avais passé de nombreuses années à y travailler moi-même et je me demandais si je faisais une différence. Voir d’autres se joindre à nous a beaucoup aidé à savoir que quelqu’un d’autre se soucie.
Bien que le projet de nettoyage ait été et soit toujours incroyablement utile, nous n'avions pas vraiment d'endroit où partager avec le reste de la communauté les bonnes alternatives qui existent.
Pour résoudre ce problème, j'ai créé le projet de remplacement de modules.
Ce projet contient essentiellement des listes JSON de modules qui peuvent éventuellement être remplacés et leurs alternatives suggérées. Ceux-ci sont actuellement divisés en trois niveaux de « rigueur » ou « d'opinion » : natifs (modules qui peuvent être remplacés par des fonctionnalités natives), micro-utilitaires (modules qui peuvent être remplacés par un simple code en ligne) et préférés (modules que nous pensons devrait être remplacé par des alternatives plus performantes).
La prochaine étape du projet de remplacement consistait à créer un ensemble de codemods afin que nous puissions automatiser le remplacement de certains de ces modules.
Pisté par @passle, ce projet a rapidement reçu une énorme quantité de contributions sous forme de codemods variés.
L'équipe codemod a également fait du bon travail en les portant sur la plateforme codemod. À l'avenir, nous souhaitons également les fournir via une sorte de CLI ou de règles de correction automatique.
Le tournant où je sens que nous tous qui nous soucions de ce genre de choses nous sommes retrouvés a été e18e.
Bjorn faisait un excellent travail pour améliorer les performances de l'astro, et Marvin avait également écrit sur l'accélération de l'écosystème. Finalement, nos chemins se sont croisés et nous avons eu de belles discussions en parallèle.
Un petit groupe d'entre nous a travaillé ensemble pour voir si nous sommes tous sur la même longueur d'onde et s'il y a une communauté à construire à partir de cela. Puis vint e18e !
Construit pour être un espace communautaire permettant aux gens de collaborer à l'amélioration des performances de l'écosystème, cela nous a montré combien de personnes se soucient de ces choses. De nombreuses personnes se sont jointes à nous et ont déjà contribué massivement. Nous constatons des accélérations et des réductions de taille presque chaque jour dans l'ensemble de l'écosystème.
La communauté grandit rapidement et compte trop de personnes à remercier pour leurs contributions. Cependant, je tiens à remercier en particulier ces personnes qui ont contribué à rendre cette communauté possible :
De même, les personnes qui travaillaient déjà sur des projets contribuant aux mêmes objectifs en parallèle :
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
