天天看點

說說webpack的建構流程?

作者:鹹魚養成記

webpack 的運作流程是一個串行的過程,它的工作流程就是将各個插件串聯起來

在運作過程中會廣播事件,插件隻需要監聽它所關心的事件,就能加入到這條webpack機制中,去改變webpack的運作,使得整個系統擴充性良好

從啟動到結束會依次執行以下三大步驟:

  • 初始化流程:從配置檔案和 Shell 語句中讀取與合并參數,并初始化需要使用的插件和配置插件等執行環境所需要的參數
  • 編譯建構流程:從 Entry 發出,針對每個 Module 串行調用對應的 Loader 去翻譯檔案内容,再找到該 Module 依賴的 Module,遞歸地進行編譯處理
  • 輸出流程:對編譯後的 Module 組合成 Chunk,把 Chunk 轉換成檔案,輸出到檔案系統

初始化流程

從配置檔案和 Shell 語句中讀取與合并參數,得出最終的參數

配置檔案預設下為webpack.config.js,也或者通過指令的形式指定配置檔案,主要作用是用于激活webpack的附加元件和插件

關于檔案配置内容分析,如下注釋:

var path = require('path');
var node_modules = path.resolve(__dirname, 'node_modules');
var pathToReact = path.resolve(node_modules, 'react/dist/react.min.js');

module.exports = {
  // 入口檔案,是子產品建構的起點,同時每一個入口檔案對應最後生成的一個 chunk。
  entry: './path/to/my/entry/file.js',
  // 檔案路徑指向(可加快打包過程)。
  resolve: {
    alias: {
      'react': pathToReact
    }
  },
  // 生成檔案,是子產品建構的終點,包括輸出檔案與輸出路徑。
  output: {
    path: path.resolve(__dirname, 'build'),
    filename: '[name].js'
  },
  // 這裡配置了處理各子產品的 loader ,包括 css 預處理 loader ,es6 編譯 loader,圖檔處理 loader。
  module: {
    loaders: [
      {
        test: /\.js$/,
        loader: 'babel',
        query: {
          presets: ['es2015', 'react']
        }
      }
    ],
    noParse: [pathToReact]
  },
  // webpack 各插件對象,在 webpack 的事件流中執行對應的方法。
  plugins: [
    new webpack.HotModuleReplacementPlugin()
  ]
};           

webpack 将 webpack.config.js 中的各個配置項拷貝到 options 對象中,并加載使用者配置的 plugins

完成上述步驟之後,則開始初始化Compiler編譯對象,該對象掌控者webpack聲明周期,不執行具體的任務,隻是進行一些排程工作

class Compiler extends Tapable {
    constructor(context) {
        super();
        this.hooks = {
            beforeCompile: new AsyncSeriesHook(["params"]),
            compile: new SyncHook(["params"]),
            afterCompile: new AsyncSeriesHook(["compilation"]),
            make: new AsyncParallelHook(["compilation"]),
            entryOption: new SyncBailHook(["context", "entry"])
            // 定義了很多不同類型的鈎子
        };
        // ...
    }
}

function webpack(options) {
  var compiler = new Compiler();
  ...// 檢查options,若watch字段為true,則開啟watch線程
  return compiler;
}
...           

Compiler 對象繼承自 Tapable,初始化時定義了很多鈎子函數

編譯建構流程

根據配置中的 entry 找出所有的入口檔案

module.exports = {
  entry: './src/file.js'
}           

初始化完成後會調用Compiler的run來真正啟動webpack編譯建構流程,主要流程如下:

  • compile 開始編譯
  • make 從入口點分析子產品及其依賴的子產品,建立這些子產品對象
  • build-module 構模組化塊
  • seal 封裝建構結果
  • emit 把各個chunk輸出到結果檔案

compile 編譯

執行了run方法後,首先會觸發compile,主要是建構一個Compilation對象

該對象是編譯階段的主要執行者,主要會依次下述流程:執行子產品建立、依賴收集、分塊、打包等主要任務的對象

make 編譯子產品

當完成了上述的compilation對象後,就開始從Entry入口檔案開始讀取,主要執行_addModuleChain()函數,如下:

_addModuleChain(context, dependency, onModule, callback) {
   ...
   // 根據依賴查找對應的工廠函數
   const Dep = /** @type {DepConstructor} */ (dependency.constructor);
   const moduleFactory = this.dependencyFactories.get(Dep);
   
   // 調用工廠函數NormalModuleFactory的create來生成一個空的NormalModule對象
   moduleFactory.create({
       dependencies: [dependency]
       ...
   }, (err, module) => {
       ...
       const afterBuild = () => {
        this.processModuleDependencies(module, err => {
         if (err) return callback(err);
         callback(null, module);
           });
    };
       
       this.buildModule(module, false, null, null, err => {
           ...
           afterBuild();
       })
   })
}           

過程如下:

_addModuleChain中接收參數dependency傳入的入口依賴,使用對應的工廠函數NormalModuleFactory.create方法生成一個空的module對象

回調中會把此module存入compilation.modules對象和dependencies.module對象中,由于是入口檔案,也會存入compilation.entries中

随後執行buildModule進入真正的構模組化塊module内容的過程

build module 完成子產品編譯

這裡主要調用配置的loaders,将我們的子產品轉成标準的JS子產品

在用 Loader 對一個子產品轉換完後,使用 acorn 解析轉換後的内容,輸出對應的抽象文法樹(AST),以友善 Webpack 後面對代碼的分析

從配置的入口子產品開始,分析其 AST,當遇到require等導入其它子產品語句時,便将其加入到依賴的子產品清單,同時對新找出的依賴子產品遞歸分析,最終搞清所有子產品的依賴關系

輸出流程

seal 輸出資源

seal方法主要是要生成chunks,對chunks進行一系列的優化操作,并生成要輸出的代碼

webpack 中的 chunk ,可以了解為配置在 entry 中的子產品,或者是動态引入的子產品

根據入口和子產品之間的依賴關系,組裝成一個個包含多個子產品的 Chunk,再把每個 Chunk 轉換成一個單獨的檔案加入到輸出清單

emit 輸出完成

在确定好輸出内容後,根據配置确定輸出的路徑和檔案名

output: {
    path: path.resolve(__dirname, 'build'),
        filename: '[name].js'
}           

在 Compiler 開始生成檔案前,鈎子 emit 會被執行,這是我們修改最終檔案的最後一個機會

進而webpack整個打包過程則結束了