隨著現(xiàn)代前端開發(fā)的復(fù)雜度和規(guī)模越來越龐大，已經(jīng)不能拋開工程化來獨(dú)立開發(fā)了，如react的jsx代碼必須編譯后才能在瀏覽器中使用；又如sass和less的代碼瀏覽器也是不支持的。 而如果摒棄了這些開發(fā)框架，那么開發(fā)的效率將大幅下降。在眾多前端工程化工具中，webpack脫穎而出成為了當(dāng)今最流行的前端構(gòu)建工具。 然而大多數(shù)的使用者都只是單純的會使用，而并不知道其深層的原理。希望通過以下的面試題總結(jié)可以幫助大家溫故知新、查缺補(bǔ)漏，知其然而又知其所以然。

問題一覽

• webpack與grunt、gulp的不同？
• 與webpack類似的工具還有哪些？談?wù)勀銥槭裁醋罱K選擇（或放棄）使用webpack？
• 有哪些常見的Loader？他們是解決什么問題的？
• 有哪些常見的Plugin？他們是解決什么問題的？
• Loader和Plugin的不同？
• webpack的構(gòu)建流程是什么?從讀取配置到輸出文件這個過程盡量說全
• 是否寫過Loader和Plugin？描述一下編寫loader或plugin的思路？
• webpack的熱更新是如何做到的？說明其原理？
• 如何利用webpack來優(yōu)化前端性能？（提高性能和體驗(yàn)）
• 如何提高webpack的構(gòu)建速度？
• 怎么配置單頁應(yīng)用？怎么配置多頁應(yīng)用？
• npm打包時需要注意哪些？如何利用webpack來更好的構(gòu)建？
• 如何在vue項(xiàng)目中實(shí)現(xiàn)按需加載？

問題解答

1. webpack與grunt、gulp的不同？

三者都是前端構(gòu)建工具，grunt和gulp在早期比較流行，現(xiàn)在webpack相對來說比較主流，不過一些輕量化的任務(wù)還是會用gulp來處理，比如單獨(dú)打包CSS文件等。

grunt和gulp是基于任務(wù)和流（Task、Stream）的。類似jQuery，找到一個（或一類）文件，對其做一系列鏈?zhǔn)讲僮?，更新流上的?shù)據(jù)， 整條鏈?zhǔn)讲僮鳂?gòu)成了一個任務(wù)，多個任務(wù)就構(gòu)成了整個web的構(gòu)建流程。

webpack是基于入口的。webpack會自動地遞歸解析入口所需要加載的所有資源文件，然后用不同的Loader來處理不同的文件，用Plugin來擴(kuò)展webpack功能。

所以總結(jié)一下：

從構(gòu)建思路來說

gulp和grunt需要開發(fā)者將整個前端構(gòu)建過程拆分成多個`Task`，并合理控制所有`Task`的調(diào)用關(guān)系 webpack需要開發(fā)者找到入口，并需要清楚對于不同的資源應(yīng)該使用什么Loader做何種解析和加工

對于知識背景來說

gulp更像后端開發(fā)者的思路，需要對于整個流程了如指掌 webpack更傾向于前端開發(fā)者的思路

2. 與webpack類似的工具還有哪些？談?wù)勀銥槭裁醋罱K選擇（或放棄）使用webpack？

同樣是基于入口的打包工具還有以下幾個主流的：

• webpack
• rollup
• parcel

從應(yīng)用場景上來看：

• ebpack適用于大型復(fù)雜的前端站點(diǎn)構(gòu)建
• rollup適用于基礎(chǔ)庫的打包，如vue、react
• parcel適用于簡單的實(shí)驗(yàn)性項(xiàng)目，他可以滿足低門檻的快速看到效果

由于parcel在打包過程中給出的調(diào)試信息十分有限，所以一旦打包出錯難以調(diào)試，所以不建議復(fù)雜的項(xiàng)目使用parcel

3.有哪些常見的Loader？他們是解決什么問題的？

• file-loader：把文件輸出到一個文件夾中，在代碼中通過相對 URL 去引用輸出的文件
• url-loader：和 file-loader 類似，但是能在文件很小的情況下以 base64 的方式把文件內(nèi)容注入到代碼中去
• source-map-loader：加載額外的 Source Map 文件，以方便斷點(diǎn)調(diào)試
• image-loader：加載并且壓縮圖片文件
• babel-loader：把 ES6 轉(zhuǎn)換成 ES5
• css-loader：加載 CSS，支持模塊化、壓縮、文件導(dǎo)入等特性
• style-loader：把 CSS 代碼注入到 JavaScript 中，通過 DOM 操作去加載 CSS。
• eslint-loader：通過 ESLint 檢查 JavaScript 代碼

4.有哪些常見的Plugin？他們是解決什么問題的？

• define-plugin：定義環(huán)境變量
• commons-chunk-plugin：提取公共代碼
• uglifyjs-webpack-plugin：通過UglifyES壓縮ES6代碼

5.Loader和Plugin的不同？

不同的作用

• Loader直譯為"加載器"。Webpack將一切文件視為模塊，但是webpack原生是只能解析js文件，如果想將其他文件也打包的話，就會用到loader。 所以Loader的作用是讓webpack擁有了加載和解析非JavaScript文件的能力。
• Plugin直譯為"插件"。Plugin可以擴(kuò)展webpack的功能，讓webpack具有更多的靈活性。 在 Webpack 運(yùn)行的生命周期中會廣播出許多事件，Plugin 可以監(jiān)聽這些事件，在合適的時機(jī)通過 Webpack 提供的 API 改變輸出結(jié)果。

不同的用法

• Loader在module.rules中配置，也就是說他作為模塊的解析規(guī)則而存在。 類型為數(shù)組，每一項(xiàng)都是一個Object，里面描述了對于什么類型的文件（test），使用什么加載(loader)和使用的參數(shù)（options）
• Plugin在plugins中單獨(dú)配置。 類型為數(shù)組，每一項(xiàng)是一個plugin的實(shí)例，參數(shù)都通過構(gòu)造函數(shù)傳入。

6.webpack的構(gòu)建流程是什么?從讀取配置到輸出文件這個過程盡量說全

Webpack 的運(yùn)行流程是一個串行的過程，從啟動到結(jié)束會依次執(zhí)行以下流程：

• 初始化參數(shù)：從配置文件和 Shell 語句中讀取與合并參數(shù)，得出最終的參數(shù)；
• 開始編譯：用上一步得到的參數(shù)初始化 Compiler 對象，加載所有配置的插件，執(zhí)行對象的 run 方法開始執(zhí)行編譯；
• 確定入口：根據(jù)配置中的 entry 找出所有的入口文件；
• 編譯模塊：從入口文件出發(fā)，調(diào)用所有配置的 Loader 對模塊進(jìn)行翻譯，再找出該模塊依賴的模塊，再遞歸本步驟直到所有入口依賴的文件都經(jīng)過了本步驟的處理；
• 完成模塊編譯：在經(jīng)過第4步使用 Loader 翻譯完所有模塊后，得到了每個模塊被翻譯后的最終內(nèi)容以及它們之間的依賴關(guān)系；
• 輸出資源：根據(jù)入口和模塊之間的依賴關(guān)系，組裝成一個個包含多個模塊的 Chunk，再把每個 Chunk 轉(zhuǎn)換成一個單獨(dú)的文件加入到輸出列表，這步是可以修改輸出內(nèi)容的最后機(jī)會；
• 輸出完成：在確定好輸出內(nèi)容后，根據(jù)配置確定輸出的路徑和文件名，把文件內(nèi)容寫入到文件系統(tǒng)。

在以上過程中，Webpack 會在特定的時間點(diǎn)廣播出特定的事件，插件在監(jiān)聽到感興趣的事件后會執(zhí)行特定的邏輯，并且插件可以調(diào)用 Webpack 提供的 API 改變 Webpack 的運(yùn)行結(jié)果。

7.是否寫過Loader和Plugin？描述一下編寫loader或plugin的思路？

Loader像一個"翻譯官"把讀到的源文件內(nèi)容轉(zhuǎn)義成新的文件內(nèi)容，并且每個Loader通過鏈?zhǔn)讲僮?，將源文件一步步翻譯成想要的樣子。

編寫Loader時要遵循單一原則，每個Loader只做一種"轉(zhuǎn)義"工作。 每個Loader的拿到的是源文件內(nèi)容（source），可以通過返回值的方式將處理后的內(nèi)容輸出，也可以調(diào)用this.callback()方法，將內(nèi)容返回給webpack。 還可以通過 this.async()生成一個callback函數(shù)，再用這個callback將處理后的內(nèi)容輸出出去。 此外webpack還為開發(fā)者準(zhǔn)備了開發(fā)loader的工具函數(shù)集——loader-utils。

相對于Loader而言，Plugin的編寫就靈活了許多。 webpack在運(yùn)行的生命周期中會廣播出許多事件，Plugin 可以監(jiān)聽這些事件，在合適的時機(jī)通過 Webpack 提供的 API 改變輸出結(jié)果。

8.webpack的熱更新是如何做到的？說明其原理？

webpack的熱更新又稱熱替換（Hot Module Replacement），縮寫為HMR。 這個機(jī)制可以做到不用刷新瀏覽器而將新變更的模塊替換掉舊的模塊。

原理：

首先要知道server端和client端都做了處理工作

• 第一步，在 webpack 的 watch 模式下，文件系統(tǒng)中某一個文件發(fā)生修改，webpack 監(jiān)聽到文件變化，根據(jù)配置文件對模塊重新編譯打包，并將打包后的代碼通過簡單的 JavaScript 對象保存在內(nèi)存中。
• 第二步是 webpack-dev-server 和 webpack 之間的接口交互，而在這一步，主要是 dev-server 的中間件 webpack-dev-middleware 和 webpack 之間的交互，webpack-dev-middleware 調(diào)用 webpack 暴露的 API對代碼變化進(jìn)行監(jiān)控，并且告訴 webpack，將代碼打包到內(nèi)存中。
• 第三步是 webpack-dev-server 對文件變化的一個監(jiān)控，這一步不同于第一步，并不是監(jiān)控代碼變化重新打包。當(dāng)我們在配置文件中配置了devServer.watchContentBase 為 true 的時候，Server 會監(jiān)聽這些配置文件夾中靜態(tài)文件的變化，變化后會通知瀏覽器端對應(yīng)用進(jìn)行 live reload。注意，這兒是瀏覽器刷新，和 HMR 是兩個概念。
• 第四步也是 webpack-dev-server 代碼的工作，該步驟主要是通過 sockjs（webpack-dev-server 的依賴）在瀏覽器端和服務(wù)端之間建立一個 websocket 長連接，將 webpack 編譯打包的各個階段的狀態(tài)信息告知瀏覽器端，同時也包括第三步中 Server 監(jiān)聽靜態(tài)文件變化的信息。瀏覽器端根據(jù)這些 socket 消息進(jìn)行不同的操作。當(dāng)然服務(wù)端傳遞的最主要信息還是新模塊的 hash 值，后面的步驟根據(jù)這一 hash 值來進(jìn)行模塊熱替換。
• webpack-dev-server/client 端并不能夠請求更新的代碼，也不會執(zhí)行熱更模塊操作，而把這些工作又交回給了 webpack，webpack/hot/dev-server 的工作就是根據(jù) webpack-dev-server/client 傳給它的信息以及 dev-server 的配置決定是刷新瀏覽器呢還是進(jìn)行模塊熱更新。當(dāng)然如果僅僅是刷新瀏覽器，也就沒有后面那些步驟了。
• HotModuleReplacement.runtime 是客戶端 HMR 的中樞，它接收到上一步傳遞給他的新模塊的 hash 值，它通過 JsonpMainTemplate.runtime 向 server 端發(fā)送 Ajax 請求，服務(wù)端返回一個 json，該 json 包含了所有要更新的模塊的 hash 值，獲取到更新列表后，該模塊再次通過 jsonp 請求，獲取到最新的模塊代碼。這就是上圖中 7、8、9 步驟。
• 而第 10 步是決定 HMR 成功與否的關(guān)鍵步驟，在該步驟中，HotModulePlugin 將會對新舊模塊進(jìn)行對比，決定是否更新模塊，在決定更新模塊后，檢查模塊之間的依賴關(guān)系，更新模塊的同時更新模塊間的依賴引用。
• 最后一步，當(dāng) HMR 失敗后，回退到 live reload 操作，也就是進(jìn)行瀏覽器刷新來獲取最新打包代碼。

9.如何利用webpack來優(yōu)化前端性能？（提高性能和體驗(yàn)）

用webpack優(yōu)化前端性能是指優(yōu)化webpack的輸出結(jié)果，讓打包的最終結(jié)果在瀏覽器運(yùn)行快速高效。

• 壓縮代碼。刪除多余的代碼、注釋、簡化代碼的寫法等等方式?？梢岳脀ebpack的UglifyJsPlugin和ParallelUglifyPlugin來壓縮JS文件， 利用cssnano（css-loader?minimize）來壓縮css
• 利用CDN加速。在構(gòu)建過程中，將引用的靜態(tài)資源路徑修改為CDN上對應(yīng)的路徑?？梢岳脀ebpack對于output參數(shù)和各loader的publicPath參數(shù)來修改資源路徑
• 刪除死代碼（Tree Shaking）。將代碼中永遠(yuǎn)不會走到的片段刪除掉?？梢酝ㄟ^在啟動webpack時追加參數(shù)--optimize-minimize來實(shí)現(xiàn)
• 提取公共代碼。

10.如何提高webpack的構(gòu)建速度？

• 多入口情況下，使用CommonsChunkPlugin來提取公共代碼
• 通過externals配置來提取常用庫
• 利用DllPlugin和DllReferencePlugin預(yù)編譯資源模塊 通過DllPlugin來對那些我們引用但是絕對不會修改的npm包來進(jìn)行預(yù)編譯，再通過DllReferencePlugin將預(yù)編譯的模塊加載進(jìn)來。
• 使用Happypack 實(shí)現(xiàn)多線程加速編譯
• 使用webpack-uglify-parallel來提升uglifyPlugin的壓縮速度。 原理上webpack-uglify-parallel采用了多核并行壓縮來提升壓縮速度
• 使用Tree-shaking和Scope Hoisting來剔除多余代碼

11.怎么配置單頁應(yīng)用？怎么配置多頁應(yīng)用？

單頁應(yīng)用可以理解為webpack的標(biāo)準(zhǔn)模式，直接在entry中指定單頁應(yīng)用的入口即可，這里不再贅述

多頁應(yīng)用的話，可以使用webpack的 AutoWebPlugin來完成簡單自動化的構(gòu)建，但是前提是項(xiàng)目的目錄結(jié)構(gòu)必須遵守他預(yù)設(shè)的規(guī)范。 多頁應(yīng)用中要注意的是：

每個頁面都有公共的代碼，可以將這些代碼抽離出來，避免重復(fù)的加載。比如，每個頁面都引用了同一套css樣式表

隨著業(yè)務(wù)的不斷擴(kuò)展，頁面可能會不斷的追加，所以一定要讓入口的配置足夠靈活，避免每次添加新頁面還需要修改構(gòu)建配置

12.npm打包時需要注意哪些？如何利用webpack來更好的構(gòu)建？

Npm是目前最大的 JavaScript 模塊倉庫，里面有來自全世界開發(fā)者上傳的可復(fù)用模塊。你可能只是JS模塊的使用者，但是有些情況你也會去選擇上傳自己開發(fā)的模塊。 關(guān)于NPM模塊上傳的方法可以去官網(wǎng)上進(jìn)行學(xué)習(xí)，這里只講解如何利用webpack來構(gòu)建。

NPM模塊需要注意以下問題：

• 要支持CommonJS模塊化規(guī)范，所以要求打包后的最后結(jié)果也遵守該規(guī)則。
• Npm模塊使用者的環(huán)境是不確定的，很有可能并不支持ES6，所以打包的最后結(jié)果應(yīng)該是采用ES5編寫的。并且如果ES5是經(jīng)過轉(zhuǎn)換的，請最好連同SourceMap一同上傳。
• Npm包大小應(yīng)該是盡量?。ㄓ行﹤}庫會限制包大?。?/li>
• 發(fā)布的模塊不能將依賴的模塊也一同打包，應(yīng)該讓用戶選擇性的去自行安裝。這樣可以避免模塊應(yīng)用者再次打包時出現(xiàn)底層模塊被重復(fù)打包的情況。
• UI組件類的模塊應(yīng)該將依賴的其它資源文件，例如.css文件也需要包含在發(fā)布的模塊里。

基于以上需要注意的問題，我們可以對于webpack配置做以下擴(kuò)展和優(yōu)化：

• CommonJS模塊化規(guī)范的解決方案： 設(shè)置output.libraryTarget='commonjs2'使輸出的代碼符合CommonJS2 模塊化規(guī)范，以供給其它模塊導(dǎo)入使用
• 輸出ES5代碼的解決方案：使用babel-loader把 ES6 代碼轉(zhuǎn)換成 ES5 的代碼。再通過開啟devtool: 'source-map'輸出SourceMap以發(fā)布調(diào)試。
• Npm包大小盡量小的解決方案：Babel 在把 ES6 代碼轉(zhuǎn)換成 ES5 代碼時會注入一些輔助函數(shù)，最終導(dǎo)致每個輸出的文件中都包含這段輔助函數(shù)的代碼，造成了代碼的冗余。解決方法是修改.babelrc文件，為其加入transform-runtime插件
• 不能將依賴模塊打包到NPM模塊中的解決方案：使用externals配置項(xiàng)來告訴webpack哪些模塊不需要打包。
• 對于依賴的資源文件打包的解決方案：通過css-loader和extract-text-webpack-plugin來實(shí)現(xiàn)，配置如下：

13.如何在vue項(xiàng)目中實(shí)現(xiàn)按需加載？

Vue UI組件庫的按需加載 為了快速開發(fā)前端項(xiàng)目，經(jīng)常會引入現(xiàn)成的UI組件庫如ElementUI、iView等，但是他們的體積和他們所提供的功能一樣，是很龐大的。 而通常情況下，我們僅僅需要少量的幾個組件就足夠了，但是我們卻將龐大的組件庫打包到我們的源碼中，造成了不必要的開銷。

不過很多組件庫已經(jīng)提供了現(xiàn)成的解決方案，如Element出品的babel-plugin-component和AntDesign出品的babel-plugin-import 安裝以上插件后，在.babelrc配置中或babel-loader的參數(shù)中進(jìn)行設(shè)置，即可實(shí)現(xiàn)組件按需加載了。

單頁應(yīng)用的按需加載 現(xiàn)在很多前端項(xiàng)目都是通過單頁應(yīng)用的方式開發(fā)的，但是隨著業(yè)務(wù)的不斷擴(kuò)展，會面臨一個嚴(yán)峻的問題——首次加載的代碼量會越來越多，影響用戶的體驗(yàn)。

通過import(*)語句來控制加載時機(jī)，webpack內(nèi)置了對于import(*)的解析，會將import(*)中引入的模塊作為一個新的入口在生成一個chunk。 當(dāng)代碼執(zhí)行到import(*)語句時，會去加載Chunk對應(yīng)生成的文件。import()會返回一個Promise對象，所以為了讓瀏覽器支持，需要事先注入Promise polyfill

參考文章

關(guān)于 webpack 的面試題有哪些？

前端面試之webpack面試常見問題

《深入淺出webpack》電子版

webpack 構(gòu)建性能優(yōu)化策略小結(jié)

以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評論