一:前端工程化的發展
很久以前,互聯網行業有個職位叫做 “軟件開發工程師” 在那個時代,大家可能會蒙,放在現今社會,大家會覺得這個職位太過籠統,所以在此提一下那個時候的互聯網行業狀態。
- 那個時候的APP還不是ios/安卓 多數是嵌入式應用(和網頁沒關係 使用c++或java開發)後續到了Symbian時代出現了可移植的sis[x]類型應用,曾經一統移動APP市場。
- 那個時候css百分之90還是用來做佈局
- 那個時候js僅僅是爲了類似彈出提示的功能而存在的
- 那個時候從服務器 - 數據庫 - 業務邏輯 - 頁面 全都由所謂的 “軟件開發工程師” 來完成
- 所以大家不必問軟件開發工程師具體是幹啥的,我只能說 啥都幹
1:個人對前端開發的體驗過程
第一個階段就是開始對着W3C的文檔,拿着txt文本文件一個字母字母的敲着代碼,那個年代,真的單純舒服,上來就是一個項目的文件夾,然後就開始img、js、css三個完美的文件夾,再接上一個index.html,就開始到網上各種下載類庫jquery、underscore.js,然後手動的引入各種類庫,當然過程也伴隨着痛苦。
- 每次來一個項目就開始建立各種繁瑣的文件夾,和拷貝複製類庫
- 引入完類庫的時候發現控制檯報錯,$ is not defined,依賴關係出錯,部分類庫需要把jquery作爲依賴
- 新寫一個頁面就需要去重新複製其他頁面的header資源,維護變的困難(完全沒有組件化的想法)
- 部分css3屬性需要自己不斷的手動添加樣式前綴
- 最大的問題再維護的時候,不敢輕易的去動一些類庫的引入,不清楚各個庫之前的依賴關係
第二個階段就是在接觸到Vue的時候直接上vue-cli的時候,幾行腳本就可以啓動本地開發服務和打包線上資源,初次嘗試了webpack這個打包工具,好像對其他問題不需要做過多的考慮,直接開始業務開發,其他的事情cli都幫助處理好了。vue init webpack helloWorld, cd helloWorld && cnpm install && npm run dev,真香警告,對工程化一知半解,但是好用,方便
- 前端需要一些工具來處理重複的大量繁瑣的事 (資源壓縮 代碼混淆 css前綴 ),以前會用Gulp等Task處理任務
- 前端需要一些需要用一些預處理器來處理樣式文件,less以前用第三方工具去編譯 -> less提供的命令行去編譯-> 配置到webpack中自動化實時編譯
- 前端需要更加細粒度的配置一下代碼體積的優化,代碼混淆壓縮的操作
- 前端部分業務越多,代碼量越多(文件體積越大)需要做文件合併,壓縮以及按需加載等
- 開發階段依然在本地開發,但同時保持和線上API的同步,爲此我們需要本地服務器(可以是靜態服務器)代理轉發(Nginx webpack-dev-server node-server等方式)
第三個階段就是給公司項目升級webpack過程中體驗到了更細粒度的控制工程,體驗工程化的過程,實際的體驗到了工程化爲我們做的事情
- 模塊化開發,不用在擔心以往開發方式帶來的全局作用域的污染問題,當然以往也可以通過閉包來實現私有變量的概念
- 組件化開發,代碼重用度高,便於維護
- 多了構建,編譯過程,可以在適當的時間去做一些提高工程質量的任務,比如代碼規範的檢測,常用的是Eslint (Airbnb, Prettier 規範等)
- 提高開發效率,比如css瀏覽器前綴的自動添加,使用postCss甚至可以提前使用一些好用的東西,比如css變量的概念
- 通過chunkHash,contentHash 等實現資源的緩存
- 根據工程代碼通過合理的代碼分割提升用戶體驗,做到按需加載,甚至可以在未來做一些用戶使用的習慣,做一些提前的預加載
二:webpack的基本使用
1:webpack和Grunt / Gulp的區別
這兩類是不同的東西,一個可以理解爲是任務執行器而另外一個是模塊打包器,任務執行器是可以自動化的執行一些以前你需要手動操作的過程,見下面簡單的代碼
// coffee 源碼
console.log 'Hello World'
//coffee轉 js coffee -c a.coffee
(function(){
console.log('Hello World');
}).call(this);
//執行編譯壓縮 uglify -s a.js -o a.min.js
(function(){console.log("Hello World")}).call(this);
coffee需要編譯成瀏覽器支持的js,你需要手動的去執行上面的幾個命令,如果現在需要去修改源碼,在Hello World 後面加上一個!,加完你需要手動的去執行兩條命令重複的去編譯操作。以 gulp 爲例,編寫 gulpfile.js來幫助我們完成重複的工作
gulp = require('gulp')
coffee = require('gulp-coffee')
uglify = require('gulp-uglify')
rename = require('gulp-rename')
file = './src/js/a.coffee'
gulp.task('coffee', function(){
gulp.src(file)
.pipe(coffee()) // 編譯
.pipe(uglify()) // 壓縮
.pipe(rename({
extname: ".min.js"
}))
.pipe(gulp.dest('./build/js'))
gulp.task('watch', function(){
gulp.watch(file, ['coffee'])
})
gulp.task('default', ['coffee'])
我只要執行一下 gulp watch 就可以檢測到coffee文件的變化,然後爲你執行一系列的自動化操作,同樣的操作也發生在less, scss, 這些css的預處理器上。在修改到源文件的情況下的編譯,壓縮這些重複操作都交由它來完成,在我看來Grunt / Gulp 算是一個能夠自動化執行一些繁瑣重複的操作,提高生產效率,算是一個任務執行器。
這些操作同樣也可以由webpack完成,接下來我們看一下官網給出的webpack的定義。
webpack is a module bundler
官方給出的解釋是,webpack是一個模塊打包器,不是一個任務執行器,它是可以配合Grunt / Gulp 使用的,相關鏈接webpack集成 。webpack打包器(bundler)幫助你生成準備用於部署的 JavaScript 和樣式表,將它們轉換爲適合瀏覽器的可用格式。例如,JavaScript的壓縮、chunk split和懶加載,以提高性能。所以webpack和Gulp/Grunt之間是有一定功能的重疊,但是處理合適,是可以一起配合工作的,不存在所謂的誰替代誰,只是在某些場景下webpack的能夠獨當一面,完成了Grunt/ Gulp的功能。
2:webpack3.x 和 webpack4.x 的對比
rollup以及Parcel的出現,號稱零配置,足以讓一個配置成本比較高的webpack出現了4.0版本,當然也號稱零配置使用,開箱即用,現在來一起看看webpack4.x和3.x比較大的區別,先給出一個Release鏈接webpack Release v4.0.0下面簡要的介紹一些大的改動
- Node環境的升級,不在支持node 4.0的版本,最低支持6.11.5
- 配置增加了mode:'production', 'development', 'none' ,所謂的開箱即用的支持點,在不同的mode下開啓了一些默認的優化手段
- 生產模式開啓了各種優化去生成bundle文件、默認開啓作用域提升、process.env.NODE_ENV設置爲production
- 開發模式優化內部rebuild流程,提升開發效率和體驗
- 刪除了和添加了一些配置項,NoEmitOnErrorsPlugin、ModuleConcatenationPlugin(default in production mode)、NamedModulesPlugin(default in development mode) ---> 轉到optimization.*的配置項
- 原生支持處理JSON文件格式,不需要json-loader
- 內置的插件 uglifyjs-webpack-plugin 升級到了 V1, 而V1是可以支持並行處理壓縮混淆JS的,webpack3之前的內置依賴的版本0.4.6 不支持並行處理。常用手段使用webpack-uglify-parallel插件並行處理,利用多核CPU的優勢,升級到webapck4可以不需要了,使用默認也可以
- 一個算是比較大的改動,webpack3.x的ComoonsChunkPlugin廢棄,代替的是optimization.splitChunks 和 optimization.runtimeChunk (會在下文着重介紹)
3:webpack4.x 的一些基本概念
首先先看下圖整體瞭解一下webpack的一些常用配置項
接下來簡單的瞭解一下webpack的一些基本概念
- mode:三種模式,production、development、none。設置mode,webpack會根據mode做相應的優化
- entry:入口,webpack會從入口遞歸尋找所有的依賴,形成依賴關係圖(dependency graph)。目前應用主要分爲單入口和多入口,直觀上表現爲經過webpack處理之後是一個JS文件還是多個JS文件(在沒有代碼分割以及懶加載的前提下)
- output:輸出,主要通過filename來定義生成chunk的命名,可以通過標識符[name]、[contenthash]、[chunkhash]來實現資源的緩存,chunkFileName針對async chunk
- loader:loader用於對模塊的源代碼進行轉換。既然是模塊打包器,那麼就會出現依賴各種各樣的文件和內容,圖片,字體,它們需要經過編譯才能被瀏覽器識別(less、sass,、stylus、ES2015、ts等module) ,都需要通過對應的loader轉換成現代瀏覽器支持的東西。loader支持鏈式傳遞,loader運行在Node.js中,並且能夠執行任何可能的操作,比如存在一些不是用來轉換文件的loader,thread-loder(多個node進程處理loader轉碼文件,提高編譯速度)
- plugin:插件和loader不同的地方在於,loader是針對模塊,比如import以及require的module文件進行轉碼。plugin是在webapck的complier整個生命週期中起作用,在這個編譯階段你可以在提供的hook中執行你需要的任何操作。比如htmlWebpackPligun插件,可以在webpack編譯emit文件的鉤子中,生成html去使用這些webpack生成的JS Chunk
- module:module的概念可以理解爲一個個需要加載的文件,Js也好,Css文件也好,都需要經過loader處理,module裏面的rules去就是配置module需要什麼loader去處理
- chunks:兩種,init chunks(這些chunks文件是會以script標籤添加到htmlWebpackPlugin生成的html文件中,當然也可以通過插件內置到html文件中,比如mainifest文件)和async chunks。初始化chunks是從提供給webapck的entries中開始遞歸的尋找依賴的module,生成的一個chunks。異步的chunks可以理解爲是需要按需加載的,主要可以分爲以下3個來源:第一、從初始化的chunk中抽出去的代碼,形成的chunk文件(這個就是webapck的splitChunk和runtimeChunk的配置)。第二、可以通過webpack識別的特定語法require.ensure (vue-router中懶加載的寫法)。第三、ES6的動態導入import(/chunkname/)
- optimization:這是webpack4.x出現的一個優化類的配置項,常用配置項:splitChunk、runtimeChunk(下文介紹)、minimize、noEmitOnErrors、namedModules、sideEffects(配合tree shaking使用)等等
-
resolve:如上圖,這個配置會增量的告知webpack如何的去尋找依賴,alias(避免一些深層次引用module代碼的別名)、modules(從哪些目錄尋找依賴)、extensions(module的擴展名)、mainFields(第三方類庫存在多個版本的時候,優先使用哪個版本)。alias可以手動指定第三方庫的使用,比如當Vue沒有用CDN的時候,如果從node_modules引用,引入的代碼是runtime運行時的代碼,是沒有包含解析單文件.vue的template部分的功能,這個時候需要依賴它的其他版本,手動指定,常見於用Vue-cli去生成項目架構的時候,發現alias默認有一項,告知webpack引入Vue的時候module的位置是vue/dist/vue.esm.js(包含了解析template的代碼)。mainFields的使用是針對第三方類庫使用各種模塊化寫法以及語法。有ES6的mport、export的,也有CommonJs的模塊導出。有壓縮的min.js也有Ts版本的,這些會在package.json中看到,至於引入第三方模塊的引入那個版本,對於一些成熟的類庫比如Vue,Vue-router等有多個版本,可以通過設置mainFields告知webpack從package.json中的那個字段導入類庫。ES6的improt、export存在靜態分析,配合tree shaking使用,這也是webpack號稱能提速98%的原因,但是目前的狀況是第三方庫參差不齊,很多都沒有提供ES6模塊導出的版本,所有目前效果還不是很理想 - externals:指定外部擴展。從bundle中排除依賴,比如項目一些基本不會變更版本的第三方類庫,通過引用CDN資源,常見Vue、VueRouter、element-ui、echart等等類庫
- devServer:開發模式的配置。在webpack4.x之前的版本通過node的express框架搭建的本地服務器,配合webpack-dev-middleware和webpack-hot-middleware搭建的開發環境。現在可以通過webapck-dev-server類庫結合devServer配置項去開啓本地開發環境,這個類庫封裝了express的操作,同時內部使用了webpack-dev-middleware。給出配置鏈接:devServer配置項
三:項目webpack升級流程
先簡短的介紹一下項目,升級的項目爲多入口項目,每個module模塊代碼一個入口,然後共用很多業務組件
*/build
webpack.base.conf.js // dev和prod共用部分
webpack.dev.conf.js // dev模式下特有配置
webapck.prod.conf.js // prod模式下特有配置
*/common
components // 多個模塊共用的組件
assets // 靜態資源
*/src
module1 // 模塊1的代碼
index.js // 模塊1代碼的入口
module2 // 模塊2的代碼
module3 // 模塊3的代碼
*/mock
mock-xxx.js // mock api的接口
*/config // 配置文件
index.js
dev.js
prod.js
1:package.json依賴的管理
升級webpack,安裝webpack-cli。全局安裝npm-check-updates,查看package.json中可升級的依賴的版本。
cnpm install -g npm-check-updates //全局安裝
// 在項目根目錄下執行ncu
ncu
// 可升級的依賴,列舉部分依賴情況
axios 0.17.1 --> 0.18.0
webpack 3.5.5 --> 4.16.5
webpack-merge 4.1.0 --> 4.1.4
// 升級webpack 安裝webpack-cli
cnpm install webpack webpack-cli --save-dev
// 升級相應的loader和plugin
cnpm install url-loader file-loader vue-loader sass-loader css-loader babel-loader html-webpack-plugin --save-dev
2:修改webpack配置
公司使用的vue-cli2.0的腳手架生成的項目,簡單的列舉關於webpack的目錄,針對需要可進行自行調整
*/build
webpack.base.conf.js // dev和prod共用部分
webpack.dev.conf.js // dev模式下特有配置
webapck.prod.conf.js // prod模式下特有配置
// 通過webpack-merge合併配置輸出最後的webpack配置
1:增加mode模式
// webpack.dev.conf.js 開發模式的配置 開啓webpack默認的配置優化
mode: 'development'
// webpack.prod.conf.js 生產模式的配置
mode: 'production'
2:升級vue-loader,vue-loaderv.15版本和之前的有所區別,vue-loader不在使用自身的配置,而是解析.vue文件之後使用webpack裏配置的loader,詳細文檔見Vue-loader的使用,補充一點:在.vue 文件中style提供的scoped標記,就是通過vue-loader去實現在template中加入了適當的hash,配合樣式去做到組件內樣式的獨立
// webpack.config.js
const VueLoaderPlugin = require('vue-loader/lib/plugin') // 插件解析.vue文件把template script style 分別交給webpack配置的loader去處理
module.exports = {
// ...
plugins: [
new VueLoaderPlugin()
]
}
3:部分webpack的插件已經配置停用。如有的話,按照提示刪除掉,比如module裏的loaders,webpack4不再支持。然後部分插件轉化爲通過optimazation 進行配置,主要配置點在於code split以及mainifest文件的提取,同樣見下文splitChunks和runtimeChunks的分析
4:開發模式加入devServer。項目是否需要通過手動node搭建本地服務器,取決於是否需要node層面去處理其他東西,在公司項目中啓動服務前有兩個操作,編譯scss文件(皮膚文件),以及mock文件夾(mock接口),所以還是保留了手動檔搭建node層面啓動服務,其實完全可以有webpck-dev-server的before,after配置項完成
// 下面代碼塊針對devServer的部分配置項做說明,結合相關知識進行分析
devServer: {
contentBase: path.join(__dirname, '../static'), // 靜態資源提供,不是webpack生成的bundle,生成的bundle在內存中見註釋1
host: host || 'localhost', // 主機名,如果你希望服務器外部可訪問,需要設置爲0.0.0.0,默認localhost
port: process.env.PORT || port, // 端口號
historyApiFallback: true, // handle fallback for HTML5 history API 瞭解一下這個東西見註釋2
proxy: proxyTable, // 後端接口轉發見註釋3
hot: true, // 熱更新見註釋4
quiet: true, // webpack打包信息省略
publicPath: assetsPublicPath, // bundle 的位置 outpath: publicPath 類似
clientLogLevel: "none" // HRM WDS 在瀏覽器控制檯的輸出
}
// 註釋1:寫過express的就知道有一個指定static中間件用來指定資源目錄的
const express = require('express')
const app = express()
app.use(staticPath, express.static(xxx)) // xxx/js/vendor.js,就可以通過localhost:prot/staticPath/js/vendor.js訪問相關靜態資源。所以contentBase就是利用express靜態中間價提供個一種訪問靜態資源文件的能力
// 註釋2:vue-router的history模式充分利用 history.pushState API 來完成 URL 跳轉而無須重新加載頁面 example: history.pushState({a:1}, '測試', '/attendance/index') ,然後內部去處理相應的router對象的展示Vue頁面和邏輯,所以這就是你順着程序點路由可以進去,但是刷新的時候,就顯示404的原因,因爲該路由在服務器上不是真實存在的,而是在index.html中通過JS去解析模擬的,這就需要我們生產模式下生產的dist文件所有的請求都轉發到index.html。處理方式:在服務器上通過nignx 代理,或者起一個express服務,通過第三方類庫 connect-history-api-fallback,當然也可以原生Node去寫,此時Node只是一個文件服務器
const http = require('http')
const fs = require('fs')
const httpPort = 80
http.createServer((req, res) => {
fs.readFile('index.htm', 'utf-8', (err, content) => {
if (err) {
console.log('We cannot open "index.htm" file.')
}
res.writeHead(200, {
'Content-Type': 'text/html; charset=utf-8'
})
res.end(content)
})
}).listen(httpPort, () => {
console.log('Server listening on: http://localhost:%s', httpPort)
})
// 註釋3:請求代理,常常被問起跨域請求有哪些方案,jsonp、CORS(後端配合)、window iframe等方式,還有一個就是通過node代碼轉發請求,服務端請求不存在跨域的概念,webpack中可以node自己使用http-proxy-middleware 去進行代理,本次更新使用的wbepack-dev-server模塊同時也依賴了http-proxy-middleware的庫,目前Node不作爲純後端,而是作爲中間代碼,連接純後端(java php)和前端。
// 註釋4:熱更新,它允許在運行時更新各種模塊,而無需進行完全刷新,目前的公司項目都是純刷新的方式,熱更新HRM,這個是需要你是用的loader或插件幫助你完成,他們能監聽webpck complier期間得鉤子,然後給出相應源碼更新後需要patch,推送到前端,打補丁,然後實現熱更新,而不是刷新整個頁面去重新加載頁面。好處自然提高開發效率,在修改.vue文件的tempalte和style以及script中不是vue生命週期函數時,是能夠保留到當時的vue的各種狀態
5:針對生產模式的優化配置,廢棄生產模式中使用的優化插件,轉爲webpack4的optimization.* 配置
- NoEmitOnErrorsPlugin // 編譯錯誤跳過編譯階段,不生成文件 (default in production)
- ModuleConcatenationPlugin // 作用域提升,加快代碼執行 (default in production)
- NamedModulesPlugin // 默認的module在打包進入chunks的時候都會以module.id 爲標識(這個是隨着依賴遞增的),這會影響到緩存,使用這個插件將會使用文件的路徑作爲標識,詳細見splitChunks and runtimeChunk分析
- CommonsChunkPlugin // 最爲晦澀難懂的webpack插件,作用代碼分割,被splitChunks && runtimeChunks代替
下面爲升級之前的配置
// 依賴module(require, import 導入的文件)來自node_modules且以.js 結尾的文件將會被打包到名爲vendor的bundle中
new webpack.optimize.CommonsChunkPlugin({
name: 'vendor',
minChunks: function (module, count) {
// any required modules inside node_modules are extracted to vendor
return (
module.resource &&
/\.js$/.test(module.resource) &&
module.resource.indexOf(
path.join(__dirname, '../node_modules')
) === 0
)
}
}),
// 在vendor的bundle中把manifest提取出來(mainifest算是webpack實現的在瀏覽器端進行模擬加載模塊和具體加載邏輯的代碼塊,這個最好拆出來,不然沒法做緩存,具體見到長效緩存分析)
new webpack.optimize.CommonsChunkPlugin({
name: 'manifest',
chunks: ['vendor']
})
// 打包之後就會生成一個vendor.js (裏面有着來自node_modules 的第三方類庫)和 mainifest.js (具體加載邏輯)
升級之後,完成原有的配置很簡單,簡單的照着API實現即可,本次升級伴隨着兩個重點,開發模式的rebuild時間,生成環境的打包文件體積和時間,所以還需要做其他優化
- 某些第三方類庫只有某個module才加載,比如只有module1中用mint-ui,這是可以單獨提出來一個chunk或者直接就加載到module1這個入口的init chunk中 ----> 配置層面
- 某些公共組件比如component下公共組件layout在基本每個系統模塊全部都條用了,可以考慮拉出來共用,減少重複代碼量 ----> 配置層面
- 利用ES的語法去動態的引入模塊import('a.js').then(module => {})去懶加載一個模塊,比如只有在某些vue中才會用到的vue-qrcode-component的類庫,這個類庫不應該出現在vendor中(來自node_modules) ----> 代碼層面
optimization: {
splitChunks: {
cacheGroups: {
// module只要滿足下面就會從原來的chunks中抽取出來打包到對應的chunks之中
// 這個vendors是在至少同時有兩個initial Chunk中引入的來自node_modules的第三方類庫會被打包到chunks-vendors中
vendors: {
name: 'chunk-vendors',
test: /[\\\/]node_modules[\\\/]/,
priority: -10,
minChunks: 2, // 至少同時有幾個chunk滿足纔會有可能從這些chunks中提取一些代碼到新的chunk中,也就是至少兩個共用纔會提取,不然就直接打包都所在module的init chunk中
chunks: 'initial' // chunk的概念:代碼分割這些操作作用於那些chunk文件,initial是通過提供給webpack入口生成的chunks, async是通過之前提到的import() 路由懶加載形成的chunk, all就是所有的chunk文件
},
// 這個common跟上面的區別在於沒有test檢測module來源,只是只要有兩個chunk共用就是提取出來,很顯然就範圍來講,下面的大於上面,這時候到底這個來自node_modules的module進入哪個chunk,取決於priority(優先級),誰高進入哪個chunk
common: {
name: 'chunk-common',
minChunks: 2,
priority: -12,
chunks: 'initial',
minSize: 0
}
}
},
runtimeChunk: {
name: 'manifest'
}
}
// 比如某些第三方類庫只在某個Vue文件中使用,通過動態引入import('vue-qrcode-component').then() 一個類庫只在一個地方用,完全沒有必要打包到vendor中(因爲vue-qrcode-component 來自node_module)
// import 就是新建一個chunk 這個chunk是沒有名字的,需要通過/* webpackChunkName: "loadsh"*/ 生成這個loadsh的chunk.name
import(/* webpackChunkName: "loadsh"*/ 'loadsh').then(m => {
const _ = m.default
console.log(_.join(['hello', 'world']))
})
總結:一般經過這幾步驟就能完成一個webapck項目的升級,對於自己項目的複雜的地方需要額外的處理,寫着寫着發現篇幅越來越長了,把上文一直出現的splitChunk和runtimeChunk留到下個篇幅着重介紹一下。在公司做升級之前,給的指標不僅僅是升級框架,還需要在dev模式開發的rebuild的速度更快(修改一個地方,rebuild的時間12s左右才能看到效果,痛苦,可以通過lessModule來解決),在prod模式下打包的項目文件體積減小已經打包所需要的時間更短(一次測試環境發佈需要5,6分鐘)。現在vue-cli3.0已經出現了,找時間把vue-cli3.0源碼給大家分析一下,簡單的包裝了一下操作