导图社区 Webpack
webpack学习笔记，下图包含了一些常用的配置信息以及常用的插件。
社区模板帮助中心，点此进入>>
互联网9大思维
安全教育的重要性
组织架构-单商户商城webAPP 思维导图。
个人日常活动安排思维导图
域控上线
西游记主要人物性格分析
17种头脑风暴法
python思维导图
css
CSS
Webpack
浏览器如何实现模块化
浏览器面对的问题
兼容性问题: 浏览器目前只支持ES6模块化,并且还存在兼容性问题
效率问题: 模块化让js文件分的精细,js文件多了带来了更多的请求,页面访问多,页面访问效率降低
工具问题: 浏览器不能下载第三方库的包, 开发中经常会使用各种第三方库
工程问题
兼容性
执行效率
代码可维护性可扩展性
团队协作
测试等等
根本原因
开发时
开发过程中 , 我们想怎么写代码就怎么写
模块化开发,分的越细致,代码越好写,越好维护
不考虑任何与业务无关的工程问题
运行时
运行时,工程部署到服务器上,我们希望文件越少越好
所有代码兼容所有浏览器
主要是解决执行效率问题
解决办法
webpack
gulp
等其他构建工具
这些构建工具的作用就是：让开发者开开心心的写代码，把开发代码编译成运行时态所需要的东西即可
webpack特点
基于node环境
基于模块化开发
在构建过程中，通过模块的导入语句进行分析模块依赖关系 支持各种模块化标准，不限CommonJS和ES6 Module
强大的生态圈
提供loader和plugin两个扩展点
其他第三方库通过loader和plugin融入其中
简单易用
不配置文件也是可以使用的
为前端工程化而生
开发者专心写代码，工程化问题全由webpack解决
核心功能
安装和使用
安装
本地安装
一般都是进行本地安装，也就是在安装在本工程
全局安装
全局安装的目的是全局使用cli命令，并不是所有的项目都可以用。只能用cli命令
使用
webpack的环境基于nodejs，需要安装node
webpack的生态圈比较复杂，npm包管理器来安装
webpack组成部分
webpack：核心包
webpack-cli：简单的命令，通过调用webpack中的api，来完成构建打包
编译结果分析
一个立即执行函数，导入 入口模块
编译过程
读取入口模块文件内容，分析其依赖关系
检查chunk模块记录表该模块是否加载，未加载继续执行，已加载则编译结束
获得文件内容，进行抽象语法树分析（AST）
记录依赖到dependencies中
替换依赖函数
保存替换后的内容以及模块id（模块路径）
递归加载dependencies中的模块
配置文件常用配置
mode
development/production
modules(对象)
针对webpack在分析模块时的配置,配置项比较多
rules(数组): 规则(用于配置loader)
每个规则是一个对象
对象中test属性:匹配模块,是一个正则表达式
对象中use属性(数组): 复杂的是->每个值是对象, loader: loader名;options:{针对该loader的配置参数} . 简单的: [loader1,loader2,loader3......]
noParse
正则匹配模块. 匹配的webpack不解析,也就是不会分析该模块的依赖关系
devtool
source-map, 记录源码内衣,以及源码对应的压缩后的内容
entry
配置入口
bundleName：配置入口文件的路径(eg：./src/index.js)
bundleName是文件压缩后的名字
可以通过规则命名
hash: 总资源文件的hash值
chunkhash: chunk的hash值
name: chunk的name值
补充: 开发环境chunk的name值与文件名相同, 生成环境chunk的name是一个数字
可以配置多个入口文件
output
配置出口
filename: 输出文件的文件名
命名规则同入口
path: 目标输出目录的路径(默认输出目录为dist)
publicPath: 这是一个绝对路径(eg: 从c/盘符开始的路径)
watch
true, 监控文件变化,如果部署到服务器,变化内容自动更新
一般开发环境配置
loader原理
转换代码
loader是读取文件内容之后，AST之前
loader核心是一个函数，接收一个参数，参数接收的是文件内容 经过一系列操作，文件内容被转换，再交给AST分析
plugin原理
影响webpack编译过程
plugin本质是一个带有apply方法的对象
webpack在初始化配置对象时，plugin加载compiler并传入到apply中，让apply执行
apply中的参数compiler提供很多hooks，在某一刻触发时，compiler提供一个compilation，完成后续所有编译过程
webpack进入编译过程时，内部会触发一些事件，compilation进行处理，同时还会执行以下自行注册的hooks，这就达到影响webpack编译的过程了
核心就是在apply函数中注册hooks函数，compilation完成
注意：compiler是在webpack初始化产生，compilation是在webpack编译是产生，则compiler只有一个，compilation存在多个
devServer开发服务器
插件: webpack-dev-server
port: 服务器端口号
open: true, 自动打开页面, 并使用本地服务器打开
区分环境
开发环境
生产环境
webpack性能优化
构建性能
减少模块解析
优化loader性能
热替换
传输性能
分包
什么是分包
将一个整体的代码，分布到不同的打包文件中
为什么要分包
减少公共代码，降低总体积
特别是一些大型的第三方库
充分利用浏览器缓存
什么时候要分包
多个chunk引入了公共模块
公共模块体积较大 或 较少的变动
如何分包
手动分包
自动分包
单模块体积优化
代码压缩
tree shaking
懒加载
gzip
其他优化
ESLint
代码风格检查
bundle analyzer
bundle分析
运行性能
不涉及
写代码有关系
常用扩展
常用plugin和loader
loader: 加载器,核心是转换代码
转换css文件
先css-loader -> 再style-loader
转换在js中动态加载的图片
file-loader
url-loader: 把图片转成base64位
plugin:插件,一般处理非js文件
赋值静态资源
自动生成html文件
自动清空dist目录内容
webpack内置插件
css工程化
css工程化的问题
1. 类名冲突问题
2. 样式重复问题(写重复的样式)
3. css文件细分问题(类似模块化,更利于维护)
解决方法
类名冲突问题
BEM(命名空间)
css in js(样式对象,使用js操作,完全没有css)
css module(模块化)
样式重复问题
css in js
预编译: Less Sass
文件细分
css module
css-loader?modules
css-loader这个插件配置一下就开启了
webpack两个结合
webpack拆分独立的css文件
mini-css-extract-plugin
css-loader
PostCss
简介
类似一个编译器, 把源码编译成最终css代码
中间的编译过程均是有plugin实现
npm i postcss
npm i postcss-cli
配置文件
postcss.config.js
与webpack.config.js类似, 该配置文件会影响其某些编译过程
应用到webpack
postcss均是通过插件来实现功能的
npm i postcss-preset-env postcss.config.js配置
添加 .browserslistrc 兼容浏览器
PostCss支持未来语法
https://postcss.org/
js兼容性
babel
新语法 -> ES5- 兼容浏览器
https://www.babeljs.cn/
性能优化
针对开发：打包看效果
减少模块分析，配置noParse
热替换：实时更新
单模块体积压缩
针对打包速率：文件多而复杂时，传输性能降低
针对生产：服务器运行时，页面运行速率问题
与写代码有关 写健壮性强的代码
