webpackを使用してjsライブラリを構築する-jsチュートリアル-php.cn

はじめに

前回の記事で、この一連の記事の対象読者は、最新のフロントエンドシステムでビジネスコードを書くことに熟練している学生であると述べました。この記事ではライブラリの構築についてのみ言及していますが、独自の構成なので、他の構成については webpack 公式ドキュメントを参照してください。

出力プロダクト

ライブラリの構築と一般的なアプリケーションの構築の最大の違いは、ビルド完了後の プロダクト出力にあります。

一般的なアプリケーションが構築されると、次の出力が行われます:

1 つの HTML ファイル
1 つの js エントリチャンク、いくつかのサブチャンク
いくつかの CSS ファイル
画像、フォントファイルなど、その他のいくつかのリソース

##多くの出力リソースがありますが、実際には、すべての依存関係と読み込み関係は HTML から始まります。つまり、この HTML ファイルがアプリケーション全体への入り口となるのです。

ライブラリが構築されると、以下が出力されます:

UMD 形式の非圧縮 js ファイル
圧縮された UMD 形式の js ファイル
には複数の css ファイルが含まれる場合があります
他のいくつかのリソースファイルが含まれる場合があります

ライブラリへの入り口は js ファイルの上にリストされています。ライブラリに 3 つのエントリファイルがあるのはなぜだろうかと疑問に思われるかもしれません。焦らないで、聞いてください。

CommonJS

CommonJS は、Node.js によって推進されるモジュール仕様です。主な構文には、module.exports、require() が含まれます。 など; webpack を使って npm パッケージを導入すると、実際には Node.js 環境になるので、CommonJS 形式のエントリー js ファイル (<ライブラリ名>. common.js ) は、Node.js 環境に npm パッケージを導入するために他のアプリケーションによって使用されます。一般に、npm パッケージを参照するときに npm パッケージのサイズはあまり考慮されないため (独自のアプリケーションを構築するときに必要に応じて自分で圧縮できます)、デバッグの便宜のため、js エントリファイルは圧縮されません。

UMD

UMD はモジュール仕様の寄せ集めです。CommonJS との互換性に加えて、AMD モジュール仕様とも互換性があります。、最も伝統的なグローバル変数モードと同様に。

ここでは AMD 仕様について簡単に紹介します。AMD の正式名は

Asynchronous Module Definition です。通常はブラウザ側で使用されます (これが CommonJS 仕様との最大の違いです) ). 最も有名な AMD ローダーは RequireJS です。現在、Webpack の人気により、AMD のモジュラーソリューションは市場から徐々に撤退しています。

グローバル変数モードは理解しやすく、ライブラリエントリをグローバル変数 (window.xxx など) にマウントします。場所は任意です。いつでもアクセスできます。これは、最も伝統的な JS プラグイン読み込みソリューションです。

上記からわかるように、UMD 形式のエントリ js ファイルは、npm パッケージ (非圧縮バージョン、つまり

<ライブラリ名>.umd.js) を参照するために使用できます。 ) は、ブラウザ側で直接使用することもできます (圧縮バージョン、つまり <ライブラリ名>.umd.min.js)。

異なるモジュール仕様でライブラリファイルをビルドする方法

現在、webpack は複数のエントリ js ファイルを同時に生成することをサポートしていないため、複数回ビルドする必要があります。

主要な Webpack 構成は次のとおりです:

output.libraryTarget: "commonjs2"
output.libraryTarget : "umd"

UMD の場合、グローバル変数名、つまり

output.library: "LibraryName" を設定する必要もあります。

ビルドされたファイルを圧縮するための最も簡単な方法は、

webpack --mode=production## など、mode パラメーターを使用して CLI で webpack コマンドを呼び出すことです。 #; これは、mode の値が production の場合、webpack が UglifyJsPlugin を自動的に有効にしてソースコードを圧縮するためです。出力バージョン情報

私が会社で働いていたとき、その会社はサードパーティの依存関係について非常に厳格でした。プロジェクトで使用されるすべてのサードパーティの依存関係は申請され、承認される必要がありました。使用でき、アプリケーションは特定のバージョンに対して正確であり、適用されていないソフトウェアバージョンは使用できません。一部のサードパーティの依存関係には、ファイルの内容にもファイル名にもバージョン番号が反映されていないため、そのようなサードパーティの依存関係を識別するのに障害が生じます。これは、独自のライブラリを開発するときに考慮する必要がある警告です。。

ライブラリを構築する際、webpackを利用することでライブラリ情報をファイル内容に直接出力することができ、この「識別情報」があれば、ユーザーはより安心して利用することができます。

ライブラリのバージョン情報を出力する方法は、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
 * 
 */

ログイン後にコピー

source map

如果库的用户是直接通过在浏览器里加载你的库来使用的话，那么提供一份 source map 文件是非常有必要的；这是因为你的库在经过 webpack 构建，甚至压缩后，与源代码已经大相径庭了，用户将难以在浏览器中进行调试；但如果你能为自己的库附上一份 source map ，浏览器开发者工具会调用 source map 来帮助解析，用户的调试体验会更接近于调试库的源码。

相应的 webpack 配置为：

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

ログイン後にコピー

webpack 支持多种类型的 source map ，不同类型的 source map 在生成速度、支持功能（如 babel ）、调试位置偏移等问题上均有不同表现，我这边只做推荐：

开发环境：cheap-module-eval-source-map
生产环境：cheap-module-source-map

关于其它类型的 source map ，请查看 webpack 官方文档的 devtool 章节。

排除第三方依赖

与一般应用不一样，在开发库的时候，我们应尽量避免引入第三方库（构建过程中使用的工具链除外），因为这些第三方库会让我们写的库的大小猛增；很可能会出现这样的情况：我们自己写的小功能只有几百行代码的逻辑，构建出来的库却有几百k，那这样的库意义就不大了。

但我们的确也很难避免使用第三方库，那该咋办呢？

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

ログイン後にコピー

使用上述配置后，我们构建出来的库中就不会包含配置中指定的第三方库（例子中为lodash）了，下面来一一详解：

commonjs和commonjs2项都是指明用户在 node.js 环境下使用当前库时，以 CommonJS 的方式来加载名为lodash的 npm 包。
amd项表示在浏览器中加载运行本库时，本库会试图以 AMD 的方式来加载名为lodash的 AMD 模块。
root项表示在浏览器中加载运行本库时，本库会试图取全局变量window._（通过<script>标签加载lodash.js时， lodash 会把自己注入到全局变量window._中）。

与一般应用不一样的 externals 配置

在一般应用中，你或许会看到这样的 externals 配置：

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

ログイン後にコピー

这样的 externals 配置方式意味着：无论在什么环境，都要取_这个全局变量；如果当前是在一般应用且确定已经使用<script>来加载指定的第三方库（比如 jQuery、 Vue 等核心库，的确很常以这种方式来加载），当然大可直接这样用；但我们作为库的作者，应提供更宽松更灵活的使用方式。

完整的 webpack 配置示例

由于构建不同模块化规范的库需要不同的 webpack 配置（其实也只是稍有不同）来进行多次构建，因此本文只针对构建 UMD 格式且已压缩这一场景来展示最简单的 webpack 配置示例；如果想知道如何更有效率地拼接 webpack 配置，请看 micro-schema-validator 项目的 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 配置

对于 Vue 生态的库，如 Vue 组件、Vue 自定义指令等，可以使用 vue-cli （本文特指 vue-cli 3.0 后的版本）根据你的需求来定制 webpack 配置，可定制内容包括：

是否启用 Babel
是否接入 TypeScript 语法
是否支持 PWA
是否使用 Vue-Router 和 Vuex
是否使用 CSS 预处理器，并可选择具体的 CSS 预处理器，包括 Sass / Less / Stylus
是否使用 ESLint 和 Prettier
是否接入单元测试和端对端测试(E2E)

定制完成后， vue-cli 将生成一个种子项目，该项目可执行（包括本地开发和构建生产环境的包）但没有实际内容（实际内容不还得由你来写嘛哈哈）。与一般的脚手架工具相比， vue-cli 除了可以生成 webpack 配置外，还将持续对其进行管理和维护，如：

提供一个统一的自定义配置的入口；过往，我们为了达到自定义配置的目的，往往会直接在脚手架工具生成出来的 webpack 配置上直接进行修改，这样会导致修改点非常分散，难以让自定义的 webpack 配置在其它项目复用；而使用 vue-cli 后，所有对 webpack 配置的修改点都被集中管理起来了，需要复用的话，直接把这自定义配置文件(vue.config.js)迁移到别的项目即可。
提供持续更新 webpack 配置的机制；假如现在有一个开源库，我为了达到自己的目的，肆意在库源码上修改，那么当我需要升级该开源库的时候可就犯难了，因为这会把我之前做的修改都覆盖掉；同理可得，vue-cli 由于统一了自定义配置的入口，并且是在每次运行项目（运行项目也是通过执行 vue-cli 的命令而非 webpack）时动态渲染 webpack 配置的，因此项目的 webpack 配置可以随着 vue-cli 的升级而不断升级了。
提供持续更新 webpack 工具链的机制；众所周知， webpack 工具链中包含了大量的第三方开源库，如 Babel 、ESLint 等，这些开源库也都是在不断更新当中，在这个过程中，必然会不断产生 Breaking Change ，所幸 vue-cli 通过自身升级——不断修改 webpack 配置来达到适配最新版第三方开源库的目的，而我们的项目也可以以极小的代价（升级 vue-cli 本身）来获取 webpack 工具链的不断更新。

vue-cli 自定义配置示例

摘自 vue-directive-window 项目的 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 配置还要简洁呢？当项目的架构逐渐丰富起来后，这个差距将不断拉大。

实例项目代码介绍

在我的工作生涯中，我写的绝大部分库都是为公司的项目写的，很可惜无法带出来，但我会以我最近写的两个开源库：javascript-library-boilerplate 和 vue-directive-window 来作为实例项目代码来辅助介绍。

javascript-library-boilerplate

javascript-library-boilerplate 是一个现代前端生态下快速构建 javascript 库的脚手架（或称种子项目，或称示例代码，看你理解了），本库支持 GitHub 的 repository templates 功能，你可以直接在项目首页点击 Use this template 来直接套用本脚手架的代码来创建你自己的 javascript 库。