JS エコシステムのクリーンアップと高速化 - これまでの道のり-jsチュートリアル-php.cn

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

WBOY

リリース： 2024-09-04 09:33:21

オリジナル

1041 人が閲覧しました

Cleaning & speeding up the JS ecosystem - Journey so far

私はここしばらく、エコシステム全体のパフォーマンスを向上させることに熱心に取り組んできました。通常は、古い依存関係ツリーをクリーンアップし、インストールのフットプリントを削減し、一般的に使用される依存関係の 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 つのレベルに分割されています。ネイティブ (ネイティブ機能に置き換えることができるモジュール)、マイクロユーティリティ (単純なインラインコードで置き換えることができるモジュール)、および優先 (私たちが考えるモジュール)よりパフォーマンスの高い代替品に置き換える必要があります)。