⑴ webpack基本使用
step1: 創建一個項目錄
注意：項目名一般 不要帶中文
step2: 創建 package.json
或者：
step4: 處理第三方文件
html文件中需要引入多個js文件或者第三方模塊(例如：jquery.js)，只引入項目js入口文件( main.js ),其他js文件均在入口文件中導入。導致可能JS文件中使用了瀏覽器不識別的高級語法:
總結：webpack可以做兩件事情況：
step5: 配置入口文件和出口文件
每次修改js文件，手動輸入命令： webpack 入口文件路徑 -o 出口文件路徑 重新打包， 每次都要輸入入口文件和出口文件，麻煩。可以在項目目錄下建立配置文件 webpack.config.js ,指定入口文件和出口文件:
重新打包：
step6: 實現自動打包編譯
每次修改js文件，都要手動重新打包，還是麻煩？使用 webpack-dev-server 這個工具，來實現自動打包編譯的功能。
webpack-dev-server 這個工具，如果想要正常運行，要求在本地項目中必須安裝 webpack
在 package.json 文件中配置命令：
在終端中執行命令：
註：在終端執行 npm run dev ，就等於執行 webpack-dev-server 命令。這將在node中開啟一個伺服器，並且立即打包。每次修改文件，ctrl + s 保存文件,webpack-dev-server工具自動監聽文件改變，並且自動打包。
改變文件引用路徑：
執行上述命令後終端會有類似信息輸出：
【 Project is running at http://localhost:8080/ 】——webpack-dev-server工具將項目託管到localhost:8080/埠上
【webpack output is served from /】——打包好的文件通過localhost:8080/bundle.js訪問
【Content not from webpack is served from C:UsersyfbDesktop前端學習案例4.27wabpackDemo_1src】——不是通過webpack打包的文件，則是以src為根目錄訪問。
該項目根目錄下並不存在bundel.js文件，我們可以認為webpack-dev-server把打包好的文件，以一種虛擬的形式託管到了咱們項目的根目錄中，雖然我們看不到它，但是可以認為和 dist、src、node_moles平級，有一個看不見的文件，叫做 bundle.js。其實是為了頻繁打包，提高效率，直接把打包的文件放在內存中。
因為項目託管到新伺服器，現在應該訪問的是 該伺服器 下的項目，文件引用路徑也要改變:
step7: 自動打開瀏覽器進行訪問、配置埠號、指定託管的根目錄、熱重載（只是修改補丁，不重新生成整個bundle.js文件）
在 package.json 中配置命令，並重啟伺服器：
step8: 使用 html-webpack-plugin 插件
使用 --contentBase 指令的過程比較繁瑣，需要指定啟動的目錄，同時還需要修改index.html中script標簽的src屬性。
安裝 html-webpack-plugin 插件：
在 webpack.config.js 配置文件中配置插件：
html-webpack-plugin 插件的兩個作用：
step9: 處理樣式文件
html文件中需要引入css、less、sass樣式文件。默認情況下，webpack處理不了這些樣式文件。
處理css文件：
處理less樣式文件
⑵ webpack工作流程
Webpack 的運行流程是一個串列的過程,從啟動到結束會依次執行以下流程 :
1.初始化參數：從配置文件和 Shell 語句中讀取與合並參數,得出最終的參數。
2.開始編譯：用上一步得到的參數初始化 Compiler 對象,載入所有配置的插件,執行對象的 run 方法開始執行編譯。
3.確定入口：根據配置中的 entry 找出所有的入口文件。
4.編譯模塊：從入口文件出發,調用所有配置的 Loader 對模塊進行翻譯,再找出該模塊依賴的模塊,再遞歸本步驟直到所有入口依賴的文件都經過了本步驟的處理。
5.完成模塊編譯：在經過第 4 步使用 Loader 翻譯完所有模塊後,得到了每個模塊被翻譯後的最終內容以及它們之間的依賴關系。
6.輸出資源：根據入口和模塊之間的依賴關系,組裝成一個個包含多個模塊的 Chunk,再把每個 Chunk 轉換成一個單獨的文件加入到輸出列表,這步是可以修改輸出內容的最後機會。
7.輸出完成：在確定好輸出內容後,根據配置確定輸出的路徑和文件名,把文件內容寫入到文件系統。
在以上過程中,Webpack 會在特定的時間點廣播出特定的事件,插件在監聽到感興趣的事件後會執行特定的邏輯,並且插件可以調用 Webpack 提供的 API 改變 Webpack 的運行結果。
⑶ 從 Webpack 到 Snowpack, 編譯速度提升十倍以上——TRPG Engine遷移小記
原文地址: http://moonrailgun.com/posts/74598ef5/
TRPG Engine 經過長久以來的迭代，項目已經顯得非常臃腫了。數分鍾的全量編譯, 每次按下保存都會觸發一次 10s 到 1m 不等的增量編譯讓我苦不堪言, 龐大的依賴使其每一次編譯都會涉及很多文件和很多包，長時的編譯時間大大降低了開發效率與迭代速度。
經過一段時間的考察，我選擇了 Snowpack 作為解決方案。與 Webpack 不同的是，除了第一次的全量編譯以外， Snowpack 的增量編譯不會涉及到龐大的 node_moles 文件夾, 准確來說只會編譯變更文件本身。甚至於如果沒有對依賴進行變更，下次的全量編譯會直接動用之前編譯的文件緩存，不需要花時間等待 node_moles 的編譯。
為什麼會這么快？這是由於 Snowpack 本身的實現與設計哲學有關的。相比 Webpack , Snowpack 利用了現代瀏覽器的本身的 mole 系統，跳過復雜的模型之間的組織編譯過程而只關注於變更文件本身的編譯，這樣當然快了。
拿 Snowpack 官方的一張圖來說:
snowpack 的最我譯單位是文件，而 webpack 的最我譯單位為 chunk , 而 chunk 還需要額外的計算, 不論是編譯部分還是編譯後的組裝部分。snowpack的設計邏輯天生決定了她的速度。
優化前(使用 webpack ):
全量編譯:
增量編譯:
全量請求用時:
優化後(使用 snowpack ):
全量編譯:
增量編譯:
(看不到編譯用時，但是體感在1s內. 而且該效果在電腦運行其他應用時更加顯著)
全量請求用時:
以上測試是保證電腦在空閑時間，且保存與操作內容為同一文件
該用時已經是平時操作的最快時間，為此我的MBR重啟了一次強制清空了swap空間, 實際表現會更加顯著
因為文件依賴於瀏覽器的耗時，而瀏覽器需要串列請求依賴，因此耗時會更加長
但實際使用中使用snowpack會更加優秀。因為其相比webpack會大大節約電腦資源。在webpack編譯時會佔用大量的電腦資源，會影響到其他操作
TRPG Engine 算是非常經典的 Webpack 應用了, 使用了各種Loader。光通用配置就有250+行，各種優化配置，各種 alias。等等長時間迭代積攢下來的配置，因此毫不意外的會遇到很多問題與坑。
以下是我遇到的問題與解決方案:
Snowpack雖然作為一個新興的打包工具，目前尚不是非常完善, 功能也沒有webpack這樣豐富與齊全。但是它的新的打包設計對於有一定規模的前端應用還是非常優秀的。能極大提升開發效率。不失為一種好的解決方案。當然最後輸出還是需要使用webpack對其進行一定的優化，畢竟原生的mole支持目前瀏覽器的支持度還沒有達到覆蓋一個理想的地步 https://caniuse.com/es6-mole
最後這是我最後提交的 pr