Bereinigen und Beschleunigen des JS-Ökosystems – Bisherige Reise

Seit einiger Zeit arbeite ich hart daran, die Leistung im gesamten Ökosystem zu steigern. Normalerweise durch Bereinigen veralteter Abhängigkeitsbäume, Reduzieren des Installationsbedarfs und Verbessern der CPU-/Speicherleistung häufig verwendeter Abhängigkeiten.

Dieser Blog-Beitrag ist nur mein kurzer Versuch, einen Teil der Reise zu erklären, die zu e18e und der Bereinigung des Ökosystems führte.

Gedanken zu Mikroversorgern

Mikro-Dienstprogramme tragen wesentlich zur Installationsgröße und darüber hinaus zur Komplexität des Abhängigkeitsbaums vieler Projekte bei.

Pakete wie is-number und is-nan passen in diese Kategorie.

Wichtig ist, dass viele dieser Pakete in manchen Situationen einen Nutzen haben, aber sicherlich nicht im allgemeinen Anwendungsfall.

Normalerweise können sie in den folgenden Situationen ersetzt werden:

• Sie wurden zu einer Zeit geschrieben, als es keine entsprechende native Funktionalität gab, aber jetzt gibt es sie
• Sie tun mehr als das, was der Verbraucher braucht

Beispiel: ist-Nummer

Is-Nummer bestimmt beispielsweise, ob ein Wert eine Zahl oder eine zahlenähnliche Zeichenfolge ist, die nicht NaN oder +/-Unendlich ist.

In einigen Projekten ist dies ein wiederholter Teil der Validierung, der besser in ein eigenes Modul oder Paket extrahiert werden kann.

Allerdings benötigten viele Verbraucher im Normalfall nie die NaN- und Infinity-Validierung oder auch nur die Unterstützung zahlenähnlicher Zeichenfolgen.

Dies eröffnet einige mögliche Verbesserungen in verschiedenen Projekten. Wir können die Verwendung dieses Pakets in diesen Projekten durch eine viel einfachere Inline-Logik ersetzen (z. B. haben wir in vielen realen Projekten sicher auf typeof n === 'number' umgestellt, da diese Projekte später davon ausgingen und sich darauf verließen, dass der Wert ein tatsächlicher Wert war). Nummer sowieso).

Ein weiteres Beispiel: is-regexp

Sie können testen, ob etwas ein regulärer Ausdruck ist, indem Sie „instanceof: v instanceof RegExp“ verwenden.

In manchen Situationen (z. B. bei der Verwendung virtueller Kontexte) funktioniert dies jedoch nicht, da RegExp nicht dieselbe Klasse ist, aus der v stammt. In diesen Fällen müssen wir so etwas verwenden:

Object.prototype.toString.call(obj) === '[object RegExp]'

Wenn Sie solchen Code nicht einbinden möchten und virtuelle Kontexte oder ähnliches unterstützen müssen, ist möglicherweise eine Bibliothek sinnvoll.

Allerdings unterstützten die Projekte in vielen Fällen ohnehin keine virtuellen Kontexte (und wollten dies auch nicht). Das eröffnet uns Möglichkeiten zur erneuten Vereinfachung auf eine einfache Instanz von.

Unterstützung älterer Laufzeiten

Ein weiterer potenzieller Verbesserungsbereich ist die Unterstützung älterer Laufzeiten.

Viele sehr beliebte Pakete haben sehr tiefe Abhängigkeitsbäume verschiedener Polyfill-ähnlicher Module. Diese liegen im Allgemeinen aus einem oder beiden der folgenden Gründe vor:

• Zum Schutz vor globalen Namensraummanipulationen
• Um die Unterstützung in Laufzeiten aufrechtzuerhalten, denen diese Funktionalität fehlt

Viele von uns benötigen dieses Maß an Abwärtskompatibilität nicht und könnten große Leistungssteigerungen erzielen, wenn wir es wegschneiden könnten.

Es ist natürlich wichtig zu beachten, dass es immer noch Menschen gibt, die unter diesen Einschränkungen arbeiten müssen. Aus diesem Grund haben wir in diesem Bereich häufig Abzweigungen oder Alternativen bereitgestellt, anstatt zu versuchen, die vorhandenen Pakete zu ändern (die für solche Änderungen ohnehin nicht offen wären). Ich fange an, die Dinge zu verbessern

Ich begann etwa 2018 über diese speziellen Bereiche nachzudenken, nachdem ich gesehen hatte, wie groß und tief verschachtelt meine Knotenmodule selbst für die kleinsten Projekte waren.

Meine ersten Änderungsversuche bestanden darin, eine Art ESLint-Plugin zu erstellen, das diese Pakete erkennen und vorschlagen kann, sie zu entfernen. Alle paar Monate hatte ich die gleiche Idee und versuchte es erneut, kam aber nie wirklich dort an, wo ich sein wollte.

Während dieser Zeit habe ich zumindest zu verschiedenen großen Projekten beigetragen, um aufzuräumen und zu verbessern, was ich konnte (z. B. eines, zu dem ich schon lange beigetragen habe, ist Storybook).

Säuberung des Ökosystems

Ich habe dann die Ökosystembereinigung erstellt, ein Repository zur Erhöhung möglicher Leistungsverbesserungen im gesamten Ökosystem (im Grunde ein Issue-Tracker). Auch dies war eine Zeit lang im Grunde mein persönlicher Issue-Tracker für mich, aber zumindest war er öffentlich sichtbar.

Bald darauf begann ich zu sehen, dass Leute in den Ausgaben auftauchten und zu vorgelagerten Projekten beitrugen. Ich war so glücklich, das zu sehen, da ich viele Jahre damit verbracht hatte, selbst daran zu arbeiten, und mich fragte, ob ich überhaupt etwas bewirken würde. Zu sehen, wie andere mitmachen, hat mir sehr geholfen, zu wissen, dass sich jemand anderes um uns kümmert.

Modulaustausch

Obwohl das Aufräumprojekt unglaublich nützlich war und immer noch ist, hatten wir nicht wirklich die Möglichkeit, mit dem Rest der Community zu teilen, welche guten Alternativen es gibt.

Um dieses Problem zu lösen, habe ich das Modulaustauschprojekt erstellt.

Dieses Projekt enthält im Wesentlichen einige JSON-Listen von Modulen, die möglicherweise ersetzt werden können, und deren vorgeschlagene Alternativen. Diese sind derzeit in drei Ebenen der „Strenge“ oder „Meinungsorientierung“ unterteilt: native (Module, die durch native Funktionalität ersetzt werden können), Mikro-Dienstprogramme (Module, die durch einfachen Inline-Code ersetzt werden können) und bevorzugt (Module, die unserer Meinung nach sollte durch leistungsfähigere Alternativen ersetzt werden).

Codemods

Der nächste Schritt des Ersatzprojekts bestand darin, eine Reihe von Codemods zu erstellen, damit wir den Austausch einiger dieser Module automatisieren können.

Angetrieben von @passle erhielt dieses Projekt schnell eine große Menge an Beiträgen in Form verschiedener Codemods.

Das Codemod-Team hat auch gute Arbeit geleistet und diese auf die Codemod-Plattform portiert. In Zukunft möchten wir sie auch über eine Art CLI oder Auto-Fix-Regeln bereitstellen.

e18e

Der Wendepunkt, an dem ich das Gefühl habe, dass wir alle, denen dieses Zeug am Herzen liegt, einander gefunden haben, war e18e.

Björn hat großartige Arbeit geleistet, um die Leistung von Astro zu verbessern, und Marvin hatte in ähnlicher Weise über die Beschleunigung des Ökosystems geschrieben. Irgendwann kreuzten sich unsere Wege und wir hatten nebenbei einige tolle Gespräche.

Eine kleine Gruppe von uns hat zusammengearbeitet, um herauszufinden, ob wir alle einer Meinung sind und ob sich daraus eine Community aufbauen lässt. Dann kam e18e!

Konstruiert als Gemeinschaftsraum, in dem Menschen zusammenarbeiten können, um die Leistung des Ökosystems zu verbessern, hat uns dies gezeigt, wie vielen Menschen diese Dinge am Herzen liegen. So viele haben sich angeschlossen und bereits riesige Beträge gespendet. Wir sehen fast täglich im gesamten Ökosystem Geschwindigkeitssteigerungen und Größenreduzierungen.

Vielen Dank

Die Community wächst schnell und hat zu viele Menschen, denen sie für ihre Beiträge danken kann. Ich möchte mich jedoch besonders bei diesen Menschen dafür bedanken, dass sie dazu beigetragen haben, diese Community möglich zu machen:

• @patak
• @antfu7
• @bluwyoo
• @passle_

Ebenso die Menschen, die bereits an Projekten arbeiteten, die parallel zu denselben Zielen beitrugen:

• @asleMammadam über tinylibs
• pi0 bis unjs

Das obige ist der detaillierte Inhalt vonBereinigen und Beschleunigen des JS-Ökosystems – Bisherige Reise. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!