本篇內(nèi)容主要講解“怎么開發(fā)Webpack Loader”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“怎么開發(fā)Webpack Loader”吧!
一、單一任務
loaders可以被鏈式調(diào)用，為每一步創(chuàng)建一個loader而非一個loader做所有事情。也就是說，在非必要的狀況下沒有必要將他們轉換為js。
例如：通過查詢字符串將一個字符串模板轉化為html。
如果你寫了個loader。做了所有事情那么你違背了loader的第一條要求。你應該為每一個task創(chuàng)建一個loader并且通過管道來使用它們
(1)ade-loader: 轉換模板為一個module
(2) apply-loader:創(chuàng)建一個module并通過查詢參數(shù)來返回結果
(3)html-loade: 創(chuàng)建一個處理html并返回一個string的模塊
二、創(chuàng)建moulde話的模塊，即正常的模塊
loader產(chǎn)出的module應該和遵循和普通的module一樣的設計原則。
舉個例子，下面這樣設計是不好的，沒有模塊化，依賴全局狀態(tài)。
三、盡量表明該loader是否可以緩存
大部分loaders是cacheable，所以應該標明是否cacheable，只需要在loader里面調(diào)用即可。
四、不要在運行和模塊之間保存狀態(tài)
(1)一個loader相對于其他編譯后的模塊應該是獨立的。 除非其可以自己處理這些狀態(tài)
(2)一個loader相對于同一模塊之前的編譯過程應該是獨立的。
五、標明依賴
如果該loader引用了其他資源(例如文件系統(tǒng))， 必須聲明它們。這些信息用來是緩存的loader失效并且重新編譯它們。
六、解析依賴
很多語言都提供了一些規(guī)范來聲明依賴，例如css中的 @import 和 url(...)。這些依賴應該被模塊系統(tǒng)所解析。
下面是兩種解決方式：
1、將它們轉化成require
2、 用this.resolve方法來解析路徑
下面是兩個示例：
1、css-loader: 將依賴轉化成require，即用require來替換@import和 url(...)，解析對其他樣式文件的依賴
2、less-loader: 不能像css-loader那樣做，因為所有的less文件需要一起編譯來解析變量和mixins。因此其通過一個公共的路徑邏輯來擴展less編譯過程。這個公共的邏輯使用this.resolve來解析帶有module系統(tǒng)配置項的文件。例如aliasing, custom module directories等。
如果語言僅僅接受相對urls(如css中url(file) 總是代表./file)，使用~來說明成模塊依賴.
七、抽離公共代碼
extract common code 我感覺還是翻譯成上面的標題比較好。其實所有語言都遵循該思想，即封裝
不要寫出來很多每個模塊都在使用的代碼，在loader中創(chuàng)建一個runtime文件，將公共代碼放在其中
八、避免寫入絕對路徑
不要把絕對路徑寫入到模塊代碼中。它們將會破壞hash的過程當項目的根目錄發(fā)生改變的時候。應該使用loader-utils的 stringifyRequest方法來絕對路徑轉化為相對路徑。
例子：
九、使用peerDependencies來指明依賴的庫
使用peerDependency允許應用開發(fā)者去在package.json里說明依賴的具體版本。這些依賴應該是相對開放的允許工具庫升級而不需要重新發(fā)布loader版本。簡而言之，對于peerDependency依賴的庫應該是松耦合的，當工具庫版本變化的時候不需要重新變更loader版本。
十、可編程對象作為查詢項
有些情況下，loader需要某些可編程的對象但是不能作為序列化的query參數(shù)被方法解析。例如less-loader通過具體的less-plugin提供了這種可能。這種情況下，loader應該允許擴展webpack的options對象去獲得具體的option。為了避免名字沖突，基于loader的命名空間來命名是很必要的。
到此，相信大家對“怎么開發(fā)Webpack Loader”有了更深的了解，不妨來實際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關內(nèi)容可以進入相關頻道進行查詢，關注我們，繼續(xù)學習！
重慶分公司
重慶分公司
