JS エコシステムのクリーンアップと高速化 - これまでの道のり

私はここしばらく、エコシステム全体のパフォーマンスを向上させることに熱心に取り組んできました。通常は、古い依存関係ツリーをクリーンアップし、インストールのフットプリントを削減し、一般的に使用される依存関係の CPU/メモリのパフォーマンスを向上させます。

このブログ投稿は、e18e とエコシステムのクリーンアップにつながる旅の一部を説明する私の簡単な試みです。

マイクロユーティリティについての考え

マイクロユーティリティは、インストール サイズ、さらには多くのプロジェクトの依存関係ツリーの複雑さの主な要因です。

is-number や is-nan などのパッケージは、このカテゴリに当てはまります。

重要なのは、これらのパッケージの多くは状況によっては使用されますが、一般的な使用例では決して使用できないということです。

通常、次の状況で置き換えることができます:

• これらは同等のネイティブ機能が存在しなかった時代に書かれましたが、現在は存在します
• 消費者が必要とする以上のことを行います

例: is-number

たとえば、is-number は、値が NaN または +/-Infinity ではない数値または数値に似た文字列であるかどうかを判断します。

一部のプロジェクトでは、これは 検証 の繰り返しであり、独自のモジュールまたはパッケージに抽出した方がよい場合があります。

しかし、一般的なケースでは、多くの消費者は NaN や Infinity 検証を必要としたことはなく、数値のような文字列のサポートさえも必要としませんでした。

これにより、さまざまなプロジェクトで改善の可能性が広がります。これらのプロジェクトでのこのパッケージの使用を、より単純なインライン ロジックに置き換えることができます (たとえば、多くの実際のプロジェクトでは、これらのプロジェクトは後で値が実際の値であると仮定して依存するため、安全に typeof n === 'number' に切り替えました)とにかく数字)。

別の例: is-regexp

instanceof を使用すると、何かが正規表現であるかどうかをテストできます。 v instanceof RegExp.

ただし、状況によっては (仮想コンテキストの使用など)、RegExp が v の元のクラスではないため、これは機能しません。そのような場合、次のようなものを使用する必要があります:

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

そのようなコードをインライン化したくないが、仮想コンテキストなどをサポートする必要がある場合は、ライブラリを使用するのが合理的かもしれません。

しかし、多くの場合、プロジェクトはとにかく仮想コンテキストをサポートしていませんでした (そしてサポートしたくありませんでした)。これにより、単純なインスタンスに再度単純化する機会が生まれます。

古いランタイムのサポート

もう 1 つの改善の可能性がある領域は、古いランタイムのサポートです。

非常に多くの人気のあるパッケージには、さまざまなポリフィルのようなモジュールの非常に深い依存関係ツリーがあります。これらは通常、次のいずれかまたは両方の理由で存在します:

• グローバル名前空間の改ざんから保護するため
• この機能が欠けているランタイムでのサポートを維持するため

私たちの多くはこのレベルの下位互換性を必要としていないため、それを削除できればパフォーマンスが大幅に向上する可能性があります。

もちろん、こうした制約の中で働く必要がある人が依然としていることに注意することが重要です。このため、この分野では、既存のパッケージを変更しようとするのではなく、フォークや代替案を提供することがよくあります (いずれにせよ、そのような変更は受け入れられません)。

物事を改善し始める

私がこれらの特定の領域について考え始めたのは、2018 年頃で、たとえ最小のプロジェクトであっても、node_modules がどれほど大きく、深くネストされているかを確認した後です。

私が変更を試みた最初の数回の試みは、これらのパッケージを検出して削除を提案できる、ある種の ESLint プラグインを作成することでした。数か月ごとに、同じ考えを思いつき、もう一度試してみましたが、実際には自分が望んでいた場所に到達することはできませんでした。

この間、私はできる限りのことをクリーンアップして改善するために、少なくともさまざまな大規模なプロジェクトに貢献してきました (たとえば、私が長い間貢献してきたプロジェクトの 1 つはストーリーブックです)。

生態系のクリーンアップ

次に、エコシステム クリーンアップを作成しました。これは、エコシステム全体でパフォーマンス向上の可能性を高めるためのリポジトリ (基本的には問題追跡ツール) です。繰り返しますが、これは基本的に私と私自身の個人的な問題追跡者でした。しかし、少なくとも公の場で目に見えていました。

その後すぐに、この問題に参加し、上流のプロジェクトに貢献する人々が現れるようになりました。私はこれを自分で何年もかけてコツコツと積み重ねてきたので、これを見て本当にうれしかったです。自分が変化をもたらしているのかと疑問に思っていました。他の人が参加しているのを見て、他の人が気にかけていることを知るのにとても役立ちました。

モジュールの交換

クリーンアップ プロジェクトは昔も今も非常に便利ですが、どのような優れた代替案が存在するのかをコミュニティの他のメンバーと共有する場所が実際にはありませんでした。

これを解決するために、モジュール置換プロジェクトを作成しました。

このプロジェクトは基本的に、置き換えられる可能性のあるモジュールとその推奨される代替モジュールの JSON リストをいくつか保持しています。これらは現在、「厳格さ」または「意見の強さ」の 3 つのレベルに分割されています。ネイティブ (ネイティブ機能に置き換えることができるモジュール)、マイクロユーティリティ (単純なインライン コードで置き換えることができるモジュール)、および優先 (私たちが考えるモジュール)よりパフォーマンスの高い代替品に置き換える必要があります)。

コードモッド

置換プロジェクトの次のステップは、これらのモジュールの一部の置換を自動化できるように、一連の codemod を作成することでした。

@passle によって推進されたこのプロジェクトは、さまざまな codemod の形ですぐに大量の貢献を受け取りました。

codemod チームは、これらを codemod プラットフォームに移植するという優れた作業も行いました。将来的には、ある種の CLI または自動修正ルールを通じてそれらを提供したいと考えています。

e18e

このことに関心を持つ私たち全員がお互いを見つけたターニングポイントは e18e でした。

Bjorn は astro のパフォーマンスを向上させる素晴らしい仕事をしており、Marvin も同様にエコシステムの高速化について書いていました。結局、私たちの道は交差し、その傍らで素晴らしい議論をすることができました。

私たちの小さなグループは、私たち全員が同じ認識を持っているかどうか、そしてそこから構築されるコミュニティがあるかどうかを確認するために協力しました。そして、e18e が登場しました!

人々が生態系のパフォーマンスを向上させるために協力するためのコミュニティ スペースとして構築されたこのことは、どれだけ多くの人がこれらのことに関心を持っているかを示しています。非常に多くの人が参加し、すでに多額の寄付を行っています。エコシステム全体でほぼ毎日、速度の向上とサイズの縮小が見られます。

ありがとう

コミュニティは急速に成長しており、貢献に感謝しきれないほどの人々がいます。ただし、このコミュニティの実現に貢献してくれた方々に特に感謝したいと思います:

• @パタク
• @antfu7
• @bluwyoo
• @passle_

同様に、既に同じ目標に貢献するプロジェクトに並行して取り組んでいる人々:

• tinylibs を通じて @asleMammadam
• pi0 から unjs

以上がJS エコシステムのクリーンアップと高速化 - これまでの道のりの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。