前沿
有兴趣可以去极客时间《玩转 webpack 课程》
为什么要将构建配置抽离成 npm 包?
通用性
- 业务开发者无需关注构建配置
- 统一团队构建脚本
可维护性
- 构建配置合理的拆分
- README 文档
质量
- 冒烟测试
- 方便持续继承,让每次提交都能检查
构建配置方案
- 方案一:通过配置文件管理不同环境的构建,webpack --config 参数控制
- 方案二:设计成一个库,类似于:hjs-webpack,webpack-blocks
- 方案三:抽成一个工具进行管理,类似我们常用的 create-react-app
- 方案四:集成在一个配置文件,通过 --env 参数控制分支选择 综上几种方案,本篇文章在于构建一个通用配置,所以本篇选择综合方案一和二,如果你的团队人员规模很大,建议采用方案三
基础概念巩固
webpack 核心概念有 entry、output、loader、plugins、mode
entry - 用来指定 webpack 打包入口
- 单入口:entry 是一个字符串
```
module.exports = {
entry: './path/to/my/entry/file.js'
}
```
- 多入口: entry 是一个对象
```
module.exports = {
entry: {
app: './src/index.js',
home: './src/home'
}
}
```
output - 告诉 webpack 如何将编译后的文件进行输出
- 单入口
```
module.exports = {
entry: './path/to/my/entry/file.js',
output: {
path: path.resolve(__dirname, 'dist'),
filename: 'my-first-webpack.bundle.js'
}
}
```
- 多入口
```
module.exports = {
entry: {
app: './src/index.js',
home: './src/home'
},
output: {
path: path.resolve(__dirname, 'dist'),
filename: '[name].js' // 通过占位符确保文件名称不一致
}
}
```
loaders - 是一个函数,接受源文件作为参数,返回转换结果。
webpack 本身只支持 js 和 json 两种文件类型,通过 loaders 可以去支持其他文件类型并且将他们转换成有效的模块,还能添加到依赖模图中。
常用loaders 后面构建会用到
名称 | 描述 |
---|---|
babel-loader | 转换 es6、es7等新特性写法 |
file-loader | 进行图片文字等打包 |
css-loader | 支持.css文件类型加载和解析 |
less-loader | less转换成 css |
ts-loader | ts转换成js |
plugins - 用于 bound.js 文件优化,资源管理和环境变量注入,作用于整个构建过程
常用的 plugins
名称 | 描述 |
---|---|
clean-webpack-plugin | 清理构建目录 |
html-webpack-plugin | 创建html 文件去承载bound文件 |
friendly-errors-webpack-plugin | 友好的错误提示 |
uglifyjs-webpack-plugin | 压缩 js |
zip-webpack-plugin | 打包文件压缩成 zip |
commons-chunk-plugin | 将相同模块提成公共js |
mode - 用来指定当前构建环境,默认 production
环境 | 描述 |
---|---|
development | 设置 process.env.NODE_ENV 为development ,开启 NamedChunkplugin 和 namedModulesPlugin 代码热更新时很适用 |
production | webpack 会去开启默认压缩等 |
none | 不开启任何优化选项 |
项目设计
通过多个配置文件管理不同环境的 webpack 配置
- 基础配置 webpack.base.js
- 开发环境 webpack.dev.js
- 生产环境 webpack.prod.js
- 如果你有 ssr 的需求可以 webpack.ssr.js
打包成 npm 包统一管理
- 规范: git commit 日志,eslint等
- 质量保证: 冒烟测试、单元测试、测试覆盖率
开发通用包
项目设计
设计脑图如下:
项目目录结构如下
rick-webpack
├─.eslintrc
├─.gitignore
|─.travis.yml
├─CHANGELOG.md
├─README.md
├─package.json
├─test // 测试文件
├─lib //放置配置代码
| ├─webpack.base.js
| ├─webpack.dev.js
| └webpack.prod.js
eslint 规范脚本
npm i eslint babel-eslint eslint-config-airbnb-base -D
新增一个 .eslintrc
文件
{
"root": true,
"env": {
"node": true
},
"parser": "babel-eslint",
"extends": ["airbnb-base"],
"rules": {
"indent": ["error", 4]
}
}
单元测试、冒烟测试、测试覆盖率
冒烟测试可以保证我们的框架是否可用,但是细节部分就需要我们用单元测试
常用单元测试框架
持续集成 和 travis CI
核心思想: 代码集成到主干之前,必须通过自动化测试,只要有一个用例失败,就不能集成到主干。
为何引入持续集成?
- 快速发现错误
- 防止分支大幅度偏离主干
选择 travis CI 原因
github目前流行 CI ,travis CI 占比很明显
怎么样接入travis CI?
接入方式很简单,只需要简单三步
- 使用 github 登录网站 www.travis-ci.org
- www.travis-ci.org/account/rep… 开启自己的项目
- 项目根目录新增 .travis.yml
language: node_js
sudo: false
cache:
apt: true
directories:
- node_modules
node_js: stable #设置相应的版本
install:
- npm install -D #安装 builder 依赖
script:
- npm test
git commit规范和changelog
后续在迭代过程很重要 良好的 git commit有以下优势
- 加快 code review 流程
- 根据 git commit 的元数据生成 changelog
- 后续维护者可以知道 feature 被修改的原因 目前推荐采用 git commit angular 规范