ほとんどすべてのビルドシステムは、ウォッチメカニズムを使用して、開発中にビルド後ファイルを繰り返し生成する問題を解決することを選択します。ただし、監視メカニズムの下では、コードを長時間変更し、リフレッシュして効果を確認する前にコードを保存した後にお茶を飲まなければならないという問題に耐える必要があります。ここでは、時計が銀の弾丸ではない理由を探り、この問題に対するより良い解決策を見つけようとします。
監視に基づく事実
ファイルが変更された場合、その変更によって引き起こされる可能性のあるファイルの変更を知ることができるため、これらのファイルを再構築するだけです。
通常、ファイルAの場合、対応する関係はファイルBのようなシナリオを構築するのに非常に正確ですが、実際のシナリオでは、建設プロセスはそれほど単純ではないことがよくあります。例えば：
ファイルA +ファイルB（ファイルAで参照） - >ファイルC
このシナリオでは、ファイルBが変更された場合、多くのファイルがファイルBを参照する可能性があるため、どのファイルが建設タスクを再実行する必要があるかを見つけることが困難な場合があります。
依存関係ツリーを構築し、ファイルが更新されるたびに依存関係ツリーを更新し、新しい依存関係ツリーに基づいてファイル構築をトリガーしない限り。しかし、これにはすべてのプラグインがこのメカニズムを単独で実装する必要があり、非常にエラーが発生しやすいです。したがって、実際、時計メカニズムはタスク全体を再実行するだけです。したがって、プロジェクトが大きくなると、ウォッチメカニズムが遅くなり、遅くなります（プロセス全体に必要な時間を短縮することでキャッシュが短縮されたとしても、プロセス全体を再実行する必要があります）。
解決
SRCは直接利用できます
AlloyTeamと@ldjkingは、SRCを直接配置して、ビルドタスクをブラウザ側に配置するか、まったくビルドしません。時間内に変更して更新するだけでなく、開発プロセス中の時間消費も短縮できます。オフライン構築は、パフォーマンスの最適化の問題のみを担当し、開発効率ではありません。
典型的な代表者には、より少ない、反応などが含まれますが、いくつかの問題があります。
ブラウザ側にエレガントな建設方法を実装することは困難であり、開発コストをさらに削減するために強力な機能を提供することは困難です。それらのほとんどは、<style type = "text/less"> </style>方法と同様の方法でのみスクリプトを導入できます。
開発モードでの実行順序は、必ずしも実際のシナリオと同じではないため、目に見えないバグにつながる可能性があります。たとえば、HTMLインラインの実装は非同期ですが、リリースモードでは同期され、不可解なバグが発生します。
SASSのJSバージョンなど、ブラウザのコンピレーションパフォーマンスは心配であり、コンパイル速度はほとんど耐えられません。
オンラインおよびオフラインの2セットとオフラインの建設システムを維持する必要があります。これにより、ツール開発のコストが増加します。
ローカルサーバーの動的構造
1つの事実は、合理的な仕様サポートを使用すると、ブラウザによって要求されたエントリファイルに戻り、ファイル中に構築されたファイルに戻ることができます。これにより、ビルドプロセスを動的にトリガーできます。
サーバーをローカルに確立することにより、サーバーにリクエストをキャプチャし、サーバーで動的にビルドします。エントリファイルに戻る限り、エントリファイルをGulpプラグインで構成されるパイプラインにスローでき、出力はブラウザで必要なファイルです。
これにより、上記のすべての問題を解決できます。