深入了解Webpack 5

2021-04-18  本文已影响0人  魂斗驴

Webpack的开发和生产构建

本质上，有两种构建JavaScript应用程序的模式：开发和生产。以前，您已使用开发模式在本地开发环境中开始使用Webpack Dev Server。您可以更改源代码，Webpack再次将其捆绑，Webpack Dev Server会在浏览器中向您显示最新的开发版本。

但是，最终您希望拥有在Web服务器上的生产环境中部署Web应用程序所需的所有构建文件。由于Webpack将所有JavaScript源代码捆绑到一个dist / index.html文件中链接的bundle.js文件中，因此从本质上讲，您只需要Web服务器上的这两个文件即可向任何人显示Web应用程序。让我们看看如何为您创建两个文件。

首先，您已经有了dist / index.html文件。如果打开它，您已经看到它使用了webpack创建的bundle.js文件，该文件是src /文件夹中所有JavaScript源代码文件中的文件。

<!DOCTYPE html>
<html>
  <head>
    <title>Hello Webpack bundled JavaScript Project</title>
  </head>
  <body>
    <div>
      <h1>Hello Webpack bundled JavaScript Project</h1>
    </div>
    <script src="./bundle.js"></script>
  </body>
</html>

其次，如果键入npm start，则Webpack将动态创建此bundle.js文件，该文件将用于Webpack Dev Server在开发模式下启动您的应用程序。您从未真正看到过bundle.js文件。

{
  ...
  "scripts": {
    "start": "webpack serve --config ./webpack.config.js --mode development",
    "test": "echo \"Error: no test specified\" && exit 0"
  },
  ...
}

现在，让我们介绍第二个npm脚本，以实际构建用于生产的应用程序。我们将显式使用Webpack而不是Webpack Dev Server来捆绑所有JavaScript文件，重用以前的相同Webpack配置，还介绍了生产模式：

{
  ...
  "scripts": {
    "start": "webpack serve --config ./webpack.config.js --mode development",
    "build": "webpack --config ./webpack.config.js --mode production",
    "test": "echo \"Error: no test specified\" && exit 0"
  },
  ...
}

如果运行npm run build，您将看到Webpack如何为您捆绑所有文件。一旦脚本经历了成功，你可以看到DIST / bundle.js在飞行中不生成的文件，但在你真正的创建DIST /文件夹。

剩下的唯一事情就是现在将dist /文件夹上传到Web服务器。但是，为了在本地检查dist /文件夹是否具有在远程Web服务器上运行应用程序所需的一切，请使用本地Web服务器亲自进行尝试：

npx http-server dist

它应该输出一个URL，您可以在浏览器中访问它。如果一切正常，您可以将dist /文件夹及其内容上载到Web服务器。

另请注意，Webpack开发和生产模式具有其自己的默认配置。开发模式在创建源代码文件时会考虑改善的开发人员体验，而生产版本会对源代码进行所有优化。

如何管理您的Webpack构建文件夹

每次运行npm run build，您都会看到Webpack使用dist / bundle.js文件创建新版本的bundle JavaScript源代码。最终，您的Webpack构建管道将变得更加复杂，并且最终在dist /文件夹中包含两个以上的文件。突然，文件夹变得一团糟，因为您不知道哪些文件属于最新版本。最好的办法是，在每个Webpack构建中都从一个空的dist /文件夹开始。

假设我们要在每个Webpack构建中擦除dist /文件夹。这将意味着我们自动生成的dist / bundle.js文件将被删除（好），而我们手动实现的dist / index.html文件将被删除（不好）。我们不想为每个Webpack构建都手动重新创建此文件。为了自动生成dist / index.html文件，我们可以使用Webpack插件。首先，从项目的根目录安装html-webpack-plugin插件作为dev依赖项：

npm install --save-dev html-webpack-plugin

成功安装后，在Webpack webpack.config.js文件中引入Webpack插件：

const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');
 
module.exports = {
  entry: path.resolve(__dirname, './src/index.js'),
  module: {
    rules: [
      {
        test: /\.(js)$/,
        exclude: /node_modules/,
        use: ['babel-loader'],
      },
    ],
  },
  resolve: {
    extensions: ['*', '.js'],
  },
  output: {
    path: path.resolve(__dirname, './dist'),
    filename: 'bundle.js',
  },
  plugins: [new HtmlWebpackPlugin()],
  devServer: {
    contentBase: path.resolve(__dirname, './dist'),
  },
};

现在，npm run build再次运行，看看它如何自动生成一个新的dist / index.html文件。它带有一个默认模板，用于说明文件的结构方式和文件中应包含的内容。但是，如果要为dist / index.html文件提供自定义内容，则可以自己指定模板：

const HtmlWebpackPlugin = require('html-webpack-plugin')
 
module.exports = {
  ...
  plugins: [
    new HtmlWebpackPlugin({
      title: 'Hello Webpack bundled JavaScript Project',
      template: path.resolve(__dirname, './src/index.html'),
    })
  ],
  ...
};

然后，在您的源代码文件夹中创建一个新的src / index.html模板文件，并为其提供以下内容：

<!DOCTYPE html>
<html>
  <head>
    <title><%= htmlWebpackPlugin.options.title %></title>
  </head>
  <body>
    <div>
      <h1><%= htmlWebpackPlugin.options.title %></h1>
 
      <div id="app">
    </div>
  </body>
</html>

请注意，您不再需要使用bundle.js文件指定script标记，因为Webpack会自动为您引入脚本标记。还要注意，您不一定需要id属性和div容器，但在上一教程中我们已使用它在其上执行一些JavaScript。

现在，npm run build再次运行，查看新的自动生成的dist / index.html是否与src / index.html中的模板匹配。最后，我们已经能够使用Webpack自动创建dist / bundle.js和dist / index.html这两个文件。这意味着我们可以在每个Webpack版本中删除dist /文件夹中的内容。为此，请引入clean-webpack-plugin插件：

npm install --save-dev clean-webpack-plugin

然后在您的webpack.config.js文件中引入它：

const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');
const { CleanWebpackPlugin } = require('clean-webpack-plugin');
 
module.exports = {
  ...
  plugins: [
    new CleanWebpackPlugin(),
    new HtmlWebpackPlugin({
      title: 'Hello Webpack bundled JavaScript Project',
      template: path.resolve(__dirname, './src/index.html'),
    }),
  ],
  ...
};

现在，每个Webpack构建都将擦除dist /文件夹的内容，然后从头开始创建新的dist / index.html和dist / bundle.js文件。通过这种方式进行设置，您将永远不会在dist /文件夹中找到来自较旧Webpack构建的文件，这非常适合仅将整个dist /文件夹投入生产。

注意：如果使用的是GitHub之类的版本控制系统，则可以将构建文件夹（dist /）放入.gitignore文件中，因为无论如何，所有内容都是自动生成的。某人获得您的项目的副本后，该人可以执行npm run build以生成文件。

Webpack source map

Webpack捆绑了所有JavaScript源代码文件。但这很完美，但是它给我们作为开发人员带来了一个陷阱。一旦引入了错误并在浏览器的开发人员工具中看到了该错误，通常很难跟踪该错误发生的文件，因为Webpack将所有内容捆绑到一个JavaScript文件中。例如，假设我们的src / index.js文件从另一个文件导入了一个函数并使用了它：

import sum from './sum.js';
 
console.log(sum(2, 5));

在我们的src / sum.js中，我们导出了此JavaScript函数，但不幸的是其中引入了一个错字：

export default function (a, b) {
  return a + c;
};

如果npm start在浏览器中运行并打开该应用程序，则应该在开发人员工具中看到发生的错误：

sum.js:3 Uncaught ReferenceError: c is not defined
    at eval (sum.js:3)
    at eval (index.js:4)
    at Module../src/index.js (bundle.js:457)
    at __webpack_require__ (bundle.js:20)
    at eval (webpack:///multi_(:8080/webpack)-dev-server/client?:2:18)
    at Object.0 (bundle.js:480)
    at __webpack_require__ (bundle.js:20)
    at bundle.js:84
    at bundle.js:87

如果单击发生错误的sum.js文件，则只会看到Webpack的捆绑输出。在此示例的情况下，它仍然可读，但是请想象输出一个更复杂的问题：

__webpack_require__.r(__webpack_exports__);
/* harmony default export */ __webpack_exports__["default"] = (function (a, b) {
  return a + c;
});
;

进一步执行此步骤，并在您的Webpack构建中引入该错误以进行生产。运行，npm run build然后npx http-server dist再次在浏览器中看到错误：

bundle.js:1 Uncaught ReferenceError: c is not defined
    at Module.<anonymous> (bundle.js:1)
    at t (bundle.js:1)
    at bundle.js:1
    at bundle.js:1

这次，它隐藏在bundle.js文件中，而没有让您知道导致它的实际文件。此外，一旦单击bundle.js文件，您只会看到Webpack捆绑的JavaScript生产版本，其格式不是可读的。

总之，这不是一个很好的开发人员体验，因为Webpack捆绑的JavaScript文件查找错误变得更加困难。对于开发模式，这是正确的，但对于生产模式，则更是如此。

为了克服此问题，可以引入 source map，以为Webpack提供对原始源代码的引用。通过使用 source map，Webpack可以将所有捆绑的源代码映射回原始源。在您的webpack.config.js文件中，为 source map引入一种常见配置：

module.exports = {
  ...
  devtool: 'source-map',
};

之后，与仍然在源代码中的bug，运行npm run build和npx http-server dist试。在浏览器中，请注意如何将错误跟踪到导致文件sum.js：

sum.js:2 Uncaught ReferenceError: c is not defined
    at Module.<anonymous> (sum.js:2)
    at t (bootstrap:19)
    at bootstrap:83
    at bootstrap:83

单击文件将为您提供实际的源代码和错误的位置，即使Webpack捆绑了所有JavaScript源代码也是如此。还要注意，有一个名为dist / bundle.js.map的新文件，该文件用于执行src /中的实际源代码和dist / bundle.js中的捆绑JavaScript的映射。

Webpack开发/构建配置

到目前为止，我们已经使用一种通用的Webpack配置进行开发和生产。但是，我们也可以为每种模式介绍一个配置。在package.json中，将启动脚本和构建脚本更改为以下内容：

{
  ...
  "scripts": {
    "start": "webpack serve --config ./webpack.dev.js",
    "build": "webpack --config ./webpack.prod.js",
    "test": "echo \"Error: no test specified\" && exit 0"
  },
  ...
}

现在创建这两个新文件，将旧的webpack.config.js配置复制并粘贴到两个文件中，然后删除旧的webpack.config.js文件。接下来，由于我们在npm脚本中省略了Webpack模式，因此请为每个Webpack配置文件再次介绍它们。首先，webpack.dev.js文件：

module.exports = {
  mode: 'development',
  ...
};

其次，webpack.prod.js文件：

...
 
module.exports = {
  mode: 'production',
  ...
};

您用于启动和构建应用程序的npm脚本应该可以再次工作。但是您可能会想：现在有什么区别？除了我们之前动态传递的Webpack模式外，Webpack的配置对于开发和生产都是相同的。我们甚至引入了不必要的重复。稍后再详细介绍后者。

在不断增长的Webpack配置中，您将介绍在开发和生产中行为应有所不同的内容（例如，插件，规则， source map）。例如，让我们来看一下我们先前实现的 source map。为大型代码库创建 source map文件是一项性能沉重的过程。为了使开发构建快速有效地运行，以提供出色的开发人员体验，您希望开发中的 source map不像生产构建中的 source map那样100％有效。为开发模式创建它们应该更快。因此，您可以对webpack.dev.js文件进行首次更改，而该更改不会反映在生产配置中：

...
 
module.exports = {
  mode: 'development',
  ...
  devtool: 'eval-source-map',
};

现在，对于您的开发和生产模式， source map的生成方式有所不同，因为在两个Webpack配置文件中以不同的方式定义了 source map。这只是在开发和生产中为Webpack配置不同配置的一个实例。

Webpack合并配置

目前，用于开发和生产的Webpack配置文件共享许多常用配置。如果我们能够将通用配置提取到一个单独的但常用的文件中，而仅根据开发和生产选择额外的特定配置，该怎么办？让我们通过调整package.json文件来做到这一点：

{
  ...
  "scripts": {
    "start": "webpack serve --config build-utils/webpack.config.js --env env=dev",
    "build": "webpack --config build-utils/webpack.config.js --env env=prod",
    "test": "echo \"Error: no test specified\" && exit 0"
  },
  ...
}

如您所见，我们为两个npm脚本引用了一个新的共享webpack.config.js。该文件位于新的build-utils文件夹中。为了稍后在Webpack配置中区分正在运行的脚本，我们还向配置传递了一个环境标志（dev，prod）。

现在，再次创建共享的build-utils / webpack.config.js文件，但这一次是在新的专用build-utils文件夹中，并为其进行以下配置：

const { merge } = require('webpack-merge');
 
const commonConfig = require('./webpack.common.js');
 
module.exports = ({ env }) => {
  const envConfig = require(`./webpack.${env}.js`);
 
  return merge(commonConfig, envConfig);
};

您可以看到该函数env从npm脚本接收了我们的环境标志。这样，我们可以动态地需要一个具有JavaScript模板文字的特定于环境的Webpack配置文件，并将其与通用的Webpack配置合并。为了合并它，让我们安装一个小助手库：

npm install --save-dev webpack-merge

接下来，我们现在必须在build-utils文件夹中实现三个文件：

让我们从新的build-utils / webpack.common.js文件中的共享Webpack配置开始：

const path = require('path');
const { CleanWebpackPlugin } = require('clean-webpack-plugin');
const HtmlWebpackPlugin = require('html-webpack-plugin')
 
module.exports = {
  entry: path.resolve(__dirname, '..', './src/index.js'),
  module: {
    rules: [
      {
        test: /\.(js)$/,
        exclude: /node_modules/,
        use: ['babel-loader']
      }
    ]
  },
  resolve: {
    extensions: ['*', '.js']
  },
  plugins: [
    new CleanWebpackPlugin(),
    new HtmlWebpackPlugin({
      title: 'Hello Webpack bundled JavaScript Project',
      template: path.resolve(__dirname, '..', './src/index.html'),
    })
  ],
  output: {
    path: path.resolve(__dirname, '..', './dist'),
    filename: 'bundle.js'
  },
  devServer: {
    contentBase: path.resolve(__dirname, '..', './dist'),
  },
};

请注意，与以前的Webpack配置相比，某些文件路径已更改，因为我们现在在专用文件夹中拥有此文件。还要注意，没有Webpack模式，也没有 source map。这两个选项将成为其专用Webpack配置文件中特定的环境（例如，开发，生产）。

通过创建build-utils / webpack.dev.js文件继续进行操作，并为其提供以下内容：

module.exports = {
  mode: 'development',
  devtool: 'eval-source-map',
}

最后但并非最不重要的是，新的build-utils / webpack.prod.js文件接收以下内容：

module.exports = {
  mode: 'production',
  devtool: 'source-map',
};

您的文件夹结构现在应该类似于以下内容。请注意，先前各节的build-utils /文件夹之外没有Webpack配置：

- build-utils/
-- webpack.common.js
-- webpack.config.js
-- webpack.dev.js
-- webpack.prod.js
- dist/
-- bundle.js
-- bundle.js.map
-- index.html
- src/
-- index.html
-- index.js
- package.json
- .babelrc

您的npm start和npm run build脚本现在应该可以工作了。相对于其build-utils / webpack.dev.js和build-utils / webpack.prod.js配置文件，两者都针对Webpack模式和 source map使用不同的配置。但是它们也共享来自build-utils / webpack.common.js的通用Webpack配置。一切都动态合并在build-utils / webpack.config.js文件中，该文件根据package.json中npm脚本中的传入标志进行动态合并。

Webpack环境变量：定义

有时您可能想在源代码中知道您是处于开发还是生产模式。对于这些情况，您可以通过Webpack指定动态环境变量。由于每个环境都有一个Webpack配置文件（开发，生产），因此可以为它们定义专用的环境变量。在您的build-utils / webpack.dev.js中，通过以下方式定义环境变量：

const { DefinePlugin } = require('webpack');
 
module.exports = {
  mode: 'development',
  plugins: [
    new DefinePlugin({
      'process.env': {
        'NODE_ENV': JSON.stringify('development'),
      }
    }),
  ],
  devtool: 'eval-source-map',
};

这同样适用于您的build-utils / webpack.prod.js文件，但具有不同的环境变量：

const { DefinePlugin } = require('webpack');
 
module.exports = {
  mode: 'production',
  plugins: [
    new DefinePlugin({
      'process.env': {
        'NODE_ENV': JSON.stringify('production'),
      }
    }),
  ],
  devtool: 'source-map',
};

现在，您可以使用src / index.js文件中console.log(process.env.NODE_ENV);的环境变量或src /文件夹中的任何其他JavaScript来基于它进行决策。在这种情况下，您已经创建了两个不同的环境变量-每个都针对Webpack模式。但是，将来您可能会为某些情况引入更多的环境变量。

Webpack环境变量：.ENV

以前，您开始在Webpack配置文件中定义环境变量。但是，这不是敏感信息的最佳实践。例如，假设您要根据开发或生产环境使用API密钥/秘密（凭证）来访问数据库。您不想在您的Webpack配置中公开这些敏感信息，而这些信息可能会与其他人共享。相反，您想为环境文件引入专用文件，这些文件可以与其他文件和版本控制系统（如Git或SVN）保持距离。

让我们从为开发和生产模式创建两个环境变量文件开始。第一个用于开发模式，称为.env.development。将其放入具有以下内容的项目的根目录中：

NODE_ENV=development

第二个称为.env.production并具有其他内容。它还放置在项目的根目录中：

NODE_ENV=production

通过使用dotenv-webpack插件，您可以将这些环境变量复制到Webpack配置文件中。首先，安装插件：

npm install dotenv-webpack --save-dev

其次，在开发模式的build-utils / webpack.dev.js文件中使用它：

const path = require('path');
const Dotenv = require('dotenv-webpack');
 
module.exports = {
  mode: 'development',
  plugins: [
    new Dotenv({
      path: path.resolve(__dirname, '..', './.env.development'),
    })
  ],
  devtool: 'eval-source-map',
};

第三，在生产模式的build-utils / webpack.prod.js文件中使用它：

const path = require('path');
const Dotenv = require('dotenv-webpack');
 
module.exports = {
  mode: 'development',
  plugins: [
    new Dotenv({
      path: path.resolve(__dirname, '..', './.env.production'),
    })
  ],
  devtool: 'eval-source-map',
};

现在，您可以通过.env.development和.env.production文件在环境变量中引入敏感信息（例如IP地址，帐户凭据和API密钥/秘密）。您的Webpack配置将复制它们，以使其在您的源代码中可访问（请参阅上一节）。如果您使用的是版本控制系统（例如Git），请不要忘记将这些新的.env文件添加到您的.gitignore中，以向第三方隐藏您的敏感信息。

Webpack插件

Webpack具有庞大的插件生态系统。通过使用Webpack开发或生产模式已经隐式使用了其中的几个。但是，还有其他Webpack插件可以改善您的Webpack捆绑包体验。例如，让我们介绍可用于分析和可视化Webpack捆绑包的加载项。在package.json中，为您的构建过程引入一个新的npm脚本，但是这次使用Webpack插件：

{
  ...
  "scripts": {
    "start": "webpack serve --config build-utils/webpack.config.js --env env=dev",
    "build": "webpack --config build-utils/webpack.config.js --env env=prod",
    "build:analyze": "npm run build -- --env addon=bundleanalyze",
    "test": "echo \"Error: no test specified\" && exit 0"
  },
  ...
}

请注意，这个新的npm脚本如何运行另一个npm脚本，但是具有附加配置（此处是Webpack插件）。但是，Webpack插件不会神奇地运行。在这种情况下，它们仅作为标志传递给我们的Webpack配置。让我们看看如何在build-utils / webpack.config.js文件中使用它们：

const { merge } = require('webpack-merge');
 
const commonConfig = require('./webpack.common.js');
 
const getAddons = (addonsArgs) => {
  const addons = Array.isArray(addonsArgs)
    ? addonsArgs
    : [addonsArgs];
 
  return addons
    .filter(Boolean)
    .map((name) => require(`./addons/webpack.${name}.js`));
};
 
module.exports = ({ env, addon }) => {
  const envConfig = require(`./webpack.${env}.js`);
 
  return merge(commonConfig, envConfig, ...getAddons(addon));
};

现在，不仅合并了通用的和特定于环境的Webpack配置，而且还合并了可选的附加组件，我们将它们放入专用的build-utils / addons文件夹中。让我们从build-utils / addons / webpack.bundleanalyze.js文件开始：

const path = require('path');
const { BundleAnalyzerPlugin } = require('webpack-bundle-analyzer');
 
module.exports = {
  plugins: [
    new BundleAnalyzerPlugin({
      analyzerMode: 'static',
      reportFilename: path.resolve(
        __dirname,
        '..',
        '..',
        './dist/report.html'
      ),
      openAnalyzer: false,
    }),
  ],
};

接下来，在命令行上通过npm安装Webpack插件：

npm install --save-dev webpack-bundle-analyzer

如您所见，您已经在新的build-utils / addons /文件夹中引入了一个特定的Webpack插件，可以选择添加该Webpack插件。插件文件的命名与package.json中npm脚本传递的标志匹配。您的Webpack合并确保将所有传递的插件标记添加为Webpack配置中的实际插件。

现在，请自己尝试用于Webpack分析和可视化的可选工具。在命令行上，键入npm run build:analyze。然后，检查您的dist /文件夹中是否有新文件。您应该找到一种可以通过以下方式打开的方式：

您将看到具有两种不同可视化效果的构建优化的Webpack捆绑包。您的应用程序中没有很多代码，但是一旦您在节点包管理器中引入了更多的源代码和更多的外部库（依赖项），您将看到Webpack包的大小将如何增长。最终，您将偶然地引入一个大型库，这会使您的应用程序变得太大。然后，分析工具和可视化工具都可以帮助您找到问题的根源。

参考

How to Advanced Webpack 5 - Setup Tutorial

上一篇 下一篇

猜你喜欢

热点阅读