Webpack 服务器端代码打包

环境变量

以前,咱们在项目里会常常使用 process.env.NODE_ENV, 但这个变量对于 webpack打包是有影响的, 在 production 的时候是有优化的.

因此, 咱们将改用其余的环境变量来区别:

new webpack.DefinePlugin({
  'process.env.NODE_ENV': '"production"',
  'process.env.API_ENV': `"${process.env.API_ENV || 'development'}"`
})

像这样, NODE_ENV 始终为 production.

而咱们实际开发/产品环境, 用 process.env.API_ENV 变量来使用(因为该项目是一个 koa 接口服务项目, 因此这样进行命名, 能够改为任意的, 你开心就好).

动态配置打包

注意

咱们之前在 node.js 后端项目中, 动态配置加载通常是这样写:

const ENV = process.env.NODE_ENV || 'development';
// eslint-disable-next-line import/no-dynamic-require
const options = require(`./_${ENV}`);

module.exports = options;

为了提升阅读性, 和可能存在ENV的复用, 咱们会单独定义一个变量.

在 webpack 打包的项目中直接这样作的话, 会产生一个问题. 好比我如今有多个配置:

• _develpment.js
• _test.js
• _production.js
• _staging.js

即使我传入的当前环境为 development, 依然全部的配置文件会被所有打包进来(只是永远不会被执行). 那么这样的话, 就存在敏感信息泄露的风险.

正确的姿式应该是这样的:

config/index.js

// eslint-disable-next-line import/no-dynamic-require
const options = require(`./_${process.env.API_ENV || 'development'}`);

module.exports = options;

模块化打包

好比, 我在项目中有不少个模块, 处于负载均衡的需求, 或者是对于客户定制模块化产品的需求, 咱们须要分模块进行打包, 避免其余模块(永远不会被执行的)被打包进 webpack bundle.

// config/_development.js
exports.enabledModules = ['user', 'demo']; 
// 可能 src 目录下 还有其余模块目录, 如 'manage' 等

在服务端加载的时候, 是这样子的:

// src/server.js
// 动态加载启用的模块
enabledModules.forEach((mod) => {
  /* eslint-disable global-require,import/no-dynamic-require */
  const routes = require(`./${mod}/route`);
  routes.middleware() |> app.use;
});

那么就须要 ContextReplacementPlugin 插件来支持了.

new webpack.ContextReplacementPlugin(/src/, new RegExp(`^./(${enabledModules.join('|')})/.*$`))

进阶使用

好比,src目录下除了各个模块的目录, 还有一些通用方法类,钩子的目录, 如: lib 和 hook. 这两个目录是可能被其余子模块共同引用的. 在插件正则中修改:

new webpack.ContextReplacementPlugin(/src/, new RegExp(`^./(lib|hook|${enabledModules.join('|')})/.*$`))

压缩代码, 并添加 source-map 支持

Uglifyjs 或 Uglify-es 其实对于服务器端代码打包并不友好, 可能会致使打包的失败, 用 babel-minify-webpack-plugin 插件来替代.

配合 source-map-support 插件来支持源码的问题定位.

---

• 示例项目源码： https://github.com/AirDwing/w...
• 原文连接： https://leader.js.cool/#/expe...