node.js_node.jsの監視機構の詳細説明

ほとんどすべてのビルド システムは、開発プロセス中にビルド後のファイルを繰り返し生成する問題を解決するために、監視メカニズムを使用することを選択します。ただし、監視メカニズムでは、保存後に長時間コードを変更する必要があります。コードでは、効果を確認する前にお茶を飲む必要があります。ここでは、時計が特効薬ではない理由を探り、この問題に対するより良い解決策を見つけようとします。

時計が基づいている事実

ファイルが変更されると、その変更によって引き起こされる可能性のあるファイルの変更を知ることができ、それらのファイルを再構築できます。

通常、ファイル A がファイル B に構築されるシナリオでは、この対応は非常に確実です。しかし、実際のシナリオでは、構築プロセスはそれほど単純ではないことがよくあります。例:

ファイル A + ファイル B (ファイル A によって参照される) -> ファイル C
このシナリオでは、ファイル B が変更されると、ファイル B を参照するファイルが多数存在する可能性があるため、ビルド タスクを再実行する必要があるファイルを見つけるのが困難になる可能性があります。

依存関係ツリーを構築し、ファイルが更新されるたびに依存関係ツリーを更新し、新しい依存関係ツリーに基づいてファイルの構築をトリガーしない限り。ただし、各プラグインはこのメカニズムを独自に実装する必要があり、非常にエラーが発生しやすくなります。したがって、実際には、監視メカニズムはタスク全体を再実行するだけです。したがって、プロジェクトがますます大きくなるにつれて、監視メカニズムはますます遅くなります (キャッシュによってプロセス全体に必要な時間が短縮されたとしても、プロセス全体を再実行する必要があるファイルが増えるため)。

解決策

ソースは直接利用可能です

AlloyTeam と @ldjking は、簡単に言うと、src を直接実行できるようにし、構築タスクをブラウザ側に配置するか、まったく構築しなくても、時間内に変更および更新できるため、開発中の時間の消費が削減されます。プロセス。オフライン構築はパフォーマンスの最適化の問題にのみ関与し、開発効率には関与しません。
代表的なものとしては、LESS、Reactなどが挙げられます。しかし、いくつかの問題もあります:

ブラウザ側でエレガントな構築方法を実装することは難しく、開発コストをさらに削減するための強力な機能を提供することは困難で、ほとんどは スクリプト。
開発モードでの実行順序は実際のシナリオと必ずしも同じではないため、目に見えないバグが発生する可能性があります。たとえば、HTML をインラインで実装する場合、開発モードではインラインが非同期であるのに対し、リリース モードではインラインが同期となり、不可解な問題が発生する可能性があります。バグ。
ブラウザのコンパイルパフォーマンスは心配です。たとえば、sass の js バージョンのコンパイル速度はほとんど耐えられません。
オンラインとオフラインの2つの構築システムを維持する必要があり、ツールの開発コストが増加します。
ローカルサーバーの動的ビルド

事実の 1 つは、妥当な仕様のサポートがあれば、ブラウザーによって要求されたファイルをファイル構築プロセスのエントリ ファイルまで追跡できるということです。このようにして、ビルド プロセスを動的にトリガーできます。

サーバーをローカルにセットアップすることで、サーバーがリクエストをキャプチャし、サーバー内で動的に構築できるようになります。エントリ ファイルまで遡れば、そのエントリ ファイルを gulp プラグインで構成されるパイプラインに投入でき、出力はブラウザが必要とするファイルになります。

このようにして、上記の問題をすべて解決できます。