透过现象看webpack处理css文件中图片路径转换的具体过程


webpack是目前使用比较流行的一个前端模块打包器，前端的任何资源都被当成一个模块来处理，如图片、css文件等等。在基于webpack构建的前端项目中，一般都会配置有关css文件处理的规则，这其中也包括css文件中图片资源的处理，那么webpack到底是怎么处理它的呢？笔者之前也遇到过类似图片路劲的问题，为此还写过一篇博文webpack生成的css文件background-image url图片无法加载。今天就来说说webpack是怎么处理css文件中的图片路径的，首先上一个具体的例子。

一个具体问题


最近使用umi搭建前端的一个项目，在使用过程可能遇到一个umi的bug，为此还提出了一个issue 项目配置css module影响到css-loader对第三方库css文件中图片url的处理。顺便在简述下：




  • 在项目中通过设置cssLoaderOptions.modules为true来开启css module



  • 项目中引入了第三方库kindeditor的css文件。

    1
    import 'kindeditor/themes/default/default.css'

    该default.css文件中有通过url引入图片资源，并且图片资源非相对路径写法，例如其中一处的写法:

    1
    2
    3
      .ke-toolbar-icon-url {
       background-image: url(background.png);
      }


然后通过npm start开启本地服务进行预览时，编译报错，如下图:



奇怪，明明对应的图片资源是存在的，webpack编译时为啥找不到呢？苦苦寻思了一番没有找到答案，于是一头扎进webpack和css-loader源码的海洋中开启"寻宝"之旅。


不卖关子了，导致上述的直接原因：



css-loader没有对css文件的url方法进行处理（转化为相对路径）


这样导致webpack在整合经过loader处理后的default.css模块时，因为模块用到require(background.png)来引用图片资源，此时就用到Nodejs的模块加载机制，其具体可以查看本博客另一篇文章谈谈npm依赖管理，也可以查看nodejs官网module章节。nodejs在解析background.png图片路径时，会将其解析为第三方模块，这样会从node_modules中查找，通过在webpack中打印错误日志，可以从其中看出一些端倪，如下图，missing字段表示查找过的路径均没有找到对应的资源文件。



umi内部其实使用css-loader-1(fork [email protected]而来)来处理css文件的， 导致css-loader没有对css文件图片路径进行处理的底层原因：



项目开启css module后，不该影响到node_modules中css文件的css module的情况而实际上产生了影响；导致没有对第三方库中的css文件中图片路径进行处理

webpack是怎么转化css中的图片路径的？


如果单纯为了解决上面问题就可以到此为止，但是处于好奇，毕竟被坑了几次，想知道webpack是怎么处理css文件中的图片路径的。例如我们在项目中这样写过css：

1
2
3
.xxa {
    background: url(background.png)
}

或者这样：

1
2
3
.xxb {
    background: url(~alias/background.png)
}

在项目中，不论我们用less、stylus还是sass等css预处理库编写css，其最终是通过对应的loader如less-loader将编写的样式转换变换为css，然后通过css-loader来处理css中有关路径的转换，其作用拿其官网的介绍来说：



The css-loader interprets @import and url() like import/require() and will resolve them.


最常见处理css样式的项目，一般经过以下几个loader从右到左顺序执行，拿less编写的样式来说，以内联loader的展示形式来说明：

1
!!css-loader!post-loader!less-loader!./xxx/xx.less

当然css-loader处理后还要经过style-loader或者mini-css-extract-plugin提供的loader处理，但是这不在本次谈论范围。


下面通过一幅图来看看经过webpack解析模块到css产出这一过程，webpack帮我们做了什么。



具体就来简单分析整个流程，可能分析有不正确的地方，还请大家批评指正


NormalModuleFactory解析并创建模块




  • 首先从入口文件（entry配置的文件）开始构建，使用NormalModuleFactory来解析并创建模块



  • NormalModuleFactory使用enhance-resolve来解析依赖的模块绝对地址，如果模块地址解析错误就会如文章开头的问题抛出错误，解析正确则会创建依赖模块。如上图中的./index.css，模块地址解析成功后，webpack为index.css创建的模块属性如下图：



    创建的一个模块，一般包括模块的type、context、request、userRequest、rawRequest、resource、dependencies和loaders等模块相关信息。


    模块创建后，会用其依赖处理的loader来编译模块内容，模块依赖的loader存放在模块的loader属性数组中；对于css文件最后是用css-loader来处理。


css-loader编译css文件


css-loader官网说的会对css文件的url/@import进行处理，但是具体实现细节并没有详细阐述。下面来简单说说对css-loader的主要功能：




  • 转换css中的url和@import为 require/import；


    例如url中的地址（绝对地址除外）会被解析为相对地址，防止webpack在解析模块地址时出错；这其中包括webpack alias别名组成的地址和node_moduels库中地址。顺便说下：



    css-loader内部是通过postcss生成css的ast并遍历找出其url方法来完成转换的。




  • 按comonjs模块的形式生成css文件模块内容


    css文件最终转换后的commonjs模块形式，模块的后缀还是.css，其内容如下图所示：




  • css-loader还处理css module，也是通过遍历css的ast来完成转换


这样通过css-loader完成了css文件中图片url路径的转换，有助于webpack寻找图片资源的具体位置。


url-loader处理图片资源


其实，在css-loader处理完css模块过程中，会再次通过NormalModuleFactory来解析并创建其内部的图片模块，webpack模块对应的属性如下图：



生成图片对应的commonjs模块内容可能为base64的内容，如下图：



也可能为图片资源产出的引用地址，如下图：



这主要取决于url-loader在处理图片资源时是否指定limit配置项值，该值会跟图片内容大小进行比较。在limit值小于图片内容大小时，则使用file-loader来实现图片提出到webpack编译产出的对应位置下。


上面图片模块内容为图片产出地址，正是file-loader处理的结果，其实现以下几项功能：




  • 图片内容会抽离到webapck的编译产出位置。



  • 按照loader的name配置和webpack的publicPath配置项生成最终的url。


    因为图片的内容被抽离掉，那么webpack生成的图片模块内容应该为该图片的引用地址。这涉及到两部分




    • 根据file-loader的name配置项生成相对地址部分。


      如下file-loader配置项：

    1
    2
    3
    4
    5
    6
    7
    {
     test: /.(png|jpe?g|gif)$/i,
     loader: 'file-loader',
     options: {
     name: 'static/[name].[hash:8].[ext]',
     },
    }

    然后根据loader-utils的interpolateName方法解析对应的url。例如上面css文件的图片地址转换结果：


    ./background.png会转换为: static/background.a9153e95.png




    • 根据webpackConfig.output.publishPath生成图片的引用地址。


      最终生成的地址为：


      __webpack_public_path__ + "static/background.a9153e95.png";


经过上面步骤的处理，我们看到产出的最终css文件的效果如下图:



顺便说一下，如果产出的css文件经过mini-css-extract-plugin提供的loader进行统一抽离，那么它也可能会影响css文件中图片的引用路径，尤其该loader配置了publicPath内容，如下面loader的配置：

1
2
3
4
5
6
{
   loader: MiniCssExtractPlugin.loader,
   options: {
     publicPath: 'public/path/to/'
   }
}

那么css文件中图片的路径最终结果如下图：



这就是webapck通过各种loader处理css中图片路劲的过程，通过这一过程我们可能只是大概对这一过程有一个大概的认知，如果要深入理解还是需要花时间研究。


参考文献




  • css-loaderr



  • url-loader



  • file-loader



  • mini-css-extract-plugin