webpack用のプラグインを作成する

すでにハブ上のwebpackについて書いてmoscowjsについて話しました。webpackの一般的な機能、その長所と短所を説明する他のリソースに関する記事がいくつかあります。



したがって、この記事ではwebpack自体について簡単に説明し、プラグインの開発について詳しく説明します。









1. Webpackについて簡単に



人気のあるgruntやgulpなどのビルドシステム用に多数の補助ライブラリが記述されていますが、webpackは現時点ではそのような豊富さを誇っていません。必要なライブラリを使用できることは素晴らしいことです。 プロジェクトにwebpackを実装することを決めたが、既成のソリューションがない場合、解決方法は1つしかありません-自分で書いてください。



それで、webpackとは何ですか、その機能は何ですか、それはどのように機能しますか？



開発者自身がWebpackを配置しているため（ http://webpack.github.io ）、Webpackはモジュールバンドラーです。







箱から出して、AMD、CommonJS、およびES6モジュールをサポートします。webpack-dev-serverアドオンに実装され、socket.ioを介して動作するライブreload'aの可能性があります。 つまり、ソースファイルに変更を加えた後、毎回ビルドコマンドを再度実行する必要はありません。



また、webpackの設定はかなりシンプルで、gulpほど透明ではありませんが、簡潔で洗練されています。



用語：



2.ローダーとプラグイン



ローダーは、ファイルのダウンロード、処理、変換に使用される強力なツールです。 つまり プロジェクトで、たとえば、ヒスイ、sass、coffee、es6などのテクノロジーを使用している場合、またはsvgが大きすぎて圧縮する必要がある場合-処理、変換、縮小のすべてのタスクはローダーによって解決されます。 それらの多くはすでに書かれています 。 ここで見つけることができます。



ローダーの作成は簡単です。 これを行うために、プロジェクトの公式ウェブサイトに別のセクションがあります- ローダーを書く方法、そして一般に、コードの最初の行で、それがどれほど簡単かすぐに理解できます：

// Identity loader module.exports = function(source) { return source; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

 // Identity loader with SourceMap support module.exports = function(source, map) { this.callback(null, source, map); };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Loaderはmodule.exports関数で、ファイルの内容を入力として受け取り、処理の結果を返します。また、構成に必要な属性が存在する場合、sourcemapを返すこともできます。



現在のコンテキストを返すと、連鎖を使用することが可能になります。 したがって、それぞれが1つのタスクのみを実行する必要があります。Webpack開発者は、各ステップに個別のローダーを作成することをお勧めします。 一般に、これは各モジュールがカプセル化されている場合の一般的なモジュールイデオロギーであり、これにより、これを操作してデバッグを実行するのがはるかに簡単になります。



プラグインは、コンパイラーという1つのパラメーターのみを持つapplyメソッドを持つオブジェクトです。 それを介して、webpack'aをコンパイルするさまざまな段階と通信できます。 必要な変換を実行します。さまざまなタイプのプラグインインターフェイスもあります。例として、次のコードが公式Webサイトで提供されています。

 compiler.plugin("compile", function(params) { // Just print a text console.log("Compiling..."); });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プロジェクトをビルドするタスクを開始すると、ターミナルで、現在のビルドプロセスに関するメッセージ、または必要なライブラリの不足が原因のエラー、またはコード構文の問題に関連するエラーが表示されます。



webpackを使用してビルドプロセスを開始すると、コードが機能し、ターミナルに「Compiling ...」と表示されます。



外見上、これは理解できる仕組みですが、そのような作業の例はほとんどなく、ドキュメントには実際には例がありません。



部分的に、これは記事を書くように促しました。 ローダーセクションの記述方法にはローダーの多くの例がありますが、プラグインセクションの記述方法は公式サイトから無期限に非表示になっています（場合によっては完全に削除されます）。 概して、いわゆるインターフェイスタイプの作業のリストとテキスト説明（ upd ：現在、このセクションは非表示になっています）と、すでに作成されたプラグインのコードを調査する機能のみがあり、それがどのように使用され動作するかを確認できます



もちろん、webpack開発者がこのセクションをすぐに提供することは間違いありませんが、現在の問題を解決するためにこのトピックを今すぐ理解しようとし、セクションを開くと、自分自身のために新しいものを見つけ、おそらく完全に作業を再考しますプラグイン。



3.問題の解決例-svgスプライトの接着



Webpackは数年前から存在していますが、多くの人がプロジェクトを操作するためのメインツールとして使用することを敢えてしていません。その機能は素晴らしく、モジュールの組み立てと操作の両方のツールをすぐに置き換えることができます。



そして、ウェブパックのメカニックのためのすべてのタスクとプラグインと一緒にうなりやむちになるプロジェクトを書き直すのは15分ではありません。 特に、これまでのところ、古い実行中のビルドシステムが誇ることができるwebpackの下には多くのライブラリがないことを考慮してください。



これに決めて、プロジェクトの更新を開始したとします。 そして、この過程で、上記の問題に出くわす可能性があります。webpack'eには、以前プロジェクトにあり、完全に機能していたタスクの同様のメカニズムを複製または実行するツールが存在しない場合があります。



これはgrunt-svgstoreで発生しました -必要なディレクトリからすべてのsvgを1つのスプライトに収集し、 use xlink：href =“＃logo”を使用して必要なsvgをページの適切な場所に接続するライブラリ



これは、スプライトを介してsvgを操作するための非常に便利なメカニズムであり、移行中にこの機能を失いたくありません。

gulpの下にも同様のソリューションがありますが、webpackの下で見つけることはできませんでした。

これが問題であり、Webpack用のプラグインを作成し、svgスプライトを接着するための一般的な仕組みを維持し、場合によってはいくつかの新しい機能を追加することです。



4.コードを書くプロセス



執筆を始めるためには、誰かのコードを盗んでそれを私たちのコードとして偽装することは私たちの目標ではないことを理解することが重要です。しかし、常に限られている時間を考えると、車輪を再発明する気もありません。



したがって、ここでこの方法を使用します。grunt-svgstoreライブラリコードをベースとして、Webpackのプラグインとして機能するように少し変更し、いくつかの新機能を追加します。一方、プラグインコードの最上部では、全体を示します。

 /** * Webpack SVGstore plugin based on grunt-svg-store * @see https://github.com/FWeinb/grunt-svgstore/blob/master/tasks/svgstore.js */
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

したがって、私たちはだれかを欺いたり、不平を言ってsvgstoreを書いた開発者を怒らせたりしません。 一般に、このプラグインは特定のプロジェクトで1回だけ使用するためではなく、npmでレイアウトして成功した結果、オープンソースコミュニティに貢献するために取り上げました。



タスクのコードをプラグインに変換するには、実際にコードからすべてのうなり声を削除し、svgをスプライトに直接組み立てて接着するための既製のメカニズムのみを保持します。 しかし、その後、修正する必要がある多くの問題に遭遇します。



5.予期しない問題



1）スプライトが大きすぎるため、縮小を追加する必要があります。



最初に見つかったのは、webpackの下に、すべてのsvgを駆動できるsvgoのフードの下に既製のsvgローダー（https://github.com/rpominov/svgo-loader）があることです。



プラグインでsvgoモジュールを接続します。

 var SVGO = require('svgo');
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、svgの縮小関数を追加します。

 SvgStore.prototype.svgMin = function(file, loop) { var svgo = new SVGO(); var source = file; var i; function svgoCallback(result) { source = result.data; } // optimize loop for (i = 1; i <= loop; i++) { svgo.optimize(source, svgoCallback); } return source; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ミニファイにより一部のsvgが損なわれる可能性があります。また、新しいsvgを追加するプロセスで人件費が最小限になるように努めています。 これを実現するには、 min：true / falseプラグインにオプションを追加します。これにより、特定のsvg'shkiを縮小するか、すべてのsvgをそのままの形で正確に収集するかどうかがわかります。



スプライトのサイズは重要であり、サイズが小さいほど自然に優れています。 しかし、すべての縮小を完全に拒否することはあまり正しくないため、svgの内部ディレクトリを追加することにしました。 たとえば、svgを使用したディレクトリへのパス：

/アプリ/アセット/ svg

そして、サブディレクトリに縮小したいsvgを入れます：

/アプリ/アセット/ svg /分

したがって、内部のminディレクトリにあるsvgのみを縮小し、複数のアイコンが破損する場合はすべての縮小を拒否します。必要はありません。



ニュアンスもあります。これは、関数が2つのパラメーターを取り、その1つがsvgの内容であり、2番目が-ループであるためです。

実際、svgの利点の1つは、CSSを使用して画像のスタイルを制御し、色、線幅などを変更できることです。



しかし、最初の実行後、svgoはインラインスタイルを削除しません。そのため、CSSを使用してスタイルを再定義することはできません。 たとえば、色をホバーに変更する必要がある場合、これは場合によっては機能しません。 ただし、2回実行すると、これらの属性は消去され、再定義が機能し始めます。



当然、誰もがこれを必要とするわけではないため、デフォルトではループオプションは1（1回の実行）に等しくなりますが、svgoを介して任意の数の実行を設定できます。



2）プラグインを使用して複数のスプライトを収集する必要があります。 これは、かなり原始的なプリフィックスを使用して実装され、あまり美しくない（ただし機能する）コードではなく、オプションはフィルターと呼ばれ、次のように機能します。



1. 'except-name'-値がexcept-で始まる場合、この場合はnameで始まるものを除き、すべてのsvgがスプライトに収集されます

2. 'name'-svgはスプライトに収集されます。スプライトは指定された行（この場合はname）で始まります。

 output: [ { filter: 'Logo-', sprite: 'svg/[hash].logo_sprite.svg' }, { filter: 'except-Logo-', sprite: 'svg/[hash].sprite.svg' } ]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

3. 'all'-何も共有する必要がなく、すべてのsvgが配置される出力で1つのスプライトのみを取得する場合。

 output: [ { filter: 'all', sprite: 'svg/[hash].sprite.svg' } ]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

フィルターに加えて、すべてのアセットが移動するディレクトリも示し、[hash]オプションも追加されました。 ハッシュ方法自体では、再び自転車を発明しませんでしたが、暗号モジュールが使用する最も標準的なハッシュ方法を採用しました。

 Name.replace('[hash]', crypto.createHash('md5').update(source).digest('hex'))
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

当初、収集されたスプライトにハッシュを追加することは計画されていませんでした。なぜなら、webpackがそのようなことを行うように思われ、私たちのタスクは、ハッシュを追加する前にコンパイルされたスプライトをスリップすることであり、残りはコレクターによって行われるからです しかし、残念ながら、それを機能させるのは機能しなかったので、プラグイン内にハッシュを追加します。



3）別の大きな問題は、収集されたスプライトをマニフェストに追加することです。



マニフェストは、アセットの名前と収集された名前との対応をハッシュとパスで示すJSONです。 各アセンブリのハッシュがわからないため、これはアセットを接続するために行われます。 マニフェストを使用して、便利なリンクテーブルを取得します。 このために、webpackのマニフェストプラグインを使用します 。



このマニフェストにより、プロジェクトの裏側は、新しいビルド後に接続する必要があるものを理解します。

そして、ここで私たちが遭遇したもう1つの問題があります。コンパイラーは2つのオブジェクトを提供し、そのうちの1つはアセットの配列、2番目はモジュールです。

そして、プラグイン内にアセットを追加した後

 compiler.plugin('emit', function(compilation, callback) { compilation.assets[key.sprite] = { source: function() { return new Buffer(source); }, size: function() { return Buffer.byteLength(source, 'utf8'); } }; callback(); });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

compiler.assets配列に表示されますが、この配列はファイル名とハッシュ付きのパスとの一致を提供しません。



そのため、manifest-webpackプラグインを作成した開発者は、プラグイン内でcomiler.assetsではなくcompiler.modulesを使用しますが、2番目の方がはるかに論理的です。



つまり Tobiasが 提案したコードの例（webpack開発者の1人）に従って新しいアセットを追加した後、このアセットはアセット配列に表示されますが、この配列には元の名前またはパスが含まれていないため、使用できません。



プル配列を介して名前のフィールドを挿入して、assets配列を使用してマニフェストを作成できるようにしましたが、受け入れられませんでした。 そして一般的に、この考えは拒否されました。



これにより、新しく作成したスプライトをマニフェストに追加するという問題が発生しました。この段階では、最終段階でプラグインを介してプラグインを手動で操作する必要があります。

 compiler.plugin('done', function(compilation, callback) { // code })
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、手でfs.readFile / fs.writeFileを通してスプライトをマニフェストに追加します。これは良くありません。



6.使用例と展望



リンクを使用して、Webpackプロジェクトでプラグインを作成して試してみることができます。



将来的には、プラグインを最も汎用性の高いものにし、コードをリファクタリングし、余分なものをすべて削除し、テストでその作業をカバーすることを計画しています-一般に、少なくとも必要なものを残し、可能な限り安定させる



7.参照



プラグインの結果を使用したデモ-motor.ruのすべてのアイコン

プラグインリポジトリ（問題とプルリクエストを待っている） -github.com/lgordey/webpack-svgstore-plugin

NPMプラグイン-www.npmjs.com/package/webpack-svgstore-plugin

Webpackドキュメント-webpack.github.io/docs

Webpackリポジトリ-github.com/webpack/webpack