我们都知道通过安装和配置第三方插件,可以使我们的webpack拓展更多的功能,虽然之后开发项目不需要我们自己去进行这些繁琐的配置,但是我们需要知道这些,在必要时我们可以去做出修改
比如我们在初识webpack中提到的webpack-dev-server(每当我们修改了源代码,webpack就会自动的进行项目打包和构建)以及html-webpack-plugin(自定制index页面内容,将存在于内存中的页面克隆一份到项目根目录)
不需要会-但是一定要知道的简单配置Webpack操作_Developer小蜗的博客-CSDN博客
目录
一.安装配置处理CSS文件的loader插件
二.安装配置LESS文件的loader加载器
三.安装配置图片文件的loader加载器
四.JS超高级语法需要使用的loader加载器
五.打包发布-部署上线
六.细节处理优化打包
七.dist文件重新打包的删除操作-clean插件
接下来进入正题,我们本章阐述的时loader加载器,那么loader加载器是什么呢?
在我们的开发过程中,webpack默认只能进行打包处理以.js后缀名结尾的模块,其他的非.js后缀结尾的模块webpack自己默认是处理不了的,比如一些.css文件或者.jpg等等
比如我们在要进行打包处理的.js文件中导入一个.css文件,我们想要将.css文件一起处理掉:
//现在我们处于.js文件中
import '../index.css'
这是会报错的,webpack目前(默认)是无法打包处理.css文件的
这时我们就需要用到loader加载器来协助webpack打包处理特定的文件模块,比如想要webpack借助插件来打包处理.css文件,那么我们需要用到css-loader;如果是.less文件,我们可以使用less-loader插件;如果是一些JS超高级语法,我们可以使用babel-loader插件提供给webpack来打包处理
那么loader是怎么工作的呢?我们需要了解它的工作原理才可以进行更好的理解和开发:
回到前面提到的那个报错问题,当时webpack处理不了并没有放弃处理,而是去查找webpack自己的webpack.config.js配置文件,看module.rules数组中是否配置了对应的loader加载器
tips:module是所有第三方模块的匹配规则;rules用来定义不同模块对应的loader插件
npm i style-loader css-loader -D
因为打包处理的时候webpack回去寻找自己的配置文件,所以我们的插件书写在webpack.config.js配置文件中:
module:{
rules:[
{test:/\.css$/,use:['style-loader','css-loader']}
]
}
test表示匹配的文件类型(本案例也就是使用正则来匹配到后缀为.css的文件)
use表示对应要调用的loader(tips:use数组中指定的loader顺序是固定的,npm上的作者怎么写,我们就怎么写,因为在执行时是规定从后往前依次执行的,如果颠倒的话,不能正常工作)
我们来捋一下思路:
首先我们import在JS文件中导入CSS文件,run一下让webpack进行打包处理,这时webpack发现了自己处理不了的.css文件,立马去自己的webpack.config.js配置文件中查找module节点里面的rules中有没有相关loader加载器,发现有css的loader加载器,那么转交给loader加载器,css-loader处理完成之后将结果转交给style-loader,style-loader处理完毕之后,发现没有需要执行的记加载器了,于是把结果转交给webpack。webpack把style-loader的处理结果与自己处理的文件一起合并到 dist文件夹下的index.js文件,这就是webpack使用loader加载器来打包的过程
npm i less-loader less -D
配置:
module:{
rules:[
{test:/\.less$/,use:['style-loader','css-loader','less-loader']}
]
}
这时我们发现了一个问题,为什么下载的less没有配置?
less包其实就是一个less-loader的一个内置依赖,不需要配置到module中,但是又不能没有
假如我们现在有这样一个img标签需要动态添加图片:
我们可以在相关JS文件中导入这张图片:
import img form './images/nav.png'
//并且动态给src赋值:
$('img').attr('src',img)
我们查看UI页面是发现没有图片,打开终端报错了,我们也是需要同样的loader加载器来进行处理:
下载(file-loader同样也是一个内置依赖项):
npm i url-loader file-loader -D
配置:
module:{
rules:[
{test:/\.png|jpg|gif|$/,use:'url-loader?limit=5000'}
]
}
?后面是loader的参数项,就像我们请求服务器携带的查询字符串一样;使用limit来指定图片的大小,单位是字节(byte),意思是当图片<=limit值(5000)时,图片被转换为base64格式来进行动态的渲染
那么我们有问题了-如果大于呢?不渲染了吗?
如果图片字节大于limit值的话,会按原先的./image/nav.png这样的路径动态给到img的src属性
那我们又问了?这俩个有什么区别吗?
如果使用路径的话,我们每加载一张图片时浏览器都会额外的发送一次请求,为了性能优化,一些小的图片就会去使用base64格式的图片
安利一个转换地址:图片转BASE64编码 | 菜鸟工具
如果图片较大的话不建议使用base64格式,因为体积会变大,也是不利于性能的,我们开发需要使用最佳的一个方案:小图base64-大图用路径
为了不需要自己配(懒),我们就可以使用url-loader加载器提供的这个功能
下载:
npm i babel-loader babel/cove @babel/plugin-proposal-decorators -D
在webpack.config.js配置文件中配置:
module:{
rules:[
{test:'/\.js$/',use:'babel-loader,exclude:/node_modules/'}
]
}
//exclude指的是排除项(node_modules文件加下的所有代码不进行转换)
//node_modules文件夹下存储的都是第三方的包,我们无需更改
在项目根目录下新建一个babel.config.js的配置文件并配置:
module.exports = {
//声明babel可用插件
plugin:[['@babel/plugin-proposal-decorators',{legacy:true}]]
}
为什么要配置这样一项?
因为@babel/plugin-proposal-decorators插件是babel-loader的插件
webpack在调用babel-loader之前会先调用加载plugin插件使用
我们前端会把项目生成一份最终的结果,打包发布给后端、由后端去部署上线
这时我们想要将文件打包整理也是需要相应的配置:
在package.json配置文件中的scripts节点下新增一个build命令:
"scripts":{
"dev":"webpack serve",
"build":"webpack --mode production"
}
也就是配置了一个上线时的production命令,可以覆盖掉之前我们在webpack.config.js配置文件中的这项配置:
module.exports = {
mode:'development'
}
然后我们run一下:
npm run build
这样我们就将项目打包完成了
我们现在打包出来的里面的文件还是比较散乱的,我们想要将所有JS文件放在JS文件夹下,所有的图片放到Images文件夹下.........,经过这样的整理再打包出来,这要怎么实现呢?
JS、CSS...文件:我们只需要将webpack.config.js配置文件中的output节点下的filenmae属性(打包文件导出路径)修改一下:
比如在路径前添加一个./images就可以了
图片文件:我们需要在配置url-loader那里,添加一个新参数outputPath,让图片文件生成在一个指定路径下:
module:{
rules:[
{test:/\.png|jpg|gif|$/,use:'url-loader?limit=5000&outputPath=images'}
]
}
我们每当dist一个新包时都需要手动删除之前的文件,否则的话之前的文件还存在,新生成的文件又存在了新的文件夹下,导致了文件重复的问题
我们需要解决每当生成一个新包时,先把旧包删除:
npm i -D clean-webpack-plugin
配置:
const { CleanWebpackPlugin } = require('clean-webpack-plugin')
const webpackConfig = {
plugins: [
new CleanWebpackPlugin(),
],
}
module.exports = webpackConfig
详细更多好玩实用功能查看:
clean-webpack-plugin - npm
npm