寫在開頭
先說說為什么要寫這篇文章, 最初的原因是組里的小朋友們看了webpack文檔后, 表情都是這樣的: (摘自webpack一篇文檔的評論區)
和這樣的:
是的, 即使是外國佬也在吐槽這文檔不是人能看的. 回想起當年自己啃webpack文檔的血與淚的往事, 覺得有必要整一個教程, 可以讓大家看完后愉悅地搭建起一個webpack打包方案的項目.
可能會有人問webpack到底有什么用, 你不能上來就糊我一臉代碼讓我馬上搞, 我照著搞了一遍結果根本沒什么naizi用, 都是騙人的. 所以, 在說webpack之前, 我想先談一下前端打包方案這幾年的演進歷程, 在什么場景下, 我們遇到了什么問題, 催生出了應對這些問題的工具. 了解了需求和目的之后, 你就知道什么時候webpack可以幫到你. 我希望我用完之后很爽, 你們用完之后也是.
先說說前端打包方案的黑暗歷史
在很長的一段前端歷史里, 是不存在打包這個說法的. 那個時候頁面基本是純靜態的或者服務端輸出的, 沒有AJAX, 也沒有jQuery. 那個時候的JavaScript就像個玩具, 用處大概就是在側欄弄個時鐘, 用media player放個mp3之類的腳本, 代碼量不是很多, 直接放在<script>標簽里或者弄個js文件引一下就行, 日子過得很輕松愉快.
隨后的幾年, 人們開始嘗試在一個頁面里做更多的事情. 容器的顯示, 隱藏, 切換. 用css寫的彈層, 圖片輪播等等. 但如果一個頁面內不能向服務器請求數據, 能做的事情畢竟有限的, 代碼的量也能維持在頁面交互邏輯范圍內. 這時候很多人開始突破一個頁面能做的事情的范圍, 使用隱藏的iframe和flash等作為和服務器通信的橋梁, 新世界的大門慢慢地被打開, 在一個頁面內和服務器進行數據交互, 意味著以前需要跳轉多個頁面的事情現在可以用一個頁面搞定. 但由于iframe和flash技術過于tricky和復雜, 并沒能得到廣泛的推廣.
直到Google推出Gmail的時候(2004年), 人們意識到了一個被忽略的接口, XMLHttpRequest, 也就是我們俗稱的AJAX, 這是一個使用方便的, 兼容性良好的服務器通信接口. 從此開始, 我們的頁面開始玩出各種花來了, 前端一下子出現了各種各樣的庫, Prototype, Dojo, MooTools, Ext JS, jQuery... 我們開始往頁面里插入各種庫和插件, 我們的js文件也就爆炸了...
隨著js能做的事情越來越多, 引用越來越多, 文件越來越大, 加上當時大約只有2Mbps左右的網速, 下載速度還不如3G網絡, 對js文件的壓縮和合并的需求越來越強烈, 當然這里面也有把代碼混淆了不容易被盜用等其他因素在里面. JSMin, YUI Compressor, Closure Compiler, UglifyJS 等js文件壓縮合并工具陸陸續續誕生了. 壓縮工具是有了, 但我們得要執行它, 最簡單的辦法呢, 就是windows上搞個bat腳本, mac/linux上搞個bash腳本, 哪幾個文件要合并在一塊的, 哪幾個要壓縮的, 發布的時候運行一下腳本, 生成壓縮后的文件.
基于合并壓縮技術, 項目越做越大, 問題也越來越多, 大概就是以下這些問題:
- 庫和插件為了要給他人調用, 肯定要找個地方注冊, 一般就是在window下申明一個全局的函數或對象. 難保哪天用的兩個庫在全局用同樣的名字, 那就沖突了.
- 庫和插件如果還依賴其他的庫和插件, 就要告知使用人, 需要先引哪些依賴庫, 那些依賴庫也有自己的依賴庫的話, 就要先引依賴庫的依賴庫, 以此類推...
恰好就在這個時候(2009年), 隨著后端JavaScript技術的發展, 人們提出了CommonJS的模塊化規范, 大概的語法是: 如果a.js依賴b.js和c.js, 那么就在a.js的頭部, 引入這些依賴文件:
var b = require('./b')
var c = require('./c')
那么變量b和c會是什么呢? 那就是b.js和c.js導出的東西, 比如b.js可以這樣導出:
exports.square = function(num) {
return num * num
}
然后就可以在a.js使用這個square方法:
var n = b.square(2)
如果c.js依賴d.js, 導出的是一個Number, 那么可以這樣寫:
var d = require('./d')
module.exports = d.PI // 假設d.PI的值是3.14159
那么a.js中的變量c就是數字3.14159, 具體的語法規范可以查看Node.js的文檔.
但是CommonJS在瀏覽器內并不適用. 因為require()的返回是同步的, 意味著有多個依賴的話需要一個一個依次下載, 堵塞了js腳本的執行. 所以人們就在CommonJS的基礎上定義了Asynchronous Module Definition (AMD)規范(2011年), 使用了異步回調的語法來并行下載多個依賴項, 比如作為入口的a.js可以這樣寫:
require(['./b', './c'], function(b, c) {
var n = b.square(2)
console.log(c) // 3.14159
})
相應的導出語法也是異步回調方式, 比如c.js依賴d.js, 就寫成這樣:
define(['./d'], function(d) {
return d.PI
})
可以看到, 定義一個模塊是使用define()函數, define()和require()的區別是, define()必須要在回調函數中返回一個值作為導出的東西, require()不需要導出東西, 因此回調函數中不需要返回值, 也無法作為被依賴項被其他文件導入, 因此一般用于入口文件, 比如頁面中這樣加載a.js:
<script src="js/require.js" data-main="js/a"></script>
以上是AMD規范的基本用法, 更詳細的就不多說了(反正也淘汰了~), 有興趣的可以看這里.
js模塊化問題基本解決了, css和html也沒閑著. 什么less, sass, stylus的css預處理器橫空出世, 說能幫我們簡化css的寫法, 自動給你加vendor prefix. html在這期間也出現了一堆模板語言, 什么handlebars, ejs, jade, 可以把ajax拿到的數據插入到模板中, 然后用innerHTML顯示到頁面上.
托AMD和CSS預處理和模板語言的福, 我們的編譯腳本也洋洋灑灑寫了百來行. 命令行腳本有個不好的地方, 就是windows和mac/linux是不通用的, 如果有跨平臺需求的話, windows要裝個可以執行bash腳本的命令行工具, 比如msys(目前最新的是msys2), 或者使用php或python等其他語言的腳本來編寫, 對于非全棧型的前端程序員來說, 寫bash/php/python還是很生澀的. 因此我們需要一個簡單的打包工具, 可以利用各種編譯工具, 編譯/壓縮js, css, html, 圖片等資源. 然后Grunt產生了(2012年), 配置文件格式是我們最愛的js, 寫法也很簡單, 社區有非常多的插件支持各種編譯, lint, 測試工具. 一年多后另一個打包工具gulp誕生了, 擴展性更強, 采用流式處理效率更高.
依托AMD模塊化編程, SPA(Single-page application)的實現方式更為簡單清晰, 一個網頁不再是傳統的類似word文檔的頁面, 而是一個完整的應用程序. SPA應用有一個總的入口頁面, 我們通常把它命名為index.html, app.html, main.html, 這個html的<body>一般是空的, 或者只有總的布局(layout), 比如下圖:
布局會把header, nav, footer的內容填上, 但main區域是個空的容器. 這個作為入口的html最主要的工作是加載啟動SPA的js文件, 然后由js驅動, 根據當前瀏覽器地址進行路由分發, 加載對應的AMD模塊, 然后該AMD模塊執行, 渲染對應的html到頁面指定的容器內(比如圖中的main). 在點擊鏈接等交互時, 頁面不會跳轉, 而是由js路由加載對應的AMD模塊, 然后該AMD模塊渲染對應的html到容器內.
雖然AMD模塊讓SPA更容易地實現, 但小問題還是很多的:
- 不是所有的第三方庫都是AMD規范的, 這時候要配置
shim, 很麻煩. - 雖然RequireJS支持插件的形式通過把html作為依賴加載, 但html里面的
<img>的路徑是個問題, 需要使用絕對路徑并且保持打包后的圖片路徑和打包前的路徑不變, 或者使用html模板語言把src寫成變量, 在運行時生成. - 不支持動態加載css, 變通的方法是把所有的css文件合并壓縮成一個文件, 在入口的html頁面一次性加載.
- SPA項目越做越大, 一個應用打包后的js文件到了幾MB的大小. 雖然
r.js支持分模塊打包, 但配置很麻煩, 因為模塊之間會互相依賴, 在配置的時候需要exclude那些通用的依賴項, 而依賴項要在文件里一個個檢查. - 所有的第三方庫都要自己一個個的下載, 解壓, 放到某個目錄下, 更別提更新有多麻煩了. 雖然可以用npm包管理工具, 但npm的包都是CommonJS規范的, 給后端Node.js用的, 只有部分支持AMD規范, 而且在npm3.0之前, 這些包有依賴項的話也是不能用的. 后來有個bower包管理工具是專門的web前端倉庫, 這里的包一般都支持AMD規范.
- AMD規范定義和引用模塊的語法太麻煩, 上面介紹的AMD語法僅是最簡單通用的語法, API文檔里面還有很多變異的寫法, 特別是當發生循環引用的時候(a依賴b, b依賴a), 需要使用其他的語法解決這個問題. 而且npm上很多前后端通用的庫都是CommonJS的語法. 后來很多人又開始嘗試使用ES6模塊規范, 如何引用ES6模塊又是一個大問題.
- 項目的文件結構不合理, 因為grunt/gulp是按照文件格式批量處理的, 所以一般會把js, html, css, 圖片分別放在不同的目錄下, 所以同一個模塊的文件會散落在不同的目錄下, 開發的時候找文件是個麻煩的事情. code review時想知道一個文件是哪個模塊的也很麻煩, 解決辦法比如又要在imgs目錄下建立按模塊命名的文件夾, 里面再放圖片.
到了這里, 我們的主角webpack登場了(2012年)(此處應有掌聲).
和webpack差不多同期登場的還有Browserify. 這里簡單介紹一下Browserify, Browserify的目的是讓前端也能用CommonJS的語法require('module')來加載js. 它會從入口js文件開始, 把所有的require()調用的文件打包合并到一個文件, 這樣就解決了異步加載的問題. 那么Browserify有什么不足之處導致我不推薦使用它呢? 主要原因有下面幾點:
- 最主要的一點, Browserify不支持把代碼打包成多個文件, 在有需要的時候加載. 這就意味著訪問任何一個頁面都會全量加載所有文件.
- Browserify對其他非js文件的加載不夠完善, 因為它主要解決的是
require()js模塊的問題, 其他文件不是它關心的部分. 比如html文件里的img標簽, 它只能轉成Data URI的形式, 而不能替換為打包后的路徑. - 因為上面一點Browserify對資源文件的加載支持不夠完善, 導致打包時一般都要配合gulp或grunt一塊使用, 無謂地增加了打包的難度.
- Browserify只支持CommonJS模塊規范, 不支持AMD和ES6模塊規范, 這意味舊的AMD模塊和將來的ES6模塊不能使用.
基于以上幾點, Browserify并不是一個理想的選擇. 那么webpack是否解決了以上的幾個問題呢? 廢話, 不然介紹它干嘛. 那么下面章節我們用實戰的方式來說明webpack是怎么解決上述的問題的.
上手先搞一個簡單的SPA應用
一上來步子太大容易扯到蛋, 讓我們先弄個最簡單的webpack配置來熱一下身.
安裝Node.js
webpack是基于我大Node.js的打包工具, 上來第一件事自然是先安裝Node.js了, 傳送門->.
初始化一個項目
我們先隨便找個地方, 建一個文件夾叫simple, 然后在這里面搭項目. 完成品在examples/simple目錄, 大家搞的時候可以參照一下. 我們先看一下目錄結構:
├── dist 打包輸出目錄, 只需部署這個目錄到生產環境
├── package.json 項目配置信息
├── node_modules npm安裝的依賴包都在這里面
├── src 我們的源代碼
│ ├── components 可以復用的模塊放在這里面
│ ├── index.html 入口html
│ ├── index.js 入口js
│ ├── libs 不在npm和git上的庫扔這里
│ └── views 頁面放這里
└── webpack.config.js webpack配置文件
打開命令行窗口, cd到剛才建的simple目錄. 然后執行這個命令初始化項目:
npm init
命令行會要你輸入一些配置信息, 我們這里一路按回車下去, 生成一個默認的項目配置文件package.json.
給項目加上語法報錯和代碼規范檢查
我們安裝eslint, 用來檢查語法報錯, 當我們書寫js時, 有錯誤的地方會出現提示.
npm install eslint eslint-config-enough eslint-loader --save-dev
npm install可以一條命令同時安裝多個包, 包之間用空格分隔. 包會被安裝進node_modules目錄中.
--save-dev會把安裝的包和版本號記錄到package.json中的devDependencies對象中, 還有一個--save, 會記錄到dependencies對象中, 它們的區別, 我們可以先簡單的理解為打包工具和測試工具用到的包使用--save-dev存到devDependencies, 比如eslint, webpack. 瀏覽器中執行的js用到的包存到dependencies, 比如jQuery等. 那么它們用來干嘛的?
因為有些npm包安裝是需要編譯的, 那么導致windows/mac/linux上編譯出的可執行文件是不同的, 也就是無法通用, 因此我們在提交代碼到git上去的時候, 一般都會在.gitignore里指定忽略node_modules目錄和里面的文件, 這樣其他人從git上拉下來的項目是沒有node_modules目錄的, 這時我們需要運行
npm install
它會讀取package.json中的devDependencies和dependencies字段, 把記錄的包的相應版本下載下來.
這里eslint-config-enough是配置文件, 它規定了代碼規范, 要使它生效, 我們要在package.json中添加內容:
{
"eslintConfig": {
"extends": "enough",
"env": {
"browser": true,
"node": true
}
}
}
業界最有名的語法規范是airbnb出品的, 但它規定的太死板了, 比如不允許使用for-of和for-in等. 感興趣的同學可以參照這里安裝使用.
eslint-loader用于在webpack編譯的時候檢查代碼, 如果有錯誤, webpack會報錯.
項目里安裝了eslint還沒用, 我們的IDE和編輯器也得要裝eslint插件支持它.
Visual Studio Code需要安裝ESLint擴展
atom需要安裝linter和linter-eslint這兩個插件, 裝好后重啟生效.
WebStorm需要在設置中打開eslint開關:
寫幾個頁面
我們寫一個最簡單的SPA應用來介紹SPA應用的內部工作原理. 首先, 建立src/index.html文件, 內容如下:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
</head>
<body>
</body>
</html>
它是一個空白頁面, 注意這里我們不需要自己寫<script src="index.js"></script>, 因為打包后的文件名和路徑可能會變, 所以我們用webpack插件幫我們自動加上.
然后重點是src/index.js:
// 引入作為全局對象儲存空間的global.js, js文件可以省略后綴
import g from './global'
// 引入頁面文件
import foo from './views/foo'
import bar from './views/bar'
const routes = {
'/foo': foo,
'/bar': bar
}
// Router類, 用來控制頁面根據當前URL切換
class Router {
start() {
// 點擊瀏覽器后退/前進按鈕時會觸發window.onpopstate事件, 我們在這時切換到相應頁面
// https://developer.mozilla.org/en-US/docs/Web/Events/popstate
window.addEventListener('popstate', () => {
this.load(location.pathname)
})
// 打開頁面時加載當前頁面
this.load(location.pathname)
}
// 前往path, 會變更地址欄URL, 并加載相應頁面
go(path) {
// 變更地址欄URL
history.pushState({}, '', path)
// 加載頁面
this.load(path)
}
// 加載path路徑的頁面
load(path) {
// 創建頁面實例
const view = new routes[path]()
// 調用頁面方法, 把頁面加載到document.body中
view.mount(document.body)
}
}
// new一個路由對象, 賦值為g.router, 這樣我們在其他js文件中可以引用到
g.router = new Router()
// 啟動
g.router.start()
現在我們還沒有講webpack配置所以頁面還無法訪問, 我們先從理論上講解一下, 等會弄好webpack配置后再實際看頁面效果. 當我們訪問 http://localhost:8100/foo 的時候, 路由會加載 ./views/foo/index.js文件, 我們來看看這個文件:
// 引入全局對象
import g from '../../global'
// 引入html模板, 會被作為字符串引入
import template from './index.html'
// 引入css, 會生成<style>塊插入到<head>頭中
import './style.css'
// 導出類
export default class {
mount(container) {
document.title = 'foo'
container.innerHTML = template
container.querySelector('.foo__gobar').addEventListener('click', () => {
// 調用router.go方法加載 /bar 頁面
g.router.go('/bar')
})
}
}
借助webpack插件, 我們可以import html, css等其他格式的文件, 文本類的文件會被儲存為變量打包進js文件, 其他二進制類的文件, 比如圖片, 可以自己配置, 小圖片作為Data URI打包進js文件, 大文件打包為單獨文件, 我們稍后再講這塊.
其他的src目錄下的文件大家自己瀏覽, 拷貝一份到自己的工作目錄, 等會打包時會用到.
頁面代碼這樣就差不多搞定了, 接下來我們進入webpack的安裝和配置階段.
安裝webpack和Babel
我們把webpack和它的插件安裝到項目:
npm install webpack webpack-dev-server html-webpack-plugin html-loader css-loader style-loader file-loader url-loader --save-dev
webpack-dev-server是webpack提供的用來開發調試的服務器, 讓你可以用 http://127.0.0.1:8080/ 這樣的url打開頁面來調試, 有了它就不用配置nginx了, 方便很多.
html-webpack-plugin, html-loader, css-loader, style-loader等看名字就知道是打包html文件, css文件的插件, 大家在這里可能會有疑問, html-webpack-plugin和html-loader有什么區別, css-loader和style-loader有什么區別, 我們等會看配置文件的時候再講.
file-loader和url-loader是打包二進制文件的插件, 具體也在配置文件章節講解.
接下來, 為了能讓不支持ES6的瀏覽器(比如IE)也能照常運行, 我們需要安裝babel, 它會把我們寫的ES6源代碼轉化成ES5, 這樣我們源代碼寫ES6, 打包時生成ES5.
npm install babel-core babel-preset-env babel-loader --save-dev
這里babel-core顧名思義是babel的核心編譯器. babel-preset-env是一個配置文件, 我們可以使用這個配置文件轉換ES2015/ES2016/ES2017到ES5, 是的, 不只ES6哦. babel還有其他配置文件. 如果只想用ES6, 可以安裝babel-preset-es2015:
npm install babel-preset-es2015 --save-dev
但是光安裝了babel-preset-env, 在打包時是不會生效的, 需要在package.json加入babel配置:
{
"babel": {
"presets": [
"env"
]
}
}
打包時babel會讀取package.json中babel字段的內容, 然后執行相應的轉換.
如果使用babel-preset-es2015, 這里相應的也要修改為:
{
"babel": {
"presets": [
"es2015"
]
}
}
babel-loader是webpack的插件, 我們下面章節再說.
配置webpack
包都裝好了, 接下來, 總算可以進入正題了, 是不是有點心累...呵呵. 我們來創建webpack配置文件webpack.config.js, 注意這個文件是在node.js中運行的, 因此不支持ES6的import語法. 我們來看文件內容:
const { resolve } = require('path')
const HtmlWebpackPlugin = require('html-webpack-plugin')
module.exports = {
// 配置頁面入口js文件
entry: './src/index.js',
// 配置打包輸出相關
output: {
// 打包輸出目錄
path: resolve(__dirname, 'dist'),
// 入口js的打包輸出文件名
filename: 'index.js'
},
module: {
/*
配置各種類型文件的加載器, 稱之為loader
webpack當遇到import ... 時, 會調用這里配置的loader對引用的文件進行編譯
*/
rules: [
{
/*
使用babel編譯ES6/ES7/ES8為ES5代碼
使用正則表達式匹配后綴名為.js的文件
*/
test: /\.js$/,
// 排除node_modules目錄下的文件, npm安裝的包不需要編譯
exclude: /node_modules/,
/*
use指定該文件的loader, 值可以是字符串或者數組.
這里先使用eslint-loader處理, 返回的結果交給babel-loader處理. loader的處理順序是從最后一個到第一個.
eslint-loader用來檢查代碼, 如果有錯誤, 編譯的時候會報錯.
babel-loader用來編譯js文件.
*/
use: ['babel-loader', 'eslint-loader']
},
{
// 匹配.html文件
test: /\.html$/,
/*
使用html-loader, 將html內容存為js字符串, 比如當遇到
import htmlString from './template.html'
template.html的文件內容會被轉成一個js字符串, 合并到js文件里.
*/
use: 'html-loader'
},
{
// 匹配.css文件
test: /\.css$/,
/*
先使用css-loader處理, 返回的結果交給style-loader處理.
css-loader將css內容存為js字符串, 并且會把background, @font-face等引用的圖片,
字體文件交給指定的loader打包, 類似上面的html-loader, 用什么loader同樣在loaders對象中定義, 等會下面就會看到.
*/
use: ['style-loader', 'css-loader']
},
{
/*
匹配各種格式的圖片和字體文件
上面html-loader會把html中<img>標簽的圖片解析出來, 文件名匹配到這里的test的正則表達式,
css-loader引用的圖片和字體同樣會匹配到這里的test條件
*/
test: /\.(png|jpg|jpeg|gif|eot|ttf|woff|woff2|svg|svgz)(\?.+)?$/,
/*
使用url-loader, 它接受一個limit參數, 單位為字節(byte)
當文件體積小于limit時, url-loader把文件轉為Data URI的格式內聯到引用的地方
當文件大于limit時, url-loader會調用file-loader, 把文件儲存到輸出目錄, 并把引用的文件路徑改寫成輸出后的路徑
比如 views/foo/index.html中
會被編譯成
而
[站外圖片上傳中……(8)]
會被編譯成
[站外圖片上傳中……(9)]
*/
use: [
{
loader: 'url-loader',
options: {
limit: 10000
}
}
]
}
]
},
/*
配置webpack插件
plugin和loader的區別是, loader是在import時根據不同的文件名, 匹配不同的loader對這個文件做處理,
而plugin, 關注的不是文件的格式, 而是在編譯的各個階段, 會觸發不同的事件, 讓你可以干預每個編譯階段.
*/
plugins: [
/*
html-webpack-plugin用來打包入口html文件
entry配置的入口是js文件, webpack以js文件為入口, 遇到import, 用配置的loader加載引入文件
但作為瀏覽器打開的入口html, 是引用入口js的文件, 它在整個編譯過程的外面,
所以, 我們需要html-webpack-plugin來打包作為入口的html文件
*/
new HtmlWebpackPlugin({
/*
template參數指定入口html文件路徑, 插件會把這個文件交給webpack去編譯,
webpack按照正常流程, 找到loaders中test條件匹配的loader來編譯, 那么這里html-loader就是匹配的loader
html-loader編譯后產生的字符串, 會由html-webpack-plugin儲存為html文件到輸出目錄, 默認文件名為index.html
可以通過filename參數指定輸出的文件名
html-webpack-plugin也可以不指定template參數, 它會使用默認的html模板.
*/
template: './src/index.html'
})
],
/*
配置開發時用的服務器, 讓你可以用 http://127.0.0.1:8080/ 這樣的url打開頁面來調試
并且帶有熱更新的功能, 打代碼時保存一下文件, 瀏覽器會自動刷新. 比nginx方便很多
如果是修改css, 甚至不需要刷新頁面, 直接生效. 這讓像彈框這種需要點擊交互后才會出來的東西調試起來方便很多.
*/
devServer: {
// 配置監聽端口, 因為8080很常用, 為了避免和其他程序沖突, 我們配個其他的端口號
port: 8100,
/*
historyApiFallback用來配置頁面的重定向
SPA的入口是一個統一的html文件, 比如
http://localhost:8010/foo
我們要返回給它
http://localhost:8010/index.html
這個文件
配置為true, 當訪問的文件不存在時, 返回根目錄下的index.html文件
*/
historyApiFallback: true
}
}
走一個
配置OK了, 接下來我們就運行一下吧. 我們先試一下開發環境用的webpack-dev-server:
./node_modules/.bin/webpack-dev-server -d --hot
上面的命令適用于Mac/Linux等*nix系統, 也適用于Windows上的PowerShell和bash/zsh環境(Bash on Wbuntu on Windows, Git Bash, Babun, MSYS2等).
如果使用Windows的cmd.exe, 請執行:
node_modules\.bin\webpack-dev-server -d --hot
我在這里安利Windows同學使用Bash on Ubuntu on Windows, 可以避免很多跨平臺的問題, 比如設置環境變量.
npm會把包的可執行文件安裝到./node_modules/.bin/目錄下, 所以我們要在這個目錄下執行命令.
-d參數是開發環境(Development)的意思, 它會在我們的配置文件中插入調試相關的選項, 比如打開debug, 打開sourceMap, 代碼中插入源文件路徑注釋.
--hot開啟熱更新功能, 參數會幫我們往配置里添加HotModuleReplacementPlugin插件, 雖然可以在配置里自己寫, 但有點麻煩, 用命令行參數方便很多.
命令執行后, 控制臺的最后一行應該是
webpack: bundle is now VALID.
這就代表編譯成功了, 我們可以在瀏覽器打開 http://localhost:8100/foo 看看效果. 如果有報錯, 那可能是什么地方沒弄對? 請自己仔細檢查一下~
我們可以隨意更改一下src目錄下的源代碼, 保存后, 瀏覽器里的頁面應該很快會有相應變化.
要退出編譯, 按ctrl+c.
開發環境編譯試過之后, 我們試試看編譯生產環境的代碼, 命令是:
./node_modules/.bin/webpack -p
-p參數會開啟生產環境模式, 這個模式下webpack會將代碼做壓縮等優化.
大家可能會發現, 執行腳本的命令有點麻煩. 因此, 我們可以利用npm的特性, 把命令寫在package.json中:
{
"scripts": {
"dev": "webpack-dev-server -d --hot --env.dev",
"build": "webpack -p"
}
}
package.json中的scripts對象, 可以用來寫一些腳本命令, 命令不需要前綴目錄./node_modules/.bin/, npm會自動尋找該目錄下的命令. 我們可以執行:
npm run dev
來啟動開發環境.
執行
npm run build
來打包生產環境的代碼.
進階配置
上面的項目雖然可以跑起來了, 但有幾個點我們還沒有考慮到:
- 指定靜態資源的url路徑前綴
- 各個頁面分開打包
- 打包時區分開發環境和生產環境
- 輸出的entry文件加上hash
- 第三方庫和業務代碼分開打包
- 開發環境關閉performance.hints
- 配置favicon
- 開發環境允許其他電腦訪問
- 打包時自定義部分參數
- webpack-dev-server處理帶后綴名的文件的特殊規則
- 代碼中插入環境變量
- 簡化import路徑
- 優化babel編譯后的代碼性能
- 使用webpack 2自帶的ES6模塊處理功能
- 使用autoprefixer自動創建css的vendor prefixes
- 編譯前清空dist目錄
那么, 讓我們在上面的配置的基礎上繼續完善, 下面的代碼我們只寫出改變的部分. 代碼在examples/advanced目錄.
指定靜態資源的url路徑前綴
現在我們的資源文件的url直接在根目錄, 比如http://127.0.0.1:8100/index.js, 這樣做緩存控制和CDN都不方便, 我們需要給資源文件的url加一個前綴, 比如 http://127.0.0.1:8100/assets/index.js這樣. 我們來修改一下webpack配置:
{
output: {
publicPath: '/assets/'
},
devServer: {
// 指定index.html文件的url路徑
historyApiFallback: {
index: '/assets/'
}
}
}
各個頁面分開打包
這樣瀏覽器只需加載當前訪問的頁面的代碼.
webpack可以使用異步加載文件的方式引用模塊, webpack 1的API是require.ensure(), webpack 2開始支持TC39的dynamic import. 我們這里就使用新的import()來實現頁面分開打包異步加載. 話不多說, 上代碼.
src/index.js:
load(path) {
import('./views' + path + '/index.js').then(module => {
// export default ... 的內容通過module.default訪問
const View = module.default
const view = new View()
view.mount(document.body)
})
}
這樣我們就不需要在開頭把所有頁面文件都import進來了.
因為import()還沒有正式進入標準, 因此babel和eslint需要插件來支持它:
npm install babel-eslint babel-preset-stage-2 --save-dev
package.json改一下:
{
"babel": {
"presets": [
"env",
"stage-2"
]
},
"eslintConfig": {
"parser": "babel-eslint",
"extends": "enough",
"env": {
"browser": true,
"node": true
}
}
}
然后修改webpack配置:
{
output: {
/*
import()加載的文件會被分開打包, 我們稱這個包為chunk, chunkFilename用來配置這個chunk輸出的文件名.
[id]: 編譯時每個chunk會有一個id.
[chunkhash]: 這個chunk的hash值, 文件發生變化時該值也會變. 文件名加上該值可以防止瀏覽器讀取舊的緩存文件.
*/
chunkFilename: '[id].js?[chunkhash]',
}
}
打包時區分開發環境和生產環境
如果webpack.config.js導出的是一個function, 那么webpack會執行它, 并把返回的結果作為配置對象.
module.exports = (options = {}) => {
return {
// 配置內容
}
}
該function接受一個參數, 這個參數的值是由命令行傳入的. 比如當我們在命令行中執行:
webpack --env.dev --env.server localhost
那么options值為 { dev: true, server: 'localhost' }
該參數對 webpack-dev-server 命令同樣有效.
我們修改一下package.json, 給dev腳本加上env.dev:
{
"scripts": {
"dev": "webpack-dev-server -d --hot --env.dev",
}
}
輸出的entry文件加上hash
上面我們提到了chunkFilename可以加上[chunkhash]防止瀏覽器讀取錯誤緩存, 那么entry同樣需要加上hash. 但使用webpack-dev-server啟動開發環境時, entry文件是沒有[chunkhash]的, 用了會報錯. 因此我們需要利用上面提到的區分開發環境和生產環境的功能, 只在打包生產環境代碼時加上[chunkhash]
module.exports = (options = {}) => {
return {
/*
這里entry我們改用對象來定義
屬性名在下面的output.filename中使用, 值為文件路徑
*/
entry: {
index: './src/index',
},
output: {
/*
entry字段配置的入口js的打包輸出文件名
[name]作為占位符, 在輸出時會被替換為entry里定義的屬性名, 比如這里會被替換為"index"
[chunkhash]是打包后輸出文件的hash值的占位符, 把?[chunkhash]跟在文件名后面可以防止瀏覽器使用緩存的過期內容,
這里, webpack會生成以下代碼插入到index.html中:
<script type="text/javascript" src="/assets/index.js?d835352892e6aac768bf"></script>
這里/assets/目錄前綴是output.publicPath配置的
options.dev是命令行傳入的參數. 這里是由于使用webpack-dev-server啟動開發環境時, 是沒有[chunkhash]的, 用了會報錯
因此我們不得已在使用webpack-dev-server啟動項目時, 命令行跟上--env.dev參數, 當有該參數時, 不在后面跟[chunkhash]
*/
filename: options.dev ? '[name].js' : '[name].js?[chunkhash]',
}
}
}
有人可能注意到官網文檔中還有一個[hash]占位符, 這個hash是整個編譯過程產生的一個總的hash值, 而不是單個文件的hash值, 項目中任何一個文件的改動, 都會造成這個hash值的改變. [hash]占位符是始終存在的, 但我們不希望修改一個文件導致所有輸出的文件hash都改變, 這樣就無法利用瀏覽器緩存了. 因此這個[hash]意義不大.
第三方庫和業務代碼分開打包
這樣更新業務代碼時可以借助瀏覽器緩存, 用戶不需要重新下載沒有發生變化的第三方庫.
我們的思路是, 入口的html文件引兩個js, vendor.js和index.js. vendor.js用來引用第三方庫, 比如這兒我們引入一個第三方庫來做路由, 我們先安裝它:
npm install spa-history --save
然后在vendor.js中, 我們引用一下它:
import 'spa-history/PathHistory'
我們import它但不需要做什么, 這樣webpack打包的時候會把這個第三方庫打包進vendor.js.
然后在src/index.js中, 我們使用它:
import PathHistory from 'spa-history/PathHistory'
const history = new PathHistory({
change(location) {
// 使用import()將加載的js文件分開打包, 這樣實現了僅加載訪問的頁面
import('./views' + location.path + '/index.js').then(module => {
// export default ... 的內容通過module.default訪問
const View = module.default
const view = new View()
view.mount(document.body)
})
}
})
history.hookAnchorElements()
history.start()
頁面foo和bar的js和html文件因為路由的改變也要做些微調.
src/views/foo/index.js:
import template from './index.html'
import './style.css'
export default class {
mount(container) {
document.title = 'foo'
container.innerHTML = template
}
}
src/views/foo/index.html:
<div class="foo">
<h1>Page Foo</h1>
<a href="/bar">goto bar</a>
<p>
</p>
<p>
[站外圖片上傳中……(11)]
</p>
</div>
src/views/bar/index.js:
import template from './index.html'
import './style.css'
export default class {
mount(container) {
document.title = 'bar'
container.innerHTML = template
}
}
src/views/bar/index.html:
<div class="bar">
<h1>Page Bar</h1>
<a href="/foo">goto foo</a>
</div>
然后最重要的webpack的配置需要修改一下:
// 引入webpack, 等會需要用
const webpack = require('webpack')
module.exports = (options = {}) => {
return {
// entry中加入vendor
entry: {
vendor: './src/vendor',
index: './src/index'
},
plugins: [
/*
使用CommonsChunkPlugin插件來處理重復代碼
因為vendor.js和index.js都引用了spa-history, 如果不處理的話, 兩個文件里都會有spa-history包的代碼,
我們用CommonsChunkPlugin插件來使共同引用的文件只打包進vendor.js
*/
new webpack.optimize.CommonsChunkPlugin({
/*
names: 將entry文件中引用的相同文件打包進指定的文件, 可以是新建文件, 也可以是entry中已存在的文件
這里我們指定打包進vendor.js
但這樣還不夠, 還記得那個chunkFilename參數嗎? 這個參數指定了chunk的打包輸出的名字,
我們設置為 [id].js?[chunkhash] 的格式. 那么打包時這個文件名存在哪里的呢?
它就存在引用它的文件中. 這就意味著被引用的文件發生改變, 會導致引用的它文件也發生改變.
然后CommonsChunkPlugin有個附加效果, 會把所有chunk的文件名記錄到names指定的文件中.
那么這時當我們修改頁面foo或者bar時, vendor.js也會跟著改變, 而index.js不會變.
那么怎么處理這些chunk, 使得修改頁面代碼而不會導致entry文件改變呢?
這里我們用了一點小技巧. names參數可以是一個數組, 意思相當于調用多次CommonsChunkPlugin,
比如:
plugins: [
new webpack.optimize.CommonsChunkPlugin({
names: ['vendor', 'manifest']
})
]
相當于
plugins: [
new webpack.optimize.CommonsChunkPlugin({
names: 'vendor'
}),
new webpack.optimize.CommonsChunkPlugin({
names: 'manifest'
})
]
首先把重復引用的庫打包進vendor.js, 這時候我們的代碼里已經沒有重復引用了, chunk文件名存在vendor.js中,
然后我們在執行一次CommonsChunkPlugin, 把所有chunk的文件名打包到manifest.js中.
這樣我們就實現了chunk文件名和代碼的分離. 這樣修改一個js文件不會導致其他js文件在打包時發生改變, 只有manifest.js會改變.
*/
names: ['vendor', 'manifest']
})
]
}
}
開發環境關閉performance.hints
我們注意到運行開發環境是命令行會報一段warning:
WARNING in asset size limit: The following asset(s) exceed the recommended size limit (250 kB).
This can impact web performance.
...
這是說建議每個輸出的js文件的大小不要超過250k. 但開發環境因為包含了sourcemap并且代碼未壓縮所以一般都會超過這個大小, 所以我們可以在開發環境把這個warning關閉.
webpack配置中加入:
{
performance: {
hints: options.dev ? false : 'warning'
}
}
配置favicon
在src目錄中放一張favicon.png, 然后src/index.html的<head>中插入:
<link rel="icon" type="image/png" href="favicon.png">
修改webpack配置:
{
module: {
rules: [
{
test: /\.html$/,
use: [
{
loader: 'html-loader',
options: {
/*
html-loader接受attrs參數, 表示什么標簽的什么屬性需要調用webpack的loader進行打包.
比如<img>標簽的src屬性, webpack會把<img>引用的圖片打包, 然后src的屬性值替換為打包后的路徑.
使用什么loader代碼, 同樣是在module.rules定義中使用匹配的規則.
如果html-loader不指定attrs參數, 默認值是img:src, 意味著會默認打包<img>標簽的圖片.
這里我們加上<link>標簽的href屬性, 用來打包入口index.html引入的favicon.png文件.
*/
attrs: ['img:src', 'link:href']
}
}
]
},
{
/*
匹配favicon.png
上面的html-loader會把入口index.html引用的favicon.png圖標文件解析出來進行打包
打包規則就按照這里指定的loader執行
*/
test: /favicon\.png$/,
use: [
{
// 使用file-loader
loader: 'file-loader',
options: {
/*
name: 指定文件輸出名
[name]是源文件名, 不包含后綴. [ext]為后綴. [hash]為源文件的hash值,
這里我們保持文件名, 在后面跟上hash, 防止瀏覽器讀取過期的緩存文件.
*/
name: '[name].[ext]?[hash]'
}
}
]
},
// 圖片文件的加載配置增加一個exclude參數
{
test: /\.(png|jpg|jpeg|gif|eot|ttf|woff|woff2|svg|svgz)(\?.+)?$/,
// 排除favicon.png, 因為它已經由上面的loader處理了. 如果不排除掉, 它會被這個loader再處理一遍
exclude: /favicon\.png$/,
use: [
{
loader: 'url-loader',
options: {
limit: 10000
}
}
]
}
]
}
}
其實html-webpack-plugin接受一個favicon參數, 可以指定favicon文件路徑, 會自動打包插入到html文件中. 但它有個bug, 打包后的文件名路徑不帶hash, 就算有hash, 它也是[hash], 而不是[chunkhash], 導致修改代碼也會改變favicon打包輸出的文件名. issue中提到的favicons-webpack-plugin倒是可以用, 但它依賴PhantomJS, 非常大.
開發環境允許其他電腦訪問
webpack配置devServer.host為'0.0.0.0'即可.
打包時自定義部分參數
在多人開發時, 每個人可能需要有自己的配置, 比如說webpack-dev-server監聽的端口號, 如果寫死在webpack配置里, 而那個端口號在某個同學的電腦上被其他進程占用了, 簡單粗暴的修改webpack.config.js會導致提交代碼后其他同學的端口也被改掉.
還有一點就是開發環境/測試環境/生產環境的部分webpack配置是不同的, 比如publicPath在生產環境可能要配置一個CDN地址.
我們在根目錄建立一個文件夾config, 里面創建3個配置文件:
-
default.js: 生產環境
module.exports = {
publicPath: 'http://cdn.example.com/assets/'
}
-
dev.js: 默認開發環境
module.exports = {
publicPath: '/assets/',
devServer: {
port: 8100,
proxy: {
'/api/auth/': {
target: 'http://api.example.dev',
changeOrigin: true,
pathRewrite: { '^/api': '' }
},
'/api/pay/': {
target: 'http://pay.example.dev',
changeOrigin: true,
pathRewrite: { '^/api': '' }
}
}
}
}
-
local.js: 個人本地環境, 在dev.js基礎上修改部分參數.
const config = require('./dev')
config.devServer.port = 8200
module.exports = config
package.json修改scripts:
{
"scripts": {
"local": "npm run dev --config=local",
"dev": "webpack-dev-server -d --hot --env.dev --env.config dev",
"build": "rimraf dist && webpack -p"
}
}
webpack配置修改:
// ...
const url = require('url')
module.exports = (options = {}) => {
const config = require('./config/' + (process.env.npm_config_config || options.config || 'default'))
return {
// ...
devServer: config.devServer ? {
host: '0.0.0.0',
port: config.devServer.port,
proxy: config.devServer.proxy,
historyApiFallback: {
index: url.parse(config.publicPath).pathname
}
} : undefined,
}
}
這里的關鍵是npm run傳進來的自定義參數可以通過process.env.npm_config_*獲得. 參數中如果有-會被轉成_
--env.*傳進來的參數可以通過options.*獲得. 我們優先使用npm run指定的配置文件. 這樣我們可以在命令行覆蓋scripts中指定的配置文件:
npm run dev --config=CONFIG_NAME
local命令就是這樣做的.
這樣, 當我們執行npm run dev時使用的是dev.js, 執行npm run local使用local.js, 執行npm run build使用default.js.
config.devServer.proxy用來配置后端api的反向代理, ajax /api/auth/*的請求會被轉發到 http://api.example.dev/auth/*, /api/pay/*的請求會被轉發到 http://api.example.dev/pay/*.
changeOrigin會修改HTTP請求頭中的Host為target的域名, 這里會被改為api.example.dev
pathRewrite用來改寫URL, 這里我們把/api前綴去掉.
還有一點, 我們不需要把自己個人用的配置文件提交到git, 所以我們在.gitignore中加入:
config/*
!config/default.js
!config/dev.js
把config目錄排除掉, 但是保留生產環境和dev默認配置文件.
webpack-dev-server處理帶后綴名的文件的特殊規則
當處理帶后綴名的請求時, 比如 http://localhost:8100/bar.do , webpack-dev-server會認為它應該是一個實際存在的文件, 就算找不到該文件, 也不會fallback到index.html, 而是返回404. 但在SPA應用中這不是我們希望的. 幸好webpack-dev-server有一個配置選項disableDotRule: true可以禁用這個規則, 使帶后綴的文件當不存在時也能fallback到index.html
historyApiFallback: {
index: url.parse(config.publicPath).pathname,
disableDotRule: true
}
代碼中插入環境變量
在業務代碼中, 有些變量在開發環境和生產環境是不同的, 比如域名, 后臺API地址等. 還有開發環境可能需要打印調試信息等.
我們可以使用DefinePlugin插件在打包時往代碼中插入需要的環境變量,
// ...
const pkgInfo = require('./package.json')
module.exports = (options = {}) => {
const config = require('./config/' + (process.env.npm_config_config || options.config || 'default')).default
return {
// ...
plugins: [
new webpack.DefinePlugin({
DEBUG: Boolean(options.dev),
VERSION: JSON.stringify(pkgInfo.version),
CONFIG: JSON.stringify(config.runtimeConfig)
})
]
}
}
DefinePlugin插件的原理很簡單, 如果我們在代碼中寫:
console.log(DEBUG)
它會做類似這樣的處理:
'console.log(DEBUG)'.replace('DEBUG', true)
最后生成:
console.log(true)
這里有一點需要注意, 像這里的VERSION, 如果我們不對pkgInfo.version做JSON.stringify(),
console.log(VERSION)
然后做替換操作:
'console.log(VERSION)'.replace('VERSION', '1.0.0')
最后生成:
console.log(1.0.0)
這樣語法就錯誤了. 所以, 我們需要JSON.stringify(pkgInfo.version)轉一下變成'"1.0.0"', 替換的時候才會帶引號.
還有一點, webpack打包壓縮的時候, 會把代碼進行優化, 比如:
if (DEBUG) {
console.log('debug mode')
} else {
console.log('production mode')
}
會被編譯成:
if (false) {
console.log('debug mode')
} else {
console.log('production mode')
}
然后壓縮優化為:
console.log('production mode')
簡化import路徑
文件a引入文件b時, b的路徑是相對于a文件所在目錄的. 如果a和b在不同的目錄, 藏得又深, 寫起來就會很麻煩:
import b from '../../../components/b'
為了方便, 我們可以定義一個路徑別名(alias):
resolve: {
alias: {
'~': resolve(__dirname, 'src')
}
}
這樣, 我們可以以src目錄為基礎路徑來import文件:
import b from '~/components/b'
html中的<img>標簽沒法使用這個別名功能, 但html-loader有一個root參數, 可以使/開頭的文件相對于root目錄解析.
{
test: /\.html$/,
use: [
{
loader: 'html-loader',
options: {
root: resolve(__dirname, 'src'),
attrs: ['img:src', 'link:href']
}
}
]
}
那么, [站外圖片上傳中……(12)]就能順利指向到src目錄下的favicon.png文件, 不需要關心當前文件和目標文件的相對路徑.
PS: 在調試<img>標簽的時候遇到一個坑, html-loader會解析``注釋中的內容, 之前在注釋中寫的
<!--
大于10kb的圖片, 圖片會被儲存到輸出目錄, src會被替換為打包后的路徑
[站外圖片上傳中……(13)]
-->
之前因為沒有加root參數, 所以/開頭的文件名不會被解析, 加了root導致編譯時報錯, 找不到該文件. 大家記住這一點.
優化babel編譯后的代碼性能
babel編譯后的代碼一般會造成性能損失, babel提供了一個loose選項, 使編譯后的代碼不需要完全遵循ES6規定, 簡化編譯后的代碼, 提高代碼執行效率:
package.json:
{
"babel": {
"presets": [
[
"env",
{
"loose": true
}
],
"stage-2"
]
}
}
但這么做會有兼容性的風險, 可能會導致ES6源碼理應的執行結果和編譯后的ES5代碼的實際結果并不一致. 如果代碼沒有遇到實際的效率瓶頸, 官方不建議使用loose模式.
使用webpack 2自帶的ES6模塊處理功能
我們目前的配置, babel會把ES6模塊定義轉為CommonJS定義, 但webpack自己可以處理import和export, 而且webpack處理import時會做代碼優化, 把沒用到的部分代碼刪除掉. 因此我們通過babel提供的modules: false選項把ES6模塊轉為CommonJS模塊的功能給關閉掉.
package.json:
{
"babel": {
"presets": [
[
"env",
{
"loose": true,
"modules": false
}
],
"stage-2"
]
}
}
使用autoprefixer自動創建css的vendor prefixes
css有一個很麻煩的問題就是比較新的css屬性在各個瀏覽器里是要加前綴的, 我們可以使用autoprefixer工具自動創建這些瀏覽器規則, 那么我們的css中只需要寫:
:fullscreen a {
display: flex
}
autoprefixer會編譯成:
:-webkit-full-screen a {
display: -webkit-box;
display: flex
}
:-moz-full-screen a {
display: flex
}
:-ms-fullscreen a {
display: -ms-flexbox;
display: flex
}
:fullscreen a {
display: -webkit-box;
display: -ms-flexbox;
display: flex
}
首先, 我們用npm安裝它:
npm install postcss-loader autoprefixer --save-dev
autoprefixer是postcss的一個插件, 所以我們也要安裝postcss的webpack loader.
修改一下webpack的css rule:
{
test: /\.css$/,
use: ['style-loader', 'css-loader', 'postcss-loader']
}
然后創建文件postcss.config.js:
module.exports = {
plugins: [
require('autoprefixer')()
]
}
編譯前清空dist目錄
不清空的話上次編譯生成的文件會遺留在dist目錄中, 我們最好先把目錄清空一下. macOS/Linux下可以用rm -rf dist搞定, 考慮到跨平臺的需求, 我們可以用rimraf:
npm install rimraf --save-dev
package.json修改一下:
{
"scripts": {
"build": "rimraf dist && webpack -p --env.config production"
},
}
傳統的多頁面網站(MPA)能否用webpack打包?
對于多頁面網站, 我們最多的是用Grunt或Gulp來打包, 因為這種簡單的頁面對模塊化編程的需求不高. 但如果你喜歡上使用import來引入庫, 那么我們仍然可以使用webpack來打包.
MPA意味著并沒不是一個單一的html入口和js入口, 而是每個頁面對應一個html和多個js. 那么我們可以把項目結構設計為:
├── dist
├── package.json
├── node_modules
├── src
│ ├── components
│ ├── libs
| ├── favicon.png
| ├── vendor.js 所有頁面公用的第三方庫
│ └── pages 頁面放這里
| ├── foo 編譯后生成 http://localhost:8100/foo.html
| | ├── index.html
| | ├── index.js
| | ├── style.css
| | └── pic.png
| └── bar http://localhost:8100/bar.html
| ├── index.html
| ├── index.js
| ├── style.css
| └── baz http://localhost:8100/bar/baz.html
| ├── index.html
| ├── index.js
| └── style.css
└── webpack.config.js
這里每個頁面的index.html是個完整的從<!DOCTYPE html>開頭到</html>結束的頁面, 這些文件都要用html-webpack-plugin處理. index.js是每個頁面的業務邏輯, 全部作為入口js配置到entry中. 頁面公用的第三方庫仍然打包進vendor.js. 這里我們需要用glob庫來把這些文件都篩選出來批量操作.
npm install glob --save-dev
webpack.config.js修改的地方:
// ...
const glob = require('glob')
module.exports = (options = {}) => {
// ...
const entries = glob.sync('./src/**/index.js')
const entryJsList = {}
const entryHtmlList = []
for (const path of entries) {
const chunkName = path.slice('./src/pages/'.length, -'/index.js'.length)
entryJsList[chunkName] = path
entryHtmlList.push(new HtmlWebpackPlugin({
template: path.replace('index.js', 'index.html'),
filename: chunkName + '.html',
chunks: ['manifest', 'vendor', chunkName]
}))
}
return {
entry: Object.assign({
vendor: './src/vendor'
}, entryJsList),
// ...
plugins: [
...entryHtmlList,
// ...
]
}
}
代碼在examples/mpa目錄.
其他問題
為什么不使用webpack.config.babel.js
部分同學可能知道webpack可以讀取webpack.config.babel.js, 它會先調用babel將文件編譯后再執行. 但這里有兩個坑:
- 由于我們的package.json中的babel配置指定了
modules: false, 所以babel并不會轉碼import, 這導致編譯后的webpack配置文件仍然無法在node.js中執行, 解決方案是package.json不指定modules: false, 而在babel-loader中的options中配置babel. 這樣webpack.config.babel.js會使用package.json的babel配置編譯, 而webpack編譯的js會使用babel-loader指定的配置編譯.
{
test: /\.js$/,
exclude: /node_modules/,
use: [
{
loader: 'babel-loader',
options: {
presets: [
['env', {
loose: true,
modules: false
}],
'stage-2'
]
}
},
'eslint-loader'
]
}
- postcss的配置不支持先用babel轉碼, 這導致了我們的配置文件格式的不統一.
綜上, 還是只在src目錄中的文件使用ES6模塊規范會比較方便一點.
總結
通過這篇文章, 我想大家應該學會了webpack的正確打開姿勢. 雖然我沒有提及如何用webpack來編譯React和vue.js, 但大家可以想到, 無非是安裝一些loader和plugin來處理jsx和vue格式的文件, 那時難度就不在于webpack了, 而是代碼架構組織的問題了. 具體的大家自己去摸索一下. 以后有時間我會把腳手架整理一下放到github上, 供大家參考.
幾個腳手架
版權許可
<a rel="license" >[站外圖片上傳中……(14)]</a><br />本作品采用<a rel="license" >知識共享署名-非商業性使用 4.0 國際許可協議</a>進行許可.
