1. 全網(wǎng)最貼心webpack系列教程和配套代碼

2. webpack4系列教程

3. webpack - babel配置

4. 沒有了CommonsChunkPlugin腋寨，咱拿什么來分包

5. webpack.config.js配置遇到Error: Cannot find module '@babel/core'問題

6. NPM install -save 和 -save-dev 傻傻分不清

7. 怎么理解webpack中的output.filename 和output.chunkFilename

8. webpack4——SplitChunksPlugin使用指南

9. Webpack4之SplitChunksPlugin規(guī)則

10. SplitChunksPlugin

先看 第三篇.

下載

npm install --save-dev babel-loader babel-core babel-preset-env

配置
原文

module: {
    rules: [
        {
            test: /\.js$/,
            use: {
                loader: 'babel-loader',
                options: {
                    presets: [
                        ['env',{
                            targets: {
//targets是presets的一些預(yù)設(shè)選項亏吝，這里表示將js用于瀏覽器片效，只確保占比大于1%的瀏覽器的特性，主流瀏覽器的最新兩個主版本。(沒聽懂)
                                browsers: ['> 1%', 'last 2 versions']
                            }
                        }]
                    ]
                }
            },
//定義不希望babel處理的文件
            exclude: '/node_modules/'
        }
    ]
}

報錯

image.png

我寫成這個樣子

{
        test : /\.js$/,
        use : [
          loader : "babel-loader",
          options : {
            presets : [
              ['env',{
                target : {
                  browsers : ['>1%','last 2 versions']
                }
              }]
            ]
          }
        
        ],
        exclude :'/node_modules/'
      }

改一下

{
        test : /\.js$/,
        use : [{
          loader : "babel-loader",
          options : {
            presets : [
              ['env',{
                target : {
                  browsers : ['>1%','last 2 versions']
                }
              }]
            ]
          }
        }
        ],
        exclude :'/node_modules/'
      }

還是報錯

image.png

改成原文粘貼,還是報同樣的錯.
仔細看了一下錯誤信息,似乎是說, 版本不太對.
果斷百度

webpack.config.js配置遇到Error: Cannot find module '@babel/core'問題

果然是版本問題

image.png

低版本,
npm install -D babel-loader@7 babel-core babel-preset-env
最新版本
npm install -D babel-loader @babel/core @babel/preset-env webpack

我用了第二種下載
發(fā)現(xiàn)package.json中

    "@babel/core": "^7.1.6",
    "@babel/preset-env": "^7.1.6",
    "babel-core": "^6.26.3",
    "babel-loader": "^8.0.4",
    "babel-preset-env": "^1.7.0",

然后用 uninstall 刪除了 "babel-core": "^6.26.3", "babel-preset-env": "^1.7.0",
結(jié)果報錯

image.png

字面意思是還要重新下 "babel-preset-env"?
鬧心.. 刪了,重新用低版本的語句.
成功..

測試用 .bablerc
這是個什么意思? 是文件名,還是文件格式? 他說的是json格式.

image.png

創(chuàng)建一個 bablerc.json文件 在根目錄中.
反正效果是正常出現(xiàn), 但不知道是不是正常把 es6改成es5了啊..

babel-polifill插件
首先這是個插件..
說是什么墊片, 什么是墊片?
咦,他說 babel-polifill插件有缺陷,全局污染什么的.
用 runtime-transform插件
安裝

npm install --save-dev babel-plugin-transform-runtime

npm install --save babel-runtime

疑問,-g 是全局, --save-dev 我知道是 開發(fā)環(huán)境, --save是什么?

NPM install -save 和 -save-dev 傻傻分不清

明白了
就是生產(chǎn)環(huán)境和開發(fā)環(huán)境的區(qū)別.
標記為開發(fā)環(huán)境的包,是指,我建立項目需要用到的工具,
項目完成后,這些工具對項目的運行是沒有必要的.

而標記為生產(chǎn)環(huán)境的包,是指,項目最后運行時,需要的包.

如果把 --save 的寫成 --save-dev 那最后可能項目用不了?
如果把 --save-dev 寫成 --save 那項目就擁有了沒用的很多東西?

回到正題,
在bablerc 文件中放入

{
    "plugins": ["transform-runtime"]
}

報錯
改回了,就是位置放錯了,要放在preset 同級的位置上.

webpack4 系列教程(三): 多頁面解決方案--提取公共代碼
先跟著讀一遍
然后試著寫一遍.

問題1. chunkFilename是什么?

怎么理解webpack中的output.filename 和output.chunkFilename

webpack中output配置項中chunkFilename屬性的用法
大意是說, 異步加載的模塊,不會按照filename 的規(guī)則生成文件名?
會按照 chunkFilename 的規(guī)則生成文件名?
似乎多用于 這種情況?

require.ensure([],function(require){alert(11);require('./greeter')})
require.ensure(["modules/tips.jsx"], function(require) {
    var a = require("modules/tips.jsx");
    // ...
}, 'tips');

require.ensure的用法;異步加載-代碼分割

問題2 optimization.splitChunks 是什么?

沒有了CommonsChunkPlugin所计，咱拿什么來分包

感覺寫的很詳細,很牛逼, 但看得我腦瓜疼.
他要是配些圖就好了.
首先理解他的配置和效果的因果關(guān)系之前,
我首先要理解他要解決的是什么? 他要解決什么需求?
我覺得是這樣的.
我們寫完源代碼,用webpack打包,生成最終文件.
假設(shè)默認最終只生成一個文件?
那這個文件肯定太大了,用戶發(fā)送請求獲取的時候,
解析后渲染一定會很慢啊.
所以,起碼應(yīng)該把 img 這種資源要分割開來.
還有一些資源,js代碼,我們希望是按需加載,
這一部分的代碼,我們也應(yīng)該分割開來.
假設(shè)我們的服務(wù)器上存在多個頁面,
那這幾個頁面必然是不同的文件,
而這些頁面的js,或者其他資源,有可能是共用的.
或者可以說,我們應(yīng)該把這些文檔中,
重復(fù)的部分抽離分割成獨立的文件,
比如 common.

假設(shè),以上是我們打包后的分割需求(估計還有其他原因的分割需求)
第一種方案是,
我們在寫源文件的時候,
就可以按照最終的邏輯寫文檔.
然后讓該獨立的文檔,不要被合成進去.
但我們知道,有--save 的部分,
也就是,我最終的代碼當中,有依賴其他一些包,
也就是那個什么node_modules中的包
這些包應(yīng)該也要根據(jù)情況分包.

根據(jù)昨天學(xué)的知識, 我接觸的分包有以下幾種,
第一種是 loader
img 文件, 用 url-loader 設(shè)置 limit, name
第二種是plugin
html-webpack-plugin 獨立生成html 包
mini-css-extract-plugin 獨立生成 css 包 似乎會把所有scss css 文件都打包成一個?
怎么對 js 文件進行分包沒接觸,
也就是,如果有多個入口文件, 就對應(yīng)生成對個出口文件?

作為一個小白沒什么經(jīng)驗的我來講,以上就是我僅有的理解了.

現(xiàn)在,我們重新看一下上面的 分包博客

影響理解的詞匯,概念
chunk : 代碼塊
on-demand 按需加載
初始代碼塊 : 什么是初始代碼塊?
百度搜索出另一篇博客
深入 webpack 打包機制的介紹
這是從webpack 各個版本進化的角度講的,沒能完全看懂,但很牛逼.

//  這個代碼的含義是，在這些入口文件中，找到那些 ***引用兩次的模塊*** 
//(如：utilB)订晌， 那么 utilB 會抽離成一個叫 vendor 文件。此時那部分初始化工作的代碼會被抽離到 vendor 文件中蚌吸。
new webpack.optimize.CommonsChunkPlugin({
// 最后生成的文件名?  
name: "vendor",
// 被引用的次數(shù)?
  minChunks: 2
});

// 這段代碼的含義是在 vendor 文件中幫我把初始化代碼抽離到 mainfest 文件中锈拨，
//此時 vendor 文件中就只剩下 utilB 這個模塊了，那么我們?yōu)槭裁葱枰@么做呢羹唠？你可能會有這樣的問題
new webpack.optimize.CommonsChunkPlugin({
// 生成的文件名?
  name: "manifest",
// 選擇哪個代碼塊
  chunks: ["vendor"]
// 被重復(fù)引用的次數(shù)為無限?
  // minChunks: Infinity 可寫可不寫
});

獨立分割一些不常變動的,有利于緩存?
什么是 長期緩存策略?

看一下這一段話

webpack根據(jù)下述條件自動進行代碼塊分割：

1. 新代碼塊可以被共享引用奕枢，OR這些模塊都是來自node_modules文件夾里面
2. 新代碼塊大于30kb（min+gziped之前的體積）
3. 按需加載的代碼塊，最大數(shù)量應(yīng)該小于或者等于5
4. 初始加載的代碼塊佩微，最大數(shù)量應(yīng)該小于或等于3
   為了滿足后面兩個條件缝彬，webpack有可能受限于包的最大數(shù)量值，生成的代碼體積往上增加哺眯。

理解:

1. 只要是 node_modules里的文件就 分割成獨立包
2. 只要是被不同代碼多次共享, 就分割成獨立包
3. 只要是 被加載的代碼塊 過大(大于 30kb) 就分割成獨立包.
   前三個好理解
4. 按需加載的代碼塊, 最大數(shù)量 <= 5 時, 分割成獨立包?
   指的是按需加載的代碼塊的數(shù)量嘛?
   按需加載的代碼塊,指的是異步加載的代碼塊?
   5.初始加載的代碼塊的數(shù)量 <= 3?
   什么是初始加載的代碼塊? 同步加載的?

(這就是強烈需要一個老師的時候,對這個作者來講,這個概念,以及指向什么東西
是非常明顯的,可到了我這,就要費很多時間要去猜,好浪費,好心疼)

我們看一下他舉的兩個例子

// entry.js
import("./a");
// a.js
import "react-dom";

他說

結(jié)果：webpack會創(chuàng)建一個包含react-dom的分離代碼塊谷浅。當import調(diào)用時候，這個代碼塊就會與./a代碼被并行加載奶卓。

為什么會這樣打包：

條件1：這個代碼塊是從node_modules來的
條件2：react-dom大于30kb
條件3：按需請求的數(shù)量是2（小于5）
條件4：不會影響初始代碼請求數(shù)量

條件1.條件2 聽懂了, 條件3 按需請求的數(shù)量是2 是個什么鬼?
這個2是怎么來的?
現(xiàn)在的假設(shè)是這樣的,
入口文件是一個包,
react-dom 也是一個包,
這倆并非直接依賴, 所以算是異步依賴,
并行的數(shù)量是 2, 所以是2?

條件4 的不會影響初始代碼請求數(shù)量又是 什么鬼?
現(xiàn)在的假設(shè)是這樣的.
初始代碼,也就是入口文件 依賴的是 a.js
但a.js 并不會被獨立分包, 也就說, 入口文件
依賴的包當中 被獨立分包的個數(shù).

什么是初始代碼塊?
inital chunks,,沒百度出來.
我只能假設(shè)為,一個入口文件就是一個初始代碼塊,
盡管他引入了幾個代碼塊, 但初始代碼塊只有一個? 所以沒有影響?
如果這也是和條件3一樣類型的限制條件,
那么有就是存在這種可能,
如果滿足條件1和條件2 進行了分包, 就有可能會增加初始代碼的請求數(shù)量?
但到底怎樣的分包情形才會出現(xiàn)這種情況呢?

繼續(xù)讀博客,

有四個選項可以用于配置這些條件：

1. minSize(默認是30000)：形成一個新代碼塊最小的體積
2. minChunks（默認是1）：在分割之前一疯，這個代碼塊最小應(yīng)該被引用的次數(shù)（譯注：保 證代碼塊復(fù)用性，默認配置的策略是不需要多次引用也可以被分割）
3. maxInitialRequests（默認是3）：一個入口最大的并行請求數(shù)
4. maxAsyncRequests（默認是5）：按需加載時候最大的并行請求數(shù)夺姑。

咦? 你發(fā)現(xiàn)這幾個參數(shù)和 上面的四個條件是一一對應(yīng)的.
minSize = 30000 對應(yīng)的是 超過30k 就分包
minChunks = 2 如果被引用次數(shù) 超過 2次就 分包?
maxIntialRequesets = 3 入口最大的并行請求數(shù)?
總算找到了 關(guān)鍵詞, 果斷搜索

webpack optimization 里的 maxInitialRequests 配置項是啥意思墩邀？

如果配置了 runtimeChunk（將webpack runtime單獨抽離出來），那么maxInitialRequest就是代碼分割以后盏浙，除去runtime所能生成的最多腳本數(shù)目

否則是就是能生成的最多腳本數(shù)目

splitChunks: {

chunks 有三個值, "all","initial","async"
 文檔說 all 的時候 async 塊和 non-async 塊 可以共享代碼塊,
 inital 應(yīng)該是指 入口文件 相關(guān)的 non-async塊,也就是同步加載的代碼塊.
 async 應(yīng)該是指 異步加載的代碼塊.
    chunks: "async",

大小超過30000 時分包
    minSize: 30000,

 最少被引入的次數(shù).
    minChunks: 1,

 谷歌翻譯是: 按需加載時的最大并行請求數(shù)眉睹。
 我覺得應(yīng)該是指, 不是入口文件直接引入的文件,
被分包的個數(shù)要小于5個 , (5 個當中 應(yīng)該算上 入口文件?)
    maxAsyncRequests: 5,

 谷歌翻譯是: 入口點處的最大并行請求數(shù)荔茬。
我覺得應(yīng)該是指, 入口文件直接引入的文件中,
被分包的個數(shù)要小于3個,
如果大于3個就不進行分包.
    maxInitialRequests: 3,

實際上,上面這兩個屬性這么解釋的話,
似乎和以前學(xué)習(xí)的異步加載的概念對不上..
異步應(yīng)該只的是 import.aysnc,import.then,require(a.js",function(){})

 name 為 true 時,自動生成名字?
    name: true,

 cacheGroups:緩存組// 上面這幾個屬性會默認作用在下面,或者緩存組也可以單獨設(shè)置上面的選項
    cacheGroups: {

 default 緩存組是, 只要被 引用兩次或兩次以上的代碼
        default: {

 最少被重復(fù)引用的次數(shù)為2
            minChunks: 2,

 優(yōu)先級, 優(yōu)先級越高, 表示 優(yōu)先進行打包.
            priority: -20,

表示, 有同樣的包 再次遇到時,不會產(chǎn)生新的包, 而是引入已經(jīng)有打包的包?
            reuseExistingChunk: true,
        },

node_modules 里引入的包,默認會放進verdors,默認分包,
        vendors: {
            test: /[\\/]node_modules[\\/]/,
            priority: -10
        }
    }

SplitChunksPlugin
哎呀媽呀,搜索不出來, 搜出英文文檔的頁面.
話說,這個倒是真的全,看來以后真的要多接觸英文文檔了.
反正有谷歌網(wǎng)頁翻譯.還是接觸第一手資料比較有效率.

webpack4——SplitChunksPlugin使用指南
這位大神總結(jié)的也很清晰啊.
不過看了這么文章, 大概的概念都了解了,
就是那兩個 ，按需加載最大請求次數(shù),初始化加載最大請求次數(shù)
到底是個什么鬼還是不確定,不清晰.

果然尼瑪,我的假設(shè)是錯的,
看另一個大神
Webpack4之SplitChunksPlugin規(guī)則
這位大神也是對這兩個概念產(chǎn)生疑問, 然后進行了測試,結(jié)論是

之前我認為是webpack根據(jù)代碼結(jié)構(gòu)自行分割(split)竹海，后來發(fā)現(xiàn)并非如此慕蔚，這其實涉及到代碼中動態(tài)加載(on demand loading)組件的概念

可見業(yè)務(wù)2相關(guān)的代碼由webpack4生成的runtime chunk來需要的時候動態(tài)引入
(這里明白一件事情,想要完成動態(tài)加載,就必須有 runtime chunk)
(所謂的動態(tài)引入就是按需加載,就是最終按需異步加載的部分.)

maxAsyncRequests（最大的異步請求數(shù)）和maxInitialRequests（最大的初始請求數(shù)是為了防止chunk劃分的過于細致，導(dǎo)致大量的文件請求降低performance)站削。

還從上一次分包情況入手分析：vendors-index和vendors-main都是來自node_moudules坊萝。那么當前按需加載的代碼塊的并行請求數(shù)就是2孵稽。
(這里就不太明白了,為什么都來自node_modules的文件就會被判定是按需加載的代碼塊?不對吧?)

設(shè)置maxAsyncRequests=1 可以看到许起，index和main還在，但是verdors只剩下了vendors~main chunk菩鲜≡跋福可見按需加載(chunks on demand)的代碼塊指的就是vendors~chunk
(這里保留意見, 按需加載的代碼塊指的可能不是 venders~chunk, 而是runtime.js?
又或者是 入口文件本身?)

maxInitialRequests 指的是模版html文件中，并行請求的javascript(不包括runtime)的數(shù)量接校。
(我上面的猜測少了這個runtime ,整個圖譜缺了一塊,自然想不明白)

--
maxInitialRequests 是 最后在index.html文件中猛频，除了 runtime.js
之外引入的 <script> 的數(shù)量。

maxAsyncRequests 是 指 不是 <script> 引入的方式蛛勉，而是異步加載鹿寻，
也就是按需加載的方式 引入的 js 的數(shù)量。

默認 chunk ： aysnc 的意思是诽凌，
默認 入口文件是不會被合并的毡熏。設(shè)置了幾個入口文件，
就會對應(yīng)聲稱幾個出口文件侣诵，
但chunk ： all （initial）之后痢法，
如果 maxInitialRequests 的數(shù)量如果比較小，
入口文件就會被合并杜顺。
而且财搁，似乎會把不同入口文件相同的部分也會獨立分包。
總之總算是入門了的感覺躬络。
花了將近5天尖奔。
其實內(nèi)心我總想跳過這部分，
因為只要經(jīng)常用必然會的穷当，又沒有什么太大的邏輯越锈。
其次，以我現(xiàn)在剛學(xué)js的小白來講膘滨，日常學(xué)習(xí)寫代碼甘凭，基本用不上webpack
不過因為之前用了一天大概學(xué)了一下webpack,
當時就是這么略過去的，
結(jié)果事后除了最基本的操作之外火邓，一無所知丹弱，手足無措德撬。
這次的學(xué)習(xí)，更大的目的是為了下回遇到webpack的時候躲胳，
不要感覺陌生就可以了蜓洪。

其實只要知道為什么分包, 理解分包的需求和思路,
以及明白各種選項的具體含義,就可以了.
今天之所以這么墨跡,就是因為各種概念總是不清楚.
哎,,也不知道今天的所學(xué),所付出的時間精力與獲得成不成正比？
美中不足的是, 今天只是看了一堆博客,了解了概念,
還沒有正式上手練習(xí),天色已晚,明天再說吧.

回顧一下babel