現代のライブラリ開発ガイドシリーズのフロントエンド（B）：ライブラリを構築WebPACKの使い方

序文

以上、私は聴衆の中の記事のこのシリーズは、熟練した学生はビジネスのコードを書くので、WebPACKの構成を紹介この記事では、ライブラリ固有のコンフィギュレーションを構築するためにのみ言及、設定のWebPACKの残りの部分を参照してください。近代的なフロントエンドシステムであることを言いました公式文書。

製品の出力

最大の違いを構築するための一般的なアプリケーションとライブラリーの構築がされた製品の出力が完了した後に構築します。

一般的なアプリケーションの意志出力の建設が完了した後：

htmlファイル
JSは、複数のサブチャンクのチャンク入口
いくつかのCSSファイル
イメージ、フォントやその他のファイルなど、他のリソースの数

多くのリソースの出力が、実際にはすべての依存関係が、関係はhtmlファイルからロードされているが、他の言葉で、層ごとに落ち着くし始めるが、htmlファイルは、実際にはアプリケーション全体への入り口です。

ライブラリ意志出力の建設が完了した後：

CommonJSのjsファイル形式
jsが非圧縮形式ファイルUMD
jsが圧縮形式ファイルUMD
いくつかのCSSファイルを含むことができ
これは、他のリソースファイルの数を含むことができ

エントランスライブラリは、JSファイル上に記載されています。あなたはライブラリが3枚の入り口の書類を持っていますか疑問に思うかもしれませんか？門司は、私には一つ一つ聞きます。

CommonJS

CommonJS主に文法を含め、モジュラー仕様のNode.jsの実装でありmodule.exports、require()そのためには、（実際には、NPMパッケージを導入Node.jsの環境、見ることができ、このCommonJSエントリのjsファイル形式我々はWebPACKのを使用する場合と、<库名称>.common.js）使用のNode.jsの環境内の他のアプリケーションのためのNPMパッケージを導入しています。NPMパッケージボリュームを参照する場合は、一般的であるので、多くのファイルエントリが圧縮JSされないように、NPMパッケージ（アプリケーション、必要に応じて独自の圧縮を構築する）と考えられ、そしてデバッグを容易にするためではありません。

UMD

UMDは、互換性のCommonJSに加えて、モジュラー仕様の寄せ集めである、それにも対応AMDモジュラー仕様だけでなく、最も伝統的なグローバル変数モード。

ここではもう少しAMDの仕様について、AMDはスタンドAsyncchronousモジュール定義（これは最大の違いはCommonJSの仕様である）、ブラウザでの一般的なアプリケーションを、AMDローダーの最も有名なのはあるRequireJS。現時点では、理由の人気のWebPACKの、AMDこのモジュラーアプローチは、徐々に市場から撤退しています。

グローバル変数モード、それが十分に理解されては、（のようなグローバル変数にマウントするライブラリへの入り口であるwindow.xxx）、どこかのページに容易にアクセスすることができ、ローダプログラムをプラグインで最も伝統的なjsの一つです。

以上のことから、入口UMD JSファイルフォーマットは、参照シーンNPMパケット（圧縮されていないバージョンのために使用されてもよい<库名称>.umd.js）、それは（すなわち、圧縮されたバージョンのブラウザで直接使用することができます<库名称>.umd.min.js）。

異なるモジュラー仕様のライブラリーを構築する方法

現在、WebPACKのが生成され、同時に複数のエントリのjsファイルをサポートしていない、複数回を構築することが必要です。

キーWebPACKの構成は次のとおりです。

CommonJS：output.libraryTarget: "commonjs2"
UMD：output.libraryTarget: "umd"

UMDのために、我々はまた、グローバル変数名を設定する必要があり、それがありますoutput.library: "LibraryName"。

構築された圧縮ファイルを引き出すために、最も簡単な方法は、CLIでWebPACKのコマンドを呼び出すことですモードなどのパラメータ、webpack --mode=production;これは、モードの値があるときからですproductionWebPACKのが自動的に有効にすると、UglifyJsPluginソースの圧縮を。

バージョン情報を出力

私はすべてのアプリケーションと通過を使用するために検討されなければならないプロジェクトにおける第三者の使用に依存し、同社では、第三者の企業の依存度が非常に厳しい仕事;と、アプリケーションが特定のバージョンに正確であるとき、適用されません。ソフトウェアのバージョンもなく、使用されません。一部のサードパーティは、私たちは自分のライブラリーを開発教訓を学ぶ必要がある障害物を作成したファイルの内容かどうかに依存して、またはファイル名には、私たちが頼るように、このような第三者を識別し、この数の公表を反映していませんでしたA。

ライブラリーを構築するとき、私たちはこの「アイデンティティ」と、中のファイルの内容に直接リポジトリWebPACKの出力を使用することができ、ユーザーは、心の余分な平和を使用することができます。

Oライブラリのバージョン情報は、最も簡単に使用できるが、以下のようにしている、webpack.BannerPluginを使用することです。

const pgk = require('./package.json');
const banner = `
${pkg.name}
${pkg.description}\n
@version v${pkg.version}
@homepage ${pkg.homepage}
@repository ${pkg.repository.url}\n
(c) 2019 Array-Huang
Released under the MIT License.
hash: [hash]
`;

/* webpack 配置 */
{
    // ...其它配置
    plugins: [
        // ...其它 plugin 配置
        new webpack.BannerPlugin(banner);
    ]
}

最終的な効果が出て生成されます。

/*!
 * 
 * vue-directive-window
 * Vue.js directive that enhance your Modal Window, support drag, resize and maximize.
 * 
 * @version v0.7.5
 * @homepage https://github.com/Array-Huang/vue-directive-window
 * @repository git+https://github.com/Array-Huang/vue-directive-window.git
 * 
 * (c) 2019 Array-Huang
 * Released under the MIT License.
 * hash: dc6c11a1e50821f4444a
 * 
 */

ソースマップ

あなたのライブラリーのブラウザをロードすることにより、直接ユーザーベースを使用する場合は、提供元のマップライブラリをしても、圧縮後、WebPACKの後に構築されているので、これは、ソースコード、ファイルが非常に必要ですユーザーがブラウザでデバッグが困難になり、非常に異なっていた。しかし、あなたは彼のライブラリのソースマップを付加することができた場合、ブラウザの開発者向けツールは、ソースマップ、ユーザーエクスペリエンスが近いデバッグになりますヘルプ解決に呼び出されますソースコードライブラリをデバッグします。

WebPACKの対応に構成されました：

// webpack 配置
{
    // ...其它配置
    devtool: 'cheap-module-source-map'
}

WebPACKのソースマップ生成速度の異なるタイプのソースマップの複数のタイプをサポートし、サポート機能は、位置ずれやその他の問題をデバッグ異なる症状（例えばバベルなど）であり、私はお勧めしています。

開発環境：格安-モジュール-EVAL-ソース-地図
本番環境：安い-モジュール-ソース-地図

ソースマップの他のタイプについては、公式ドキュメントをdevtool WebPACKのセクションを参照してください。

サードパーティの依存の排除

一般的なアプリケーションとは異なり、ライブラリの開発に、我々はこれらのサードパーティのライブラリの大きさは、私たちは、ライブラリが急騰書くようになるので、（プロセスで使用されるビルドツールチェーンを除く）、サードパーティのライブラリを回避しようとしてください。そうこの処理が行われます。私たちは、kの数百人は、このようなライブラリはあまり重要ではないことを、あるライブラリから構築、コードのロジックのわずか数百行を記述するために、小さな機能を所有しています。

しかし、我々は、我々が行うことになっていることを、サードパーティのライブラリの使用を回避することは困難ですか？

// webpack 配置
{
    // ...其它配置
    externals: {
        lodash: {
            commonjs: 'lodash',
            commonjs2: 'lodash',
            amd: 'lodash',
            root: '_'
        }
    }
}

上記の構成を使用した後、私たちは図書館の増築の構成には含まれません（例えば、サードパーティのライブラリを指定lodash）、1つずつ、以下の内訳：

commonjsそして、commonjs2エントリーはNode.jsの環境では、現在のライブラリは、ユーザーが指定されているCommonJSの方法は、名前ロードするlodashNPMパッケージのを。
amdエントリーは、ブラウザでライブラリの実行をロードするとき、ライブラリがしようと示しAMD名付けロードするための方法lodashAMDモジュールを。
rootエントリーは、ブラウザでライブラリの実行をロードするとき、ライブラリはグローバル変数を取るしようとします示しwindow._（によって<script>タグの読み込みlodash.js、lodashは、グローバル変数に身を注入する時間window._で）。

そして、一般的なアプリケーションの構成は同じ外観ではありません

典型的なアプリケーションでは、あなたは、このような外観の設定が表示されることがあります

// webpack 配置
{
    // ...其它配置
    externals: {
        lodash: '_'
    }
}

このような外観の設定手段：何があっ環境は、取るべきで_グローバル変数を、現在のアプリケーションは、一般的に使用されていると判定された場合<script>など、指定されたサードパーティのライブラリ（ロードするためのjQuery、Vueのは非常に頻繁にあるコアライブラリを、負荷へのこのようは）、当然のことながら、そのような直接の使用を持っている可能性があり、私たち、著者ライブラリは、よりリラックスして、より柔軟な使用を提供する必要がありますよう。

完全な構成例をWebPACKの

異なる仕様のモジュール構造は、（実際には、わずかに異なる）だけのために、このように複数回、構築するために異なるWebPACKのライブラリの設定を必要にUMDのフォーマットを構築し、圧縮された最も簡単なWebPACKの構成例を示すシーンを、もしより効率的スプライシングのWebPACKの設定、確認する方法を知りたいマイクロスキーマ・バリプロジェクトWebPACKのプロファイルを：

// webpack.config.js
const webpack = require('webpack');
const pkg = require('./package.json'); // 把 package.json 作为信息源
const banner = `
${pkg.name}
${pkg.description}\n
@version v${pkg.version}
@homepage ${pkg.homepage}
@repository ${pkg.repository.url}\n
(c) 2019 Array-Huang
Released under the MIT License.
hash: [hash]
`;

module.exports = {
  entry: `${__dirname}/index.js`,
  devtool: 'cheap-module-source-map',
  output: {
    path: `${__dirname}/dist`, // 定义输出的目录
    filename: 'micro-schema-validator.min.js', // 定义输出文件名
    library: 'MicroSchemaValidator', // 定义暴露到浏览器环境的全局变量名称
    libraryTarget: 'umd', // 指定遵循的模块化规范
  },
  /* 排除第三方依赖 */
  externals: {
    lodash: {
      commonjs: 'lodash',
      commonjs2: 'lodash',
      amd: 'lodash',
      root: '_'
    }
  },
  module: {
    rules: [
      {
        test: /(\.jsx|\.js)$/,
        loader: 'babel-loader',
        exclude: /(node_modules|bower_components)/
      },
      {
        test: /(\.jsx|\.js)$/,
        loader: 'eslint-loader',
        exclude: /(node_modules|bower_components)/
      }
    ]
  },
  plugins: [
    new webpack.BannerPlugin(banner) // 输出项目信息
  ]
};

Vueの-CLIの使用のカスタム設定と管理のWebPACK

このような構成は、コンテンツ備えるをカスタマイズすることができWebPACKのニーズに合わせて調整することがアセンブリのVue、Vueのカスタムコマンドなど、VUE-CLI（特に3.0バージョンここVUE-CLI）を使用することができるように生態Vueのライブラリについて：

かどうかはバベルを有効に
アクセス活字体文法かどうか
PWAをサポートするかどうか
かどうかヴュー・ルータとVuex
サス/以下/スタイラスを備えたCSSプリプロセッサ、および必要に応じて特定のCSSプリプロセッサかどうか
かどうかESLintときれい
アクセスユニットと試験終了が終了するか否かをテストする（E2E）

カスタム終了した後、VUE-CLIは実行可能な種子プロジェクト、生成する（ローカルの開発を含むが、パッケージの制作環境を構築）しますが、実際のコンテンツ（実際のコンテンツは、ハハさてあなたに記述する必要はありません）。WebPACKの構成を生成することに加えて、一般的な足場ツール、VUE-CLIと比較し、またなど、管理し、維持し続けます。

過去には、我々はカスタム構成を達成するためにあったが、多くの場合、直接修正する足場ツールのWebPACK構成から直接生成され、これは改正につながる非常に散乱され、それが困難なカスタムのために作る、統一されたカスタム設定へのアクセスを提供多重他のプロジェクトでWebPACKの構成; VUE-CLIを使用しながら、WebPACKの構成の変更のすべてが集中する（vue.config.js）、それを再利用する必要があるまでこれらのカスタム設定ファイルの直接移行をポイントに管理されています他のプロジェクトとすることができます。
連続更新機構WebPACKの構成を提供することと、私は自分の目的のためのオープンソースのライブラリを持って前に、今、私はオープンソースのライブラリよい脚本をアップグレードする必要がある場合、それはなるので、ソースコードを変更し、その理不尽な場合作るの変更が上書きされ、原因の統一入学カスタム設定に、同様に利用可能VUE-CLIを、プロジェクト（プロジェクトがかなりのWebPACKよりVUE-CLIコマンドを実行することによって実行される）たびにするときに実行される動的なレンダリングのWebPACK設定可能なので、WebPACKのプロジェクト構成は、絶えずアップグレードVUE-CLIでアップグレードすることができます。
それは継続的に更新WebPACKのツールチェーンのためのメカニズムを提供し、我々はすべて知っている、WebPACKのツールチェーンは、バベル、ESLintなどのサードパーティのオープンソースのライブラリを多数含まれ、これらのオープンソースライブラリはプロセスで、常に更新の中でもあり、必然的に生産するために継続されますブレーキングの変更、それだけで幸いVUE-cliのアップグレードは - 常に最新のサードパーティ製のオープンソースライブラリを適応させる目的を達成するためにWebPACKの構成を見直し、そして私たちのプロジェクトはまた、GET WebPACKの最小価格（アップグレードVUE-CLI自体）することができ常に更新ツールチェーン。

VUE-cliのカスタム構成例

撮影VUE-指令-ウィンドウ vue.config.jsプロジェクトファイルを：

const webpack = require('webpack');
const pkg = require('./package.json');

const banner = `
${pkg.name}
${pkg.description}\n
@version v${pkg.version}
@homepage ${pkg.homepage}
@repository ${pkg.repository.url}\n
(c) 2019 Array-Huang
Released under the MIT License.
hash: [hash]
`;

module.exports = {
  chainWebpack: config => {
    config.output.libraryExport('default');
    config.plugin('banner').use(webpack.BannerPlugin, [
      {
        banner,
        entryOnly: true,
      },
    ]);
  },
};

上記よりさらに簡単であるように思われるが、最も基本的なWebPACKの構成ではないでしょうか？プロジェクトの構造が徐々に濃縮すると、このギャップが広がっていきます。

私はより多くの技術的な記事を読みたいですか？私はGitHubのブログに行くアレイ・黄/ブログあなたのための助けがあれば、（〃^ω^）スター・時計ボーハをしてください、に