webpack有做過哪些優化和配置嗎
⑴ webpack打包原理
webpack打包原理是根據文件間的依賴關系對其進行靜態分析，然後將這些模塊按指定規則生成靜態資源，當 webpack 處理程序時，它會遞歸地構建一個依賴關系圖(dependency graph)，其中包含應用程序需要的每個模塊，然後將所有這些模塊打包成一個或多個 bundle。
webpack有兩種組織模塊的依賴方式，同步、非同步。非同步依賴將作為分割點，形成一個新的塊；在優化了依賴樹之後，每一個非同步區塊都將作為一個文件被打包。
webpack有一個智能解析器，幾乎可以處理任何第三方庫。無論它們的模塊形式是CommonJS、AMD還是普通的JS文件；甚至在載入依賴的時候，允許使用動態表require("、/templates/"+name+"、jade")。
(1)webpack有做過哪些優化和配置嗎擴展閱讀
在使用webpack構建的典型應用程序或站點中，有三種主要的代碼類型：
1、團隊編寫的源碼。
2、源碼會依賴的任何第三方的library或"vendor"代碼。
3、webpack的runtime和manifest，管理所有模塊的交互。
runtime 包含：在模塊交互時，連接模塊所需的載入和解析邏輯；包括瀏覽器中的已載入模塊的連接，以及懶載入模塊的執行邏輯。
⑵ 開源了一個 webpack 插件，希望對大家有所幫助
最近，陸陸續續搞 了一個 插件(下面介紹)，這是自己第三個開源項目，希望大家一起來維護，一起 star 呀，其它兩個：
用 uniapp開發小程序的小夥伴應該知道，我們在 uniapp 中要使用第三方 UI 庫( vant-weapp ， iView-weapp )的時候 ，想要在全局中使用，需要在 src/pages.json 中的 usingComponents 添加對應的組件聲明，如：
但在開發過程中，我們不太清楚需要哪些組件，所以我們可能會全部聲明一遍（PS:這在做公共庫的時候更常見)，所以我們得一個個的寫，做為程序員，我們絕不允許使用這種笨方法。 這是第一個痛點 。
使用第三方組件，除了在 src/pages.json 還需要在對應的生產目錄下建立 wxcomponents ，並將第三方的庫拷貝至該文件下，這個是 uniapp 自定義的，詳細就見：https://uniapp.dcloud.io/frame?id=%e7%9b%ae%e5%bd%95%e7%bb%93%e6%9e%84。
這是第二個痛點 。
第二痛點，我們將整個UI庫拷貝至 wxcomponents ，但最終發布的時候，我們不太可能全都用到了裡面的全局組件，所以就將不必要的組件也發布上去，增加代碼的體積。
有的小夥伴就會想到，那你將第三方的庫拷貝至 wxcomponents 時候，可以只拷使用到的就行啦。是這理沒錯，但組件裡面可能還會使用到其它組件，我們還得一個個去看，然後一個個引入，這又回到了 第一個痛點了 。
有了這三個痛點，必須得有個插件來做這些傻事，處理這三個痛點。於是就有 插件，這個webpack 插件主要解決下面幾個問題：
webpack 的插件體系是一種基於 Tapable 實現的強耦合架構，它在特定時機觸發鉤子時會附帶上足夠的上下文信息，插件定義的鉤子回調中，能也只能與這些上下文背後的數據結構、介面交互產生 side effect，進而影響到編譯狀態和後續流程。
從形態上看，插件通常是一個帶有 apply 函數的類：
Webpack 會在啟動後按照注冊的順序逐次調用插件對象的 apply 函數，同時傳入編譯器對象 compiler ，插件開發者可以以此為起點觸達到 webpack 內部定義的任意鉤子，例如：
注意觀察核心語句 compiler.hooks.thisCompilation.tap ，其中 thisCompilation 為 tapable 倉庫提供的鉤子對象； tap 為訂閱函數，用於注冊回調。
Webpack 的插件體系基於 tapable 提供的各類鉤子展開，所以有必要先熟悉一下 tapable 提供的鉤子類型及各自的特點。
到這里，就不做繼續介紹了，關於插件的更多 詳情可以去官網了解。
這里推薦 Tecvan 大佬寫的 《Webpack 插件架構深度講解》
插件主要用到了三個 compiler 鉤子。
第一個鉤子是 environment :
這個鉤子主要用來自動引入其下的原生組件，這樣就無需手動配置。 解決第一個痛點 。
第二個鉤子 thisCompilation ，這個鉤子可以獲得 compilation ，能對最終打包的產物進行操作：
所以這個勾子用來將 node_moles 下的第三庫拷貝到我們生產 dist 目錄裡面的 wxcomponents ， 解決第二個痛點 。
ps：這里也可直接用現有的 -webpack-plugin 插件來實現。
第三個鉤子 done ，表示 compilation 執行完成：
執行完成後，表示我們已經生成 dist 目錄了，可以讀取文件內容，分析，獲取哪些組件被使用了，然後刪除沒有使用到組件對應的文件。這樣就可以解決我們 第三個痛點了 。
PS：這里我判斷只有在生產環境下才會 剔除，開發環境沒有，也沒太必要。
安裝
然後將插件添加到 WebPack Config 中。例如：
NameType Description patterns{Array}為插件指定相關
moleprefix 模塊名組件前綴
mole 是指 package.json 裡面的 name ，如使用是 Vant 對應的 mole 為 @vant/weapp ，如果使用是 iview，剛對應的 mole 為 iview-weapp ，具體可看它們各自的 package.json 。
prefix 是指組件的前綴，如 Vant 使用是 van 開頭的前綴，iview 使用是 i 開頭的前綴，具體可看它們各自的官方文檔。
PS: 這里得吐曹一下 vant，叫別人使用 van 的前綴，然後自己組件裡面聲明子組件時，卻沒有使用 van 前綴，如 picker 組件，它裡面的 JSON 文件是這么寫的：
picker-column 和 loading 都沒有帶 van 前綴，因為這個問題，在做 自動剔除 功能中，我是根據 前綴來判斷使用哪些組件的，由於這里的 loading ， picker-column 沒有加前綴，所以就被會刪除，導致最終的 picker 用不了。為了解決這個問題，增加了不少工作量。
希望 Vant 官方後面的版本能優化一下。
本文通用自定義 Webpack 插件來實現日常一些技術優化需求。主要為大家介紹了 Webpack 插件的基本組成和簡單架構，通過三個痛點，引出了 uni-using-components-webpack-plugin 插件，並介紹了使用方式，實現思路。
最後，關於 Webpack 插件開發，還有更多知識可以學習，建議多看看官方文檔《Writing a Plugin》進行學習。
⑶ webpack 性能優化怎麼做
送到這個直接去優化行動中應該能搞定優化生活，我認為這應該是小孩兒為什麼還是涼的。
⑷ webpack 打包怎麼優化的
解決webpack打包的文件體積過大的問題：
確實，每次打包從入口開始，會parse所有的依賴，多的時候竟然打包一次要2秒多，簡直不能忍。然而，有幾個解決方案，最有效的，是使用weboack的watch，只有文件md5變化時，才會重新打包，並且只parse有變化的文件，其他沒變化的文件是使用緩存的。這樣子，打包時間迅速降到200ms以內。 再優化下去的話，我們要知道webpack打包的過程中做了啥，首先是解析依賴啦，然後就是各種各樣的loader。從解析依賴的角度入手，我們可以bower install一些打包好的文件，然後通過設置別名讓依賴指向這個文件，這樣就減去了第三方庫的依賴解析時間。 然後各種各樣的loader也是很耗時的，一種辦法是在loader裡面配include，讓loader只針對特殊資源。
⑸ webpack承擔了哪些工作原理功能
承擔了很多前端代碼的自動化生成的工作。
搭配很多loader，可以完成不同的事情。
比如說把繁雜的項目中用到的js打包並壓縮成你設定的一個或多個文件去發布到生產環境。
比如把react中引用的圖片壓縮並抽出來項目中引用到的。沒引用到的，不會拿過來。
比如CSS Moles，單個組件開發時用單獨的css定義，最終打包成一個css文件里，而沒用到的css不會打包。而且通過設置，不用擔心各個文件中的同名css打包到一個css里後重復。
less轉css
sass轉css
PostCSS轉css
es6寫的js，通過babel轉成瀏覽器可執行的es5
......
原理，其實就是用程序代替人的工作。比如我們開發的時候經常是css寫到一個或幾個文件，隨著迭代，裡面肯定就產生很多垃圾不再用的代碼，而用人去識別很累，如果用CSS Moles，把css也模塊化，隨著迭代，不再引用到的，就不會再打包進去，不用人來識別了。同理，瀏覽器是不識別sass這種的，程序來幫你轉成瀏覽器可讀的css。不管用什麼程序，其實都可以開發這樣的一個解釋器，其實就是一個翻譯轉化的過程。只不過當前前端的發展需要和node的便捷加上npm方便的分發，所以在node中，大量的工具出現了。
其實原理和功能，就是用程序代替人做那些事，由程序翻譯成普通瀏覽器可執行的代碼。
⑹ 2020年Web前端性能優化需要做哪些
今天小編要跟大家分享的文章是關於2020年Web前端性能優化需要做哪些?性能優化一直以來都是前端工程領域中的一個重要部分。很多資料表明，網站應用的性能優化對於提高用戶留存、轉化率等都有積極影響。可以理解為，提升你的網站性能，就是提升你的業務數據(甚至是業務收入)。
性能優化廣義上包含前端優化和後端優化。後端優化的關注點更多的時候是在增加資源利用率、降低資源成本以及提高穩定性上。相較於後端，前端的性能優化會更直接與用戶的體驗掛鉤。從用戶體驗側來說，前端服務
5s的載入時間優化縮減80%(1s)與後端服務50ms的響應優化縮減80%(10ms)
相比，用戶的體驗提升會更大。因此很多時候，與體驗相關的性能的瓶頸會出現在前端。下面就來和小編一起看一看吧!
一、html文檔結構標簽語義化
1、首先什麼是語義化呢?
語義化是指用合理HTML標記以及其特有的屬性去格式化文檔內容。機器在需要更少的人類干預的情況下能夠研究和收集信息,讓網頁能夠被機器理解,最終讓人類受益。即用正確的標簽做正確的事。
2、語義化的好處或者說存在的意義
①有利於搜索引擎抓取
②結構清晰的HTML在團隊合作中的作用：代碼可讀、便於維護、提高開發效率、快速達成共識、利於二次開發。
③有利於盲人屏幕閱讀器
二、css、js文件數量及大小
優化一般對於css、js是建議使用外聯式來進行導入。我們可以對css、js做相應的規劃也可以減少css、js的個數以減少http請求。同時也要注重減少重復代碼，注重代碼重復利用，以達到用最少的代碼干最多的事。同時當項目要投入上線使用的時候，可以對css、js文件進行壓縮，文件的減小可以加速文件的鏈接導入，以便加速網頁的載入渲染。
可通過使用Webpack，gulp等工具對Js文件進行合並。
三、圖片的數量和大小
多個伺服器請求會對站點的性能產生顯著的影響。對一張圖片進行導入又是一個http請求，因此我們應該減少圖片的導入數量以便減少http請求。此處，我們必須提到一個名詞「css精靈spirit」。css精靈是指包含多個不同的圖標、按鈕或圖形的單個圖像。因此我們可以把多張背景圖片合並為一張然後對背景圖片進行相應的定位。同時使用PNG8格式的圖片相對於GIF來說比較少。而對於內容圖片，可以對其進行適當的壓縮，可以加快文檔內容載入，或者如果是需要用戶下載的圖片，小的圖片可以加快用戶下載的速度。
使用較為廣泛的Web圖片格式有：JPEG/JPG、PNG、WEBP、Base64、SVG。
1.JPEG/JPG
特點是有損壓縮，體積小，載入快，不支持透明。
使用場景：JPG適合用於呈現熱菜豐富的圖片，在日常的開發中，JPG圖片經常作為大的背景圖、輪播圖或是Banner圖。比如兩大電商網站對大圖片的處理，就是對JPG圖片應用場景的最佳寫照。用JPG來呈現大圖片，既可以保留圖片的質量，又不會擔心圖片的體積，是一種比較廣泛使用的方案。
缺點：在處理一些矢量圖形和logo等這些線條感很強、顏色對比強烈的圖片時，認為壓縮就導致圖片模糊非常明顯。另外，JPG圖像不支持透明度處理，透明圖片只能用PNG來呈現了。
2.PNG-8和PNG-24
特點是無損壓縮、質量高、體積大、支持透明
優點：無損壓縮的高保真圖片格式。8和24都是二進制數的位數，8位的PNG支持256中顏色，24位的PNG可以支持1600萬種顏色。在不考慮文件大小隻在乎最佳的顯示效果時，推薦使用PNG-24。但是在適合使用PNG時會優先選擇PNG-8
應用場景：主要用PNG來呈現小的LOGO、顏色簡單對比強烈的圖片或是背景。
3.SVG
特點是文本文件，體積小，不失真，兼容性好
優點：SVG是一種基於XML語法的圖像格式。SVG對圖像的處理不是基於像素，而是基於對圖像的形狀描述。
和JPG、PNG相比較，SVG文件體積更小，可壓縮性更強。SVG作為矢量圖最大的優點在於圖片可以無限放大還不失真，一張SVG圖片可以適配多種解析度。另外SVG是文本文件，可以像寫代碼一樣定義SVG，放在HTML中稱為DOM的一部分。也可以把對圖像的描述寫入以.svg為後綴的文件中，在img標簽中引入即可。
4.WebP
優點：WebP是一款比JPG、PNG等在壓縮方面更加優越的圖片格式，同時也不會影響其圖片質量，使用該格式時最好將同名文件格式化，當檢測瀏覽器不兼容時自動切換jpg格式
缺點：是一個相對較新的技術，所以對於目前市面上的瀏覽器能否完美的兼容，其可用和實用性就變得很現實了，再好的東西如果沒有好的兼容性，也是非常難以普及和被廣泛使用的
5.Base64
優點：減少請求，加快首屏數據顯示。對於jpg格式的圖片，每一個圖片相當於一次http請求，圖片多了的話，伺服器耗性能比較嚴重。而將jpg轉化成base64格式的圖片，則極大地減少了請求數，因為Base是文本格式。
缺點：base64格式圖片比原圖大，佔用更多存儲空間，同時，瀏覽器不會對該資源緩存。
使用方法：background:url(data:image/png;base64,{img_data})
應用場景：一般對於小於10KB大小的圖片進行base64轉碼。
至於動態圖有GIF與APNG：後者APNG這東西是mozilla搞出來的，
它是24位的，而且也是動圖，可以容納1680萬種顏色，也是為了取代GIF，但是....也就火狐支持，IE10和chrome，safari全部不行，
如果說gif圖片是卡片機的話，APNG就是單反
四、有效性驗證
除了根據語義加標記之外，HTML文檔還需要用有效的代碼來編寫，如果代碼是無效的，瀏覽器會嘗試解釋標記本身，有時候會產生錯誤的結果。更糟的是，如果發送具有正確的MIME類型的XHTML文檔，理解XML的瀏覽器將不顯示無效的頁面。因為瀏覽器需要知道要使用什麼DTD(文檔類型定義)才能正確地處理頁面，所以對頁面進行有效性驗證要求有DOCTYPE聲明。
有效性驗證工具徑：
①
W3C驗證器(bookmarklet)，這是一小段可以存儲在瀏覽器的書簽或收藏夾中的Javascript。單擊這個書簽就會觸發Javascript動作。
②可以訪問http://validator.w3.org/，通過輸入自己的URL來對自己的站點來進行在線驗證。
③使用firefox瀏覽器的可以下載插件FirefoxWebDeveloperExtension
五、雅虎的Web優化最佳實踐
1、內容優化
①盡量減少HTTP請求：常見方法包括合並多個CSS文件和JavaScript文件，利用CSSSprites整合圖像，Image
map(圖像中不同的區域設置不同的鏈接)，內聯圖象(使用data:URLscheme在實際的頁面嵌入圖像數據)等。
②減少DNS查找，一般dns查找需要花費20-120ms，Windows的DNS緩存，可以通過ipconfig/displaydns
這個命令來查看。
③避免重定向
④使Ajax可緩存
⑤延遲載入組件：考慮哪些內容是頁面呈現時所必需首先載入的、哪些內容和結構可以稍後再載入，根據這個優先順序進行設定。
⑥
預載入組件：預載入是在瀏覽器空閑時請求將來可能會用到的頁面內容(如圖像、樣式表和腳本)。當用戶要訪問下一個頁面時，頁面中的內容大部分已經載入到緩存中了，因此可以大大改善訪問速度。
⑦減少DOM元素數量：頁面中存在大量DOM元素，會導致JavaScript遍歷DOM的效率變慢。
⑧根據域名劃分頁面內容：把頁面內容劃分成若幹部分可以使你最大限度地實現平行下載。但要確保你使用的域名數量在2個到4個之間(否則與第2條沖突)。
⑨最小化iframe的數量：iframes
提供了一個簡單的方式把一個網站的內容嵌入到另一個網站中。但其創建速度比其他包括JavaScript和CSS的DOM元素的創建慢了1-2個數量級。
⑩
避免404：HTTP請求時間消耗是很大的，因此使用HTTP請求來獲得一個沒有用處的響應(例如404沒有找到頁面)是完全沒有必要的，它只會降低用戶體驗而不會有一點好處。
2、伺服器優化
①使用內容分發網路(CDN)：把你的網站內容分散到多個、處於不同地域位置的伺服器上可以加快下載速度。
添加Expires或Cache-Control信息頭：對於靜態內容，可設置文件頭過期時間Expires的值為「Never
expire(永不過期)」;對於動態內容，可使用恰當的Cache-Control文件頭來幫助瀏覽器進行有條件的請求。
②Gzip壓縮
③設置ETag：ETags(Entity
tags，實體標簽)是Web伺服器和瀏覽器用於判斷瀏覽器緩存中的內容和伺服器中的原始內容是否匹配的一種機制。
④
提前刷新緩沖區：當用戶請求一個頁面時，伺服器會花費200到500毫秒用於後台組織HTML文件。在這期間，瀏覽器會一直空閑等待數據返回。在PHP中，可以使用flush()方法，它允許你把已經編譯的好的部分HTML響應文件先發送給瀏覽器，這時瀏覽器就會可以下載文件中的內容(腳本等)而後台同⑤時處理剩餘的HTML頁面。
⑥
對Ajax請求使用GET方法：當使用XMLHttpRequest時，瀏覽器中的POST方法會首先發送文件頭，然後才發送數據。因此使用GET最為恰當。
⑦避免空的圖像src
3、Cookie優化
①減小cookie大小：去除不必要的coockie，並使coockie體積盡量小以減少對用戶響應的影響
②
針對Web組件使用域名無關的Cookie：對靜態組件的Cookie讀取是一種浪費，使用另一個無Cookie的域名來存放靜態組件是一個好方法，或者也可以在Cookie中只存放帶www的域名。
4、CSS優化
①將CSS代碼放在HTML頁面的頂部
②避免使用CSS表達式：CSS表達式在執行時候的運算量非常大，會對頁面性能產生大的影響
③使用來代替@import
④避免使用Filters：IE獨有屬性AlphaImageLoader用於修正IE
7以下版本中PNG圖片的半透明效果，但它的問題在於瀏覽器載入圖片時它會終止內容的呈現並且凍結瀏覽器。
5、JavaScript優化
①將JavaScript腳本放在頁面的底部
②
將JavaScript和CSS作為外部文件來引用：在實際應用中使用外部文件可以提高頁面速度，因為JavaScript和CSS文件都能在瀏覽器中產生緩存。
③縮小JavaScript和CSS
④刪除重復的腳本
⑤最小化DOM的訪問：使用JavaScript訪問DOM元素比較慢
⑥開發智能的事件處理程序
6、圖像優化
①優化圖片大小
②通過CSSSprites優化圖片
③不要在HTML中使用縮放圖片
④favicon.ico要小而且可緩存
7、針對移動優化
①保持組件大小在25KB以下：主要是因為iPhone不能緩存大於25K的文件(注意這里指的是解壓縮後的大小)。
②將組件打包成為一個復合文檔：把頁面內容打包成復合文本就如同帶有多附件的Email，它能夠使你在一個HTTP請求中獲取多個組件。
以上就是小編今天為大家分享的關於2020年Web前端性能優化需要做哪些的文章，希望本篇文章能夠對正在從事Web前端工作的小夥伴們有所幫助，想要了解更多Web前端知識記得關注北大青鳥Web培訓官網。最後祝願小夥伴們工作順利，成為一名優秀的Web前端工程師。
⑺ 前端構建工具webpack有什麼缺陷
配置多入口時，沒有glob的方式，需要額外處理。
目錄結構復雜時，file-loder裡面的path功能太弱，很多時候無法自定義構建後的目錄結構，只能放在一個目錄下。
源碼比較復雜，遇到問題看源碼，要花很長時間。
如果沒有 babel， webpack 對 ES2015+ 的語法是不接受的，會提示用指定 loader。這意味著，在支持部分 ES2015 語法的 firefox 與 chrome 瀏覽器中能直接跑的代碼，無法用 webpack 編譯。
⑻ webpack到底有什麼用
1. 為什麼用 webpack?
他像 Browserify, 但是將你的應用打包為多個文件. 如果你的單頁面應用有多個頁面, 那麼用戶只從下載對應頁面的代碼. 當他么訪問到另一個頁面, 他們不需要重新下載通用的代碼.
他在很多地方能替代 Grunt 跟 Gulp 因為他能夠編譯打包 CSS, 做 CSS 預處理, 編譯 JS 方言, 打包圖片, 還有其他一些.
它支持 AMD 跟 CommonJS, 以及其他一些模塊系統, (Angular, ES6). 如果你不知道用什麼, 就用 CommonJS.
2. Webpack 給 Browserify 的同學用
對應地:
browserify main.js > bundle.js
webpack main.js bundle.js
Webpack 比 Browserify 更強大, 你一般會用 webpack.config.js 來組織各個過程:
// webpack.config.js
mole.exports = {
entry: './main.js',
output: {
filename: 'bundle.js'
}
};
這僅僅是 JavaScript, 可以隨意添加要運行的代碼.
3. 怎樣啟動 webpack
切換到有 webpack.config.js 的目錄然後運行:
webpack 來執行一次開發的編譯
webpack -p for building once for proction (minification)
webpack -p 來針對發布環境編譯(壓縮代碼)
webpack --watch 來進行開發過程持續的增量編譯(飛快地!)
webpack -d 來生成 SourceMaps
4. JavaScript 方言
Webpack 對應 Browsserify transform 和 RequireJS 插件的工具稱為 loader. 下邊是 Webpack 載入 CoffeeScript 和 Facebook JSX-ES6 的配置(你需要 npm install jsx-loader coffee-loader):
// webpack.config.js
mole.exports = {
entry: './main.js',
output: {
filename: 'bundle.js'
},
mole: {
loaders: [
{ test: /\.coffee$/, loader: 'coffee-loader' },
{ test: /\.js$/, loader: 'jsx-loader?harmony' } // loaders 可以接受 querystring 格式的參數
]
}
};
要開啟後綴名的自動補全, 你需要設置 resolve.extensions 參數指明那些文件 Webpack 是要搜索的:
// webpack.config.js
mole.exports = {
entry: './main.js',
output: {
filename: 'bundle.js'
},
mole: {
loaders: [
{ test: /\.coffee$/, loader: 'coffee-loader' },
{ test: /\.js$/, loader: 'jsx-loader?harmony' }
]
},
resolve: {
// 現在可以寫 require('file') 代替 require('file.coffee')
extensions: ['', '.js', '.json', '.coffee']
}
};
5. 樣式表和圖片
首先更新你的代碼用 require() 載入靜態資源(就像在 Node 里使用 require()):
require('./bootstrap.css');
require('./myapp.less');
var img = document.createElement('img');
img.src = require('./glyph.png');
當你引用 CSS(或者 LESS 吧), Webpack 會將 CSS 內聯到 JavaScript 包當中, require() 會在頁面當中插入一個 ｀<style>標簽. 當你引入圖片, Webpack 在包當中插入對應圖片的 URL, 這個 URL 是由require()` 返回的.
你需要配置 Webpack(添加 loader):
// webpack.config.js
mole.exports = {
entry: './main.js',
output: {
path: './build', // 圖片和 JS 會到這里來
publicPath: 'http://mycdn.com/', // 這個用來成成比如圖片的 URL
filename: 'bundle.js'
},
mole: {
loaders: [
{ test: /\.less$/, loader: 'style-loader!css-loader!less-loader' }, // 用 ! 來連接多個人 loader
{ test: /\.css$/, loader: 'style-loader!css-loader' },
{test: /\.(png|jpg)$/, loader: 'url-loader?limit=8192'} // 內聯 base64 URLs, 限定 <=8k 的圖片, 其他的用 URL
]
}
};
6. 功能開關
有些代碼我們只想在開發環境使用(比如 log), 或者 dogfooging 的伺服器里邊(比如內部員工正在測試的功能). 在你的代碼中, 引用全局變數吧:
if (__DEV__) {
console.warn('Extra logging');
}
// ...
if (__PRERELEASE__) {
showSecretFeature();
}
然後配置 Webpack 當中的對應全局變數:
// webpack.config.js
// definePlugin 接收字元串插入到代碼當中, 所以你需要的話可以寫上 JS 的字元串
var definePlugin = new webpack.DefinePlugin({
__DEV__: JSON.stringify(JSON.parse(process.env.BUILD_DEV || 'true')),
__PRERELEASE__: JSON.stringify(JSON.parse(process.env.BUILD_PRERELEASE || 'false'))
});
mole.exports = {
entry: './main.js',
output: {
filename: 'bundle.js'
},
plugins: [definePlugin]
};
然後你在控制台里用 BUILD_DEV=1 BUILD_PRERELEASE=1 webpack 編譯. 注意一下因為 webpack -p 會執行 uglify dead-code elimination, 任何這種代碼都會被剔除, 所以你不用擔心秘密功能泄漏.
7. 多個進入點(entrypoints)
比如你用 profile 頁面跟 feed 頁面. 當用戶訪問 profile, 你不想讓他們下載 feed 頁面的代碼. 因此你創建多個包: 每個頁面一個 "main mole":
// webpack.config.js
mole.exports = {
entry: {
Profile: './profile.js',
Feed: './feed.js'
},
output: {
path: 'build',
filename: '[name].js' // 模版基於上邊 entry 的 key
}
};
針對 profile, 在頁面當中插入 <script src="build/Profile.js"></script>. feed 頁面也是一樣.
8. 優化共用代碼
feed 頁面跟 profile 頁面共用不要代碼(比如 React 還有通用的樣式和 component). Webpack 可以分析出來他們有多少共用模塊, 然後生成一個共享的包用於代碼的緩存.
// webpack.config.js
var webpack = require('webpack');
var commonsPlugin =
new webpack.optimize.CommonsChunkPlugin('common.js');
mole.exports = {
entry: {
Profile: './profile.js',
Feed: './feed.js'
},
output: {
path: 'build',
filename: '[name].js'
},
plugins: [commonsPlugin]
};
在上一個步驟的 script 標簽前面加上 <script src="build/common.js"></script> 你就能得到廉價的緩存了.
9. 非同步載入
CommonJS 是同步的, 但是 Webpack 提供了非同步指定依賴的方案. 這對於客戶端的路由很有用, 你想要在每個頁面都有路由, 但你又不像在真的用到功能之前就下載某個功能的代碼.
聲明你想要非同步載入的那個"分界點". 比如:
if (window.location.pathname === '/feed') {
showLoadingState();
require.ensure([], function() { // 語法奇葩, 但是有用
hideLoadingState();
require('./feed').show(); // 函數調用後, 模塊保證在同步請求下可用
});
} else if (window.location.pathname === '/profile') {
showLoadingState();
require.ensure([], function() {
hideLoadingState();
require('./profile').show();
});
}
Webpack 會完成其餘的工作, 生成額外的 chunk 文件幫你載入好.
Webpack 在 HTML script 標簽中載入他們時會假設這些文件是怎你的根路徑下. 你可以用 output.publicPath 來配置.
// webpack.config.js
output: {
path: "/home/proj/public/assets", // path 指向 Webpack 編譯能的資源位置
publicPath: "/assets/" // 引用你的文件時考慮使用的地址