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

站长

发表文章数:4263

C# 定时器保活机制引起的内存泄露问题

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文件。

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

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

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

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

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

奇怪,明明对应的图片资源是存在的,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字段表示查找过的路径均没有找到对应的资源文件。

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

umi内部其实使用css-loader-1(fork css-loader@1.x而来)来处理css文件的, 导致css-loader没有对css文件图片路径进行处理的底层原因:

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

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

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

.xxa {
    background: url(background.png)
}

或者这样:

.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的展示形式来说明:

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

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

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

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

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

NormalModuleFactory解析并创建模块

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

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

    透过现象看webpack处理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@importrequire/import

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

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

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

    算法入门基础

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

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

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

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

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

url-loader处理图片资源

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

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

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

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

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

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

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

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

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

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

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

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

      如下file-loader配置项:

    {
     test: /\.(png|jpe?g|gif)$/i,
     loader: 'file-loader',
     options: {
     name: 'static/[name].[hash:8].[ext]',
     },
    }

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

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

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

      最终生成的地址为:

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

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

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

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

{
   loader: MiniCssExtractPlugin.loader,
   options: {
     publicPath: 'public/path/to/'
   }
}

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

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

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

参考文献

《ASP.NET Core 高性能系列》关于.NET Core的配置信息的若干事项

分享到:
赞(0) 打赏 生成海报

长按图片转发给朋友

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏

投稿赚钱
2020年在家赚取零花钱
切换注册

登录

忘记密码 ?

您也可以使用第三方帐号快捷登录

Q Q 登 录
微 博 登 录
切换登录

注册