webpack TM 到底是什么和为什么
历史
因为早期浏览器的标准的不统一导致 web 技术的历史包袱比较重,旧的浏览器无法支持新的标准,但是又有旧的浏览器的用户群体,同时也有需要新方法的用户群体,新需求和旧标准之间的矛盾一直存在,而且愈演愈烈。整个前端生态就好像一个巨人在一个鸡窝里头去跳芭蕾舞,又要跳的优雅,又要跳的小心,还不能踩死鸡娃,就是这种感觉。那咋搞?webpack lei了。
坑坑 - 模块化
要理解 webpack 是个什么东西,以及它解决了什么问题,首先得了解前端的一个最大的坑,就是浏览器在解析js的时候,它有个盲点,无法像其他语言一样做到 js 文件的模块化。
比如说:一个文件想要对另一个文件暴露出去一个变量,你只能把它定义在全局作用域下。在 script src 中引入 js 文件,但是一旦文件数量一多,可能变量就会发生冲突,覆盖。
文件目录下有:index.html , a.js , b.js
1 | <script src="./a.js"></script> |
后来,出现了一个东西,node。它可以跑 js,而且 node 可以直接跑在操作系统上,直接终端输入 node
就可以。而且 node 有个非常好的东西是浏览器不存在的,模块化。在 node 中,所有的文件都是模块,任何的模块都有两个口,一个是入口 require(XXX),一个是出口 module.exports = {XXX}。
举个栗子:
1 | // a.js |
但是浏览器不识别这东西,怎么办?webpack 来搞。
1 | <!-- 终端输入: webpack b.js bundle.js --> |
这样运行 index.html 就能在控制台看到生成的消息 msg: 这是 a 里面的消息
webpack 能动态的把后端的代码变成浏览器能读懂的代码, 做到了后端代码前端化,这样我们既做到了用后端的方式来让我们的代码更加模块化,也能够让浏览器读懂我们的代码。至于打包出来的 js 代码有多丑陋,我们不管,只要它体积小,性能好,就行了。
安装和配置
- npm init -y
- npm i webpack@3 -D
- 在 package.json 中添加 scripts 命令 “pack”: “node_modules/.bin/webpack b.js bundle.js”
- npm run pack
1 | { |
- 为了添加更多的配置项,我们新建一个 webpack.config.js
1 | module.exports = { |
- 修改 scripts 命令 “pack”: “node_modules/.bin/webpack –watch”
- npm run pack
这就是最基本的 webpack
webpack 是什么应该心里有些 b 树了吧,模块化和打包 (感觉自己菜的一笔啊)
我们可以直接使用 require(XXX) 的形式来引入各模块,即使它们可能需要经过编译(比如JSX和sass),但我们无须在上面花费太多心思,因为 webpack 有着各种健全的加载器(loader)在默默处理这些事情,这块后续会提到。
总结
可以看做一个模块化打包机,分析项目结构,处理模块化依赖,转换成为浏览器可运行的代码。
- 代码转换: TypeScript,JSX 编译成 JavaScript、SCSS,LESS 编译成 CSS.
- 文件优化:压缩 JavaScript、CSS、HTML 代码,压缩合并图片。
- 代码分割:提取多个页面的公共代码、提取首屏不需要执行部分的代码让其异步加载。
- 模块合并:在采用模块化的项目里会有很多个模块和文件,需要构建功能把模块分类合并成一个文件。
- 自动刷新:监听本地源代码的变化,自动重新构建、刷新浏览器。
构建把一系列前端代码自动化去处理复杂的流程,解放生产力。