开发和生产环境的构建配置差异

开发和生产环境的构建配置差异

我们在日常的前端开发工作中，一般都会有两套构建环境：

一套开发时使用，构建结果用于本地开发调试，不进行代码压缩，打印debug 信息，包含sourcemap 文件；

另外一套构建后的结果是直接应用于线上的，即代码都是压缩后，运行时不打印debug信息，静态文件不包括sourcemap 的。有的时候可能还需要多一套测试环境，在运行时 直接进行请求mock 等工作。

webpack 的运行时环境是Node.js，我们可以通过Node.js 提供的机制给要运行的

webpack 程序传递环境变量，来控制不同环境下的构建行为。]

例如，我们在npm 中的

{
    "scripts": {
    "build": "NODE_ENV=production webpack",
    "dev": "NODE_ENV=development webpack-dev-server"
    }
}

scripts 字段添加一个用于生产环境的构建命令 然后在webpack.config.js 文件中可以通过process.env.NODE_ENV 来获取命令传 入的环境变量

常见的环境差异配置

前面提及的使用环境变量的方式可以让我们在不同的构建环境中完成不同的构建需求，这

里列举一下常见的webpack 构建差异配置：

成单独的文件，以便多个页面共享同一个CSS 文件

生产环境需要压缩HTML/CSS/JS 代码

生产环境需要压缩图片

开发环境需要生成sourcemap 文件

开发环境需要打印debug 信息

开发环境需要live reload 或者hot reload 的功能 以上是常见的构建环境需求差异，可能更加复杂的项目中会有更多的构建需求（如划分静 态域名等），但是我们都可以通过判断环境变量来实现这些有环境差异的构建需求。

优化前端资源加载

图片加载优化

css sprites 用webpack-spritesmith 或者sprite-webpack-plugin 图片压缩image-webpack-loader 来压缩图片文件 使用DataURL url－loader 在处理文件的时候，可以通过配置指定一个大小， 当文件小于这个配置值时，url-loader 会将其转换为一个base64 编码的DataURL

代码压缩

webpack 4.x 版本运行时，mode 为production 即会启动压缩JS 代码的插件，而对于

webpack 3.x，使用压缩JS 代码插件的方式也已经介绍过了。在生产环境中，压缩JS 代码基本是一个必不可少的步骤，这样可以大大减小JavaScript 的体积，相关内容这里 不再赘述

分离代码文件

css 分离在webpack 中使用extract-text-webpack-plugin 插件即可 如何使用webpack 来把代码中公共使用的部分分离成为独立的文件呢？

3.x 以前的版本是使用CommonsChunkPlugin 来做代码分离的，而webpack 4.x 则是把 相关的功能包到了optimize.splitChunks 中，直接使用该配置就可以实现代码分离。

webpack 4.x 的optimization 之前我们提到拆分文件是为了更好地利用缓存，分离公共类库很大程度上是为了让多页面 利用缓存，从而减少下载的代码量，同时，也有代码变更时可以利用缓存减少下载代码量 的好处。从这个角度出发，笔者建议将公共使用的第三方类库显式地配置为公共的部分， 而不是webpack 自己去判断处理。因为公共的第三方类库通常升级频率相对低一些，这 样可以避免因公共chunk 的频繁变更而导致缓存失效。

显式配置共享类库可以这么操作：

module.exports = {
    entry: {
        vendor: ["react", "lodash", "angular", ...], // 指定公共使用的第三方类库
        },
        optimization: {
            splitChunks: {
                cacheGroups: {
                vendor: {
                    chunks: "initial",
                    test: "vendor",
                    name: "vendor", // 使用vendor 入口作为公共部分
                    enforce: true,
                },
            },
        },
    },
    // ... 其他配置
}
// 或者
	module.exports = {
	optimization: {
	splitChunks: {
	module.exports = {
	// ... webpack 配置
		optimization: {
			splitChunks: {
				chunks: "all", // 所有的chunks 代码公共的部分分离出来成为一个单独的
				文件
				},
				},
				}
			cacheGroups: {
				vendor: {
					test: /react|angluar|lodash/, // 直接使用test 来做路径匹配
					chunks: "initial",
					name: "vendor",
					enforce: true,
					},
					},
					},
				},
			}
// 或者

module.exports = {
	optimization: {
		splitChunks: {
			cacheGroups: {
				vendor: {
					chunks: "initial",
					test: path.resolve(__dirname, "node_modules") // 路径在
					node_modules 目录下的都作为公共部分
					name: "vendor", // 使用vendor 入口作为公共部分
					enforce: true,
				},
			},
		},
	},
}

上述第一种做法是显示指定哪些类库作为公共部分，第二种做法实现的功能差不多，只是 利用了test 来做模块路径的匹配，第三种做法是把所有在node_modules 下的模块，即 作为依赖安装的，都作为公共部分。你可以针对项目情况，选择最合适的做法。 webpack 3.x 的CommonsChunkPlugin

CommonsChunkPlugin 也是支持显式配置共享类库的：
	module.exports = {
	// ...
		plugins: [
			new webpack.optimize.CommonsChunkPlugin({
			name: "commons", // 公共使用的chunk 的名称
			filename: "commons.js", // 公共chunk 的生成文件名
			minChunks: 3, // 公共的部分必须被3 个chunk 共享
			}),
		],
	}

按需加载模块

前面讲述了如何把大的代码文件进行拆分，抽离出多个页面共享的部分，但是当你的Web 应用是单个页面，并且极其复杂的时候，你会发现有一些代码并不是每一个用户都需要用 到的。你可能希望将这一部分代码抽离出去，仅当用户真正需要用到时才加载，这个时候 就需要用到webpack 提供的一个优化功能—— 按需加载代码模块。 在webpack 的构建环境中，要按需加载代码模块很简单，遵循ES 标准的动态加载语 法dynamic-import 来编写代码即可，webpack 会自动处理使用该语法编写的模块：