前端打包工具 —— webpack(二.处理样式文件)
webpack 依赖图
为什么需要了解 webpack 的依赖图呐,是因为了解了 webpack 的依赖图后可以方便我们了解更多关于 webpack 的打包流程
那么这个时候我们的 webpack 是如何进行打包的呐???
首先我们的 webpack 先实现的是我们的根据具体的配置来寻找我们打包需要的入口文件
根据寻找到的入口文件,生成我们的依赖关系图,这个依赖关系图中含有了程序中所需的所有模块(JS, CSS, Image, font)
然后根据生成的依赖关系图,遍历图结构,进行打包一个又一个的模块,不同的文件类型使用不同的 loader 进行解析
这里拓展一下什么是图结构,什么是树结构
- 树结构就是我们的关系图只是单向的,只有从上往下进行扩展
- 图结构就不同了,图结构实现的是整体的是从上往下进行依赖的,但是在中间还是具备其他的交叉依赖
webpack 打包规则
- 首先我们需要注意的是我们的 webpack 默认是可以打包我们的 JS 文件的,但是对于 CSS 和 html 文件是无法实现打包的
- 所以说这个时候就需要我们进行配置对应的 webpack 来实现打包对应的文件类型
- 每种文件类型的处理就需要我们使用到具体的 loader 依赖来实现具体的编译解析
- 这个时候就需要实现的是向我们的
webpack.config.js
文件中自定义 module.rules 规则来实现具体的打包
module.rules
test 属性,用来实现的就是我们的对原文件进行匹配,通常使用正则表达式即可
use 属性,通常就是用来指定我们的解析需要使用得到的依赖是什么
- loader 属性,指定解析所需要的依赖
- options 属性,可选属性
- query 属性,设置参数类型的
loader 属性:就是我们的 Rule.use[{ loader }] 简写
webpack 解析样式的配置
CSS 的解析处理
首先我们为了可以实现解析我们的 CSS 文件,我们现在就需要进行的是下载两个依赖来实现
npm install css-loader style-loader -D
开发依赖css-loader
- 实现的是我们的解析我们的 CSS 文件
style-loader
- 实现的就是将我们解析后的文件加载到我们的页面中去
这里我们需要注意的是 use 中的 loader 的解析规则是从后往前进行使用的
- 所以说上面的步骤的话,我们先实现的是先解析 CSS 文件,然后加载我们的页面
- 配置信息这个时候就需要我们两极反转,
css-loader
在我们的style-loader
之后书写(webpack-config.js)但是这样的编译解析后任然还是具备一些缺点的
- 这样配置的文件是全部使用的是内敛的书写方式进行引入的文件
- 但是实际上开发中我们希望的是将我们的 JS代码,CSS代码,HTML代码解析并且压缩到单独的目录中去的
- 所以说这里先留这样的抑或点,后面再来解决
less 文件的处理
处理我们的 less 文件任然是需要三个依赖的
一个就是 less-loader ,一个就是 css-loader,最后一个就是 style-loader
- 默认的情况下,我们的 style-loader 只可以实现对我们的 css-loader 解析的代码进行解析
less-loader
- 主要是用来实现的是解析我们的 less 代码为CSS代码的依赖
css-loader
- 将我们的通过 less-loader 解析为的 CSS 代码进一步的解析
style-loader
- 实现的就是我们的将解析后的代码实现添加到页面中生效的依赖
npm install less-loader css-loader style-loader -D
sass 文件的处理
和我们的 less 文件的处理大致类似的
只是最顶层的解析依赖有所不同了
这个时候我们需要机型安装的的是
npm install sass-loader css-loader style-loader -D
解决兼容性问题
我们的一些CSS属性可能会引发兼容性问题的,这个时候我们是可以添加浏览器前缀在实现解决兼容性问题的
但是我们不可能手动的添加浏览器前缀来实现我们的解决浏览器兼容性问题吧
所以说这个时候,我们就可以使用一些依赖来帮助我们解决这样的问题,来实现自动的帮助我们添加浏览器前缀
这个工具就是我们的
postcss-loader
npm install postcss-loader -D
- 这个工具是在我们的代码进行编译打包的时候需要使用的呐
- 该工具是在我们进行打包 CSS 的时候需要使用的一个工具集
- 所以说需要在我们编译打包使用
css-loader
之前使用我们的postcss-loader
来实现具体的编译使用但是这样之后,还是没有进行自动添加我们的浏览器前缀,我们还需要使用到另一个插件
npm install autoprefixer -D
这个时候就需要使用我们的一些配置项来实现具体的指定我们的
postcss
工具使用怎样的方式进行解析我们的代码了这个时候就是使用我们的
options
配置属性了
- 同时这里我们还是可以注意一点的是,我们对我们的
postcss
实现配置的时候形式含有两种- 一种是直接在我们的
webpack.config.js
来实现配置- 或者说把对应的限制配置在我们的
postcss.config.js
中通过上面的实现,我们可以知道的是我们的
postcss-loader
插件的话实现编译的时候需要使用到里面内置的一些插件的
- 但是我们常用的插件也就那几个吧,所以说现在我们就可以使用设置预设环境来设置需要安装的插件有那些了
postcss-preset-env
- 这个插件实现的是将我们的一些提前需要的插件都进行准备了的
- 我们的
autoprefixer
更加的强大:npm uninstall autoprefixer
npm install postcss-preset-env -D
总结
我们在该部分讲解了关于我们的 webpack 来处理样式文件的配置以及使用我们的配置文件来实现解决我们的浏览器兼容性
- 等问题的实现
在本章节我们需要注意的一个点是: 我们的 webpack 工具默认的是可以解析我们的 JS 文件的
- 但是关于其他的文件是不可以进行解析的
同时我们还需要注意的一个点是,我们的 webpack 工具,实现打包的基本流程是
- 将我们的所有的文件进行构建了依赖树之后,再进行的最终的打包
- 这一点也是为什么后面我们的 vite 打包工具比 webpack 打包速度快的原因之一