我们知道webpack的基本配置和四个配置的核心概念之后,其实远远不够,我们需要知道常用的loader都有什么能力,不然真的遇到问题之后,连常用loader都不了解,全靠网上去搜索,是很麻烦的一件事,就像是解决问题可以,但是也要知道解决问题的门路,不需要背下来,但是一定要对很多loader有所印象有所了解
我绞尽脑汁也就想出来这么多的loader,这些loader是我以为的在项目中应该会大频率或者说有一定频率使用的loader
css-loader
一起来讲css-loader
就是一个文件类型为css的文件进行转换,注意,css-loader
是无法单独进行使用的,因为转换出来的值无法直接进入webpack进行打包,那么就和style-loader
来一起使用const lessLoader = {
test: /\.css$/,
use: [
'style-loader',
{
loader: 'css-loader',
options: {
modules: true,
},
}
],
}
style-loader一般情况使用默认的配置,也就是啥都不用配置,参数配置详情看https://www.npmjs.com/package/style-loader
我们可以看到,因为loader的加载时由下往上的,我们可以看到这个css-loader先执行,在use里配置的loader,上边的会接收到下边的laoder处理过的值,那逻辑就是css-loader处理过的值再次被style-loader处理,就可以正常的把css成功打包进去了
modules
:这个时要配置是否打开作用域的,如果给modules配置为true,那么就会把css的名称改为哈希字符串,这样就不会有相同的css有所冲突了,modules也支持去全局的css样式书写,就是global,我们只需要:global(类名)
这样去写样式,就可以把固定类名的css不进行哈希值转换
{
test: /\.scss$/,
use: [
"style-loader",
"css-loader",
"sass-loader"
],
include: /src/, //include是任何loader都能配置的,说明loader只处理匹配的目录下的文件
},
我们可以看到,最简单的配置实际上就能满足了我们的需求了,loader们排排站好,从下往上一步步解析,就能被webpack使用了
module.exports = ({ env }) => ({
plugins: [
require("autoprefixer")({
overrideBrowserslist: ["> 1%", "last 3 versions", "ie 8"]
}),
env === 'production' ? require('cssnano') : null
]
})
loader里边加载plugin,autofixer是postcss的功能插件,autofixer就是给css中的一些属性添加-webkit-这种前缀做兼容的,autofixer作为postcss-loader的插件进行加载使用,cssnano也是功能插件plugin,但是一般会用env来判断是不是开发环境,一般取自process.env.NODE_ENV,process是node的对象,这个是可以在执行脚本语句的时候设置的,这个就暂时不细聊了,cssnano作用是压缩,那我们就知道了,这俩,一个是添加前缀的,一个是压缩的,至于参数overrideBrowserslist也很好理解,就是为了设置浏览器占比与版本来判断是否要添加某个浏览器的前缀
{
test: /\.m?js$/,
exclude: /(node_modules|bower_components)/,
use: {
loader: 'babel-loader',
options: {
presets: ['@babel/preset-env'],
plugins: ['@babel/plugin-proposal-object-rest-spread']
}
}
}
exclude用来排除node_modules等文件目录,这个是webpack给所有loader都可以添加的属性,因为babel-loader的过程太慢了,所以一定要添加这个,不然的话编译一次编译半天的情况太常见了,而且举例,
core-js 和 webpack/buildin 如果被 Babel 转码会发生错误
,我们也可以通过cacheDirectory参数配置缓存,这样第二次就会很快,但是语法转换结果会被缓存,其他的配置和优化方法也都很容易理解,可以看https://webpack.docschina.org/loaders/babel-loader/
"module": "commonjs", // 编译出的代码采用的模块规范
"target": "es5", // 编译出的代码采用 ES 的哪个版本
"sourceMap": true, // 输出 Source Map 方便调试
"importHelpers": true // 减少代码的冗余,类似:@babel/plugin-transform-runtime
一些tsconfig.js的配置,聊胜于无
这里我只用到过一次,就是在html文件转换获取代码上传给服务端生成pdf的时候
{
loader: "file-loader",
options: {
name: "[name]_[hash:8].[ext]",
publicPath: "image/"
}
}
name配置项是配置打包生成的文件的名字,使用的是placeholder语法, [name] 表示的是原文件的名字;[hash] 表示的是这次打包的hash值 [ext]表示的是原文件的后缀,outputPath配置项配置的打包生成的文件存放的路径
我本来想着梳理的全面一些,哪知道其实做了一些无用的工作,耽误到了一点时间,本来想完全梳理完呢,算了,明天周六,周六再继续梳理吧,其实有很多不需要一遍遍解释的内容,又怕哪里说的不到位,很多的loader都是只要会基础的配置,参数什么的没啥大问题,看懂一点,也就都会了,就当作记录了吧