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編譯時為啥找不到呢？苦苦尋思了一番沒有找到答案，於是一頭扎進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 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-loaderinterprets@importandurl()likeimport/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幫我們做了什么。
具體就來簡單分析整個流程，可能分析有不正確的地方，還請大家批評指正
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配置項：
{ 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的配置：
{
loader: MiniCssExtractPlugin.loader,
options: {
publicPath: 'public/path/to/'
}
}
那么css文件中圖片的路徑最終結果如下圖：
這就是webapck通過各種loader處理css中圖片路勁的過程，通過這一過程我們可能只是大概對這一過程有一個大概的認知，如果要深入理解還是需要花時間研究。