Webpackプラグインエラー管理

Question

この投稿の主な目的は、Webpackプラグインの作成中にエラー/警告管理に関する追加情報を得ることです。

私はプラグインインターフェイス（コールバックで）ベースのタイミングにerrパラメータを渡すことが可能ですWebpack plug-in documentationで見てきたが、それはWebPACKのライフサイクルに影響を与えていますどのように何の更なる説明は、そのビルドはありませんプロセスとそれを使用する方法。他のタイプのプラグインインタフェースでエラーを管理する方法があるかどうかは説明していません。

は、とにかく最初の試みとして、'emit'ライフサイクルの段階で、私はerrパラメータにnew Error('An error has occurred')または単に'An error has occured'値を渡すのどちらかにしようとしたが、いずれの場合には、それは確かに与えられたERRパラメータを表示します（悲しいことに、エラーの特定の着色なしIE）があり、そしてWebPACKの-SEV-serverが捕まってしまったとしてコンソール：だから、それは余分なコールバックがWebPACKのビルドプロセスを持つために、以下の方法を呼び出す必要

function WpAggregationPlugin() { 
    this.startTime = Date.now(); 
    this.prevTimestamps = {}; 
    } 

    WpAggregationPlugin.prototype.apply = function(compiler) { 
    compiler.plugin('emit', (compilation, callback) => { 

     var changedFiles = Object.keys(compilation.fileTimestamps).filter(watchfile => 
     this.prevTimestamps[watchfile] && 
     (this.prevTimestamps[watchfile] < (compilation.fileTimestamps[watchfile] || Infinity))) 

     // compilation.errors.push(new Error('...')) 

     this.prevTimestamps = compilation.fileTimestamps; 

     if(changedFiles.length <= 0) { 
     callback() 
     } else { 
     process.stdout.write(`File modification detected :\n${JSON.stringify(changedFiles, null, 4)}\n`) 
     callback('...') 
     } 
    }); 
    }; 

    module.exports = WpAggregationPlugin; 

が再開：

を

... 
     if(changedFiles.length <= 0) { 
     callback() 
     } else { 
     process.stdout.write(`File modification detected :\n${JSON.stringify(changedFiles, null, 4)}\n`) 
     callback('...') 
     callback()  // EXTRA CALL 
     } 
    ... 

残念ながら、この方法では、Webpackのライフサイクルに影響を与えることなく、無色の文字列をstdoutに表示するだけです。

私が達成しようとしているのは、エラーが発生したときにエラーメッセージが表示され、バンドルビルドプロセスがvalidの状態になるのを防ぐためです。

警告管理について私は、プラグイン自体の中で直接着色してprocess.stdout.write()を呼び出すか、コンパイルパラメータで警告収集を行うかのどちらかで実行する必要があると思います。これは唯一の推測です：p

私はアプリケーション内で散らばっているすべての翻訳を1つのファイルに集約することを目標とする小さなビルドツールを作成しているので、この質問をします。私たちのクライアントが数十台ではなく一つの翻訳ファイルを扱うようにするためです。

これは「ワンショット」モードまたは時計モードで実行できますが、Webpackビルドプロセスのプラグインとしてこれを直接統合するのが最もよいと思います。

ウェブパックの新人として、私はこの「建築的」選択肢についてあなたの見解を伝えてください。私は間違いなくその可能性を全面的に受け入れていないと思います。 （この記事の主な理由ではないので、もちろん注意してください）

おかげさまで、あなたのヒントやトリックをお寄せいただきありがとうございます;）！

Answer 1

私は現在Webpackプラグインを作成しており、同じ問題が発生しています。私は参考のためにいくつかの既存のプラグインを見てみましたが、あなたと同じ結論に達しました：これのためのインフラはありません。一例として、抽出・テキストのWebPACK-プラグインを取る：

https://github.com/webpack-contrib/extract-text-webpack-plugin/blob/master/index.js

それは基本的にものを処理するためにconsole.warnとthrow new Errorを使用しています。エラーはcompilationオブジェクトにプッシュできますが、どのように処理されているのかわかりませんが、それは明らかに一部のエントリポイントでは使用できません。

Answer 2

最後に、Webpackコードのデバッグの半日後にこれをソートしました。

実際の契約はWebPACKのコンパイルのエラーコレクションをこのように供給することである。

compilation.errors.push(new Error('explain why the build failed'))

そしてもちろんのは関係なく、あなたのプラグインが失敗するかどうかcallback()に忘れてはいけません。

このerrors.push意志：

• 束
• を対処するためのWebPACK-DEV-サーバを防止STDOUT
• に赤で表示されるエラーメッセージは、WebPACKのヘッダに報告されたエラーメッセージを持ちましたあなたのアプリの代わりにクライアント/ブラウザ側の一部！ WebPACKのドキュメントがとてもラメであることだけは残念）

  ;

（あなたはもちろんのhttp://yourDN:yourPort/webpack-dev-serverを通してそれにアクセスした場合）、最新のポイントセッションをコーディングが再開する前に、そこにエラーを修正するために、あなたの開発者を強制するだけで完璧です... Webpack 2には困惑しているドキュメントの欠点がないことを願っています：p