webpackはモジュール入力としてASTを採用しますか？

Question

現在webpackはファイルを扱います。ファイルはローダーを介して解析され、依存関係を判別します。

babelを使用する場合、babelはファイルを解析し、webpackにどの依存関係があるかを直接伝えるのに十分な情報を持っています。私が知っている限り、この豊富な情報をwebpackに直接渡す方法はありません.babelはJavaScriptファイルをテキストとして生成する必要があります。このWebpackは、依存情報を抽出するために再解析します。

（a）要約は正しいですか？これは現在起こっていることですか？ （b）このようなレイヤー間の統合を強化する計画はありますか？私はこれがビルド時間にかなり良い影響を及ぼすことを期待します。

Answer 1

（a）はい、この要約は正しいです。これは主に、異なるツール間で共通のASTフォーマットが存在しなかったためです。これは最近ESTree Specで変更されました。しかし、私はこれらのASTが実世界プロジェクトでどのように相互運用可能であるかはわかりません。 astexplorer.netのASTを比較すると、ASTがいくぶん類似しているように見えます。 Webpackの現在の設計は無駄ですが、優れた相互運用性を提供します。

（b）私はこれに関する計画を知らない。しかし私はすでにそれについても考えてきました。ほとんどのWebpackビルドチェーンでは、Sassが解析されてCSSに変換され、CSSは通常はプレフィックスを適用してCSSを出力するpostcss-loaderによって解析され、その後CSSは再び解析されますcss-loader（PostCSSによるfunnily）、JSに変換され、webpackによって再び解析されて、依存関係のグラフが得られます。これは非常に効率が悪く（can already be a problem）、ソースコードを理解できるツールを統合することができます。

しかし、コンパイラをよりプラガブルにする傾向があります。最も顕著な例はBabelとPostCSSです。その結果、autoprefixer-loaderはPostCSSプラグインのために推奨されなくなりました。公式の委員でさえ、CSS-TAG Houdini Task ForceやJavaScript decorators proposalのようなブラウザ内の言語処理を傍受するためのAPIを扱っています。

私はBabelやPostCSSのようなツールをもっと期待しています。そして、これはおそらく、Webpackビルドチェーン内の別々のローダーや、これらのツール環境内でより多くの作業が行われることにつながります。これらのツールはWebpackのコンテキスト外で再利用できるため、実際には良いことです。コード生成をスキップし、すぐにASTを再利用する手段を提供するコンパイラが増えているのを見るのは本当に良いことです。

はWebPACKの中に、現在の状況に関して：

ほとんど知られてローダ機能が value/inputValueと呼ばれる、もあります。あるローダーから別のローダーにメタ情報を渡す方法として意図されています。したがって、 a shortcut to skip needless parsingとして使用できます。 webpack @ 1でこの機能を使用できます。しかし、この機能は現在webpack @ 2のベータブランチでは利用できません（理由はわかりません）。
は - sokraは、彼が2 @ WebPACKの中で、このレガシー機能を削除したことを私に言ったので、これは、複数の入力と出力を有していてもよく、もう

ローダーを使用するのは安全ではありません。 JavaScriptでは複数のreturn値を使用できないため、出力はthis.callbackを呼び出すことによってのみ達成できます。現在の規約では、最初の値は常に実際のローダの内容です。 2番目の値はソースマップです（アクティブな場合）。だから私たちはASTを回す手段として第3の値を使うことができました。しかし、これは現在どこにも実装されていません。しかし、それから始めることができます。

---

Btw：Mark Finger最近このトピックに関する貴重な研究を行いました。 his findingsにも興味があるかもしれません。