如何開發webpack loader

一、單一任務

loaders可以被鏈式呼叫，為每一步建立一個loader而非一個loader做所有事情。也就是說，在非必要的狀況下沒有必要將他們轉換為js。

例如：透過查詢字串將一個字串模板轉化為html。

如果你寫了個loader。做了所有事情那麼你違背了loader的第一條要求。你應該為每一個task建立一個loader並且透過管道來使用它們

(1)ade-loader:  轉換模板為一個module

(2) apply-loader:  建立一個module並透過查詢引數來返回結果

(3)html-loade:  建立一個處理html並返回一個string的模組

二、建立moulde話的模組，即正常的模組

loader產出的module應該和遵循和普通的module一樣的設計原則。

舉個例子，下面這樣設計是不好的，沒有模組化，依賴全域性狀態。

三、儘量表明該loader是否可以快取

大部分loaders是cacheable，所以應該標明是否cacheable，只需要在loader裡面呼叫即可。

四、不要在執行和模組之間儲存狀態

(1)一個loader相對於其他編譯後的模組應該是獨立的。 除非其可以自己處理這些狀態

(2)一個loader相對於同一模組之前的編譯過程應該是獨立的。

五、標明依賴

如果該loader引用了其他資源(例如檔案系統)， 必須宣告它們。這些資訊用來是快取的loader失效並且重新編譯它們。

六、解析依賴

很多語言都提供了一些規範來宣告依賴，例如css中的 @import 和 url(...)。這些依賴應該被模組系統所解析。

下面是兩種解決方式：

1、將它們轉化成require

2、 用this.resolve方法來解析路徑

下面是兩個示例：

1、css-loader: 將依賴轉化成require，即用require來替換@import和 url(...)，解析對其他樣式檔案的依賴

2、less-loader: 不能像css-loader那樣做，因為所有的less檔案需要一起編譯來解析變數和mixins。因此其透過一個公共的路徑邏輯來擴充套件less編譯過程。這個公共的邏輯使用this.resolve來解析帶有module系統配置項的檔案。例如aliasing, custom module directories等。

如果語言僅僅接受相對urls(如css中url(file) 總是代表./file)，使用~來說明成模組依賴.

七、抽離公共程式碼

extract common code 我感覺還是翻譯成上面的標題比較好。其實所有語言都遵循該思想，即封裝

不要寫出來很多每個模組都在使用的程式碼，在loader中建立一個runtime檔案，將公共程式碼放在其中

八、避免寫入絕對路徑

不要把絕對路徑寫入到模組程式碼中。它們將會破壞hash的過程當專案的根目錄發生改變的時候。應該使用loader-utils的 stringifyRequest方法來絕對路徑轉化為相對路徑。

例子：

九、使用peerDependencies來指明依賴的庫

使用peerDependency允許應用開發者去在package.json裡說明依賴的具體版本。這些依賴應該是相對開放的允許工具庫升級而不需要重新發布loader版本。簡而言之，對於peerDependency依賴的庫應該是松耦合的，當工具庫版本變化的時候不需要重新變更loader版本。

十、可程式設計物件作為查詢項

有些情況下，loader需要某些可程式設計的物件但是不能作為序列化的query引數被方法解析。例如less-loader透過具體的less-plugin提供了這種可能。這種情況下，loader應該允許擴充套件webpack的options物件去獲得具體的option。為了避免名字衝突，基於loader的名稱空間來命名是很必要的。