【Webpack】自定义file-loader时图片解析后出现[object%20Module]

手写file-loader视频讲解

根据视频教程一顿操作后，编译后请求图片资源时出现404问题
GET http://127.0.0.1:5500/dist/[object%20Module] 404 (Not Found)

在搜索引擎里看了半天，很多只是讲了添加esModule=false这个配置即可，没有说明原理。
esModule=false仅针对于开源的file-loader，而我们自定义loader，不需要这个配置。

思考：为什么配置esModule=false可以解决问题？

能解决问题肯定是配置生效了，所以我直接去看了源码，观察这个配置影响了什么内容
以下为file-loader源码部分内容截取

const esModule = typeof options.esModule !== 'undefined' ? options.esModule : true;
  return `${esModule ? 'export default' : 'module.exports ='} ${publicPath};`;
1
2

由此，可以看到esModule默认为true，为true时使用的是es6模块化解析，把它设置成false后，实际上是换成了commonjs模块化的方式去解析。

为什么改成commonjs模块化方式可以解决问题？

在这里我们就需要思考引入图片的模块化处理方式是什么？

我们的图片在样式中作为背景图片使用

.box1 {
  width: 536px;
  height: 354px;
  background-image: url("../images/1.jpg");
}
1
2
3
4
5

在main.js打包入口中需要引入样式，才能被webpack解析

import './css/index.css'
1

由于样式交给了css-loader去解析，所以关键就来到了css-loader到底是如何处理background-image: url()的。
css-loader处理url的方式：https://webpack.docschina.org/loaders/css-loader/#url
在官方文档中可以看到url指定的图片，最终会采用require的方式去导入。即，使用commonjs模块化。

url(image.png) => require('./image.png')
1

总结

之所以出现404问题是因为引入图片和解析图片采用的是不同的模块化方式。css-loader已经默认是commonjs了，我们将模块化方式统一成commonjs，用module.exports导出即可。

file-loader.js

const loaderUtils = require('loader-utils')
// https://github.com/webpack/loader-utils#interpolatename
module.exports = function (content) {
    // 根据文件内容生成hash
    let interpolatedName = loaderUtils.interpolateName(this,'[hash].[ext]',{content})
    interpolatedName = 'images/' + interpolatedName
    // 输出
    this.emitFile(interpolatedName, content)
    // 返回文件路径
    return `module.exports = '${interpolatedName}'`
}
// 二进制格式
module.exports.raw = true
1
2
3
4
5
6
7
8
9
10
11
12
13