最近粗略阅读了一下Webpack的源码，对其打包的流程有了一定的了解，接下来结合源码，和大家分享一下webpack的打包流程；同时在文章最后，会有一个简易的Webpack的实现，提供大家参考和学习~

Webpack 是一个用于现代 JavaScript 应用程序的静态模块打包工具。它将你项目中所需的每一个模块组合成一个或多个bundles，用于在浏览器使用

PS：本次分享阅读的是webpack4的源码，当前最新的webpack5^[1]对比4版本有很多升级和调整，但是大体的流程差别不大，提供给大家学习其主要的流程没太大问题

整体构建流程

我们先来了解一下Webpack整体大致的一个构建流程，Webpack 的运行流程是一个串行的过程，从启动到结束会依次执行以下流程：

概念介绍

在细节地介绍流程前，有一些相关概念需要提前说明一下：

Module

Webpack官网是这么解释module（模块）的：

在模块化编程中，开发者将程序分解为功能离散的 chunk，并称之为 模块。每个模块都拥有小于完整程序的体积，使得验证、调试及测试变得轻而易举。精心编写的 模块 提供了可靠的抽象和封装界限，使得应用程序中每个模块都具备了条理清晰的设计和明确的目的。

通俗来说，module 即每一个资源文件的模块对应，如js / css / 图片等，由NormalModule实例化而来，存在compilations.modules中；它可以理解为是源文件到chunk的一个中间态，便于编译过程中进行各种操作。

Chunk & ChunkGroup

chunk 即每一个输出文件的对应，包括入口文件，异步加载文件，优化切割后的文件等等；它可以包含多个module；存于 compilation.chunks；chunkGroup 可以包含多个 chunk（入口 chunk 或异步模块的 chunk）。entrypoint 就是一个 chunkGroup，里包含入口 chunk。存于 compilation.chunkGroups。

Loader

Webpack 本身只能处理 JavaScript 模块，如果要处理其他类型的文件，就需要使用 loader 进行转换。Loader 是导出为一个函数的 node 模块。该函数在 loader 转换资源的时候调用，它接受源文件作为参数，返回转换的结果。这样，我们就可以通过 require 来加载任何类型的模块或文件，比如 CoffeeScript、 JSX、 LESS 或图片。

module.exports = function (source) { 
    // ... 对source做处理 
     
    return newSource; 
}; 

Plugins

即插件，它是可插拔的模块，可以完成更多编译过程中 loader 不能完成的功能。这里我们要先介绍一下Plugin依赖的另外一个库——Tapable^[2]，它简单来说就是一个发布-订阅模式的实现。它提供了很多类型的钩子类（如同步、异步、并行、熔断等），他们可以tap（订阅）若干个回调函数，在call（发布）的时候，将订阅的回调函数以对应的方式执行。举个例子🌰：

const tapable = require("tapable"); 
 
const { SyncHook } = tapable; 
 
const hook = new SyncHook(); 
 
hook.tap("MyHook", () => { console.log("enter MyHook") }); 
hook.tap("MyHook2", () => { console.log("enter MyHook2") }); 
 
hook.call(); // enter MyHook   enter MyHook2 

webpack的Plugin是与上述的Tapable强耦合的，我们可以参照下面一个plugin的简单实现来了解一下：

class MyPlugin { 
  apply(compiler) { 
    compiler.hooks.make.tap("MyPlugin", (compilation) => { 
      // ... 
      compilation.hooks.optimizeChunkAssets.tap("MyPlugin", (chunks) => { 
        // ... 
      } 
    } 
  } 
} 

结合上述代码我们可以注意到：

• plugin必须在原型上定义一个apply方法，并接受了一个compiler实例作为参数。
• apply方法会在初始化插件时被调用，此时我们可以对compiler、compilation上的hooks做订阅，等编译流程执行到了我们监听的时机，就会调用订阅的回调函数，来对编译的过程做一些对应操作。

Webpack 会在特定的时间点（编译周期钩子）发布特定的事件，插件在监听到对应事件后会执行特定的逻辑，并且插件可以调用 Webpack 提供的 API 改变 Webpack 的运行结果

Compiler

Compiler 对象包含了当前运行Webpack的配置，包括entry、output、loaders等配置，这个对象在启动Webpack时被实例化，而且是全局唯一的。Plugin可以通过该对象获取到Webpack的配置信息进行处理、以及监听compiler的hooks从而做进一步的处理。如下：

class Compiler extends Tapable { 
    constructor(context){ 
        // ... 
        this.options = {}, 
        this.hooks = { 
              run: new AsyncSeriesHook(["compiler"]), 
              compile: new SyncHook(["params"]), 
              make: new AsyncParallelHook(["compilation"]), 
              // ... 
        } 
    } 
} 

Compilation

Compilation对象代表了一次资源版本构建。每次构建过程都会产生一次 Compilation，比如我们启动 watch 功能的时候，每当检测到一个文件变化，就会重新创建一个新的 Compilation，从而生成一组新的编译资源 一个 Compilation 对象表现了当前的模块资源、编译生成资源、变化的文件、以及被跟踪依赖的状态信息。Compilation 模块会被 Compiler 用来创建新的编译（或新的构建）。compilation 实例能够访问所有的模块和它们的依赖（大部分是循环依赖）。它会对应用程序的依赖图中所有模块进行字面上的编译(literal compilation)。在编译阶段，模块会被加载(loaded)、封存(sealed)、优化(optimized)、分块(chunked)、哈希(hashed)和重新创建(restored)。Compilation 对象也提供了插件需要自定义功能的回调，以供插件做自定义处理时选择使用拓展。简单来说，Compilation的职责就是构建模块和Chunk，并利用插件优化构建过程。

总结来说，以上概念的关系可以通过下面的流程图来更好地get到：每个文件可以被创建为一个module，若干个module可以解析编译组成一个chunk，入口+异步chunk可以组成一个chunkGroup。

构建流程细化

接下来我们结合流程图和代码，了解一下初始化、编译、输出三个大的步骤中的一些细节

初始化

我们使用webpack进行打包代码时，一般会命令行的指令 ./node_modules/bin/webpack ，实际上对应执行的文件是 node_modules/webpack/bin/webpack.js ，它即webpack的入口文件，我们从入口文件开始分析：首先，获取到当前已安装的cli；并将cli作为执行入口，如webpack-cli。

webpack4会判断安装了两种中任意一种即可；在webpack5版本只支持webpack-cli作为cli工具

// bin/webpack.js 
#!/usr/bin/env node 
 
const installedClis = CLIs.filter(cli => cli.installed); 
 
// 过滤出安装了的cli 
if (installedClis.length === 0) { 
  // ... 没有安装cli，提示用户安装webpack的cli 
} else if (installedClis.length === 1) { 
  const path = require("path"); 
  const pkgPath = require.resolve(`${installedClis[0].package}/package.json`); 
  const pkg = require(pkgPath); 
   
  // 实际上是require('webpack-cli')，即webpack-cli才是webpack真正执行的入口 
  require(path.resolve( 
    path.dirname(pkgPath), 
    pkg.bin[installedClis[0].binName] 
  )); 
} else { 
  // .. 安装了多个cli会warning，并退出 
   
  // * 在webpack5中只支持使用webpack-cli 
} 

我们转到webpack-cli这个包，通过其package.json可以发现执行入口为 ./bin/cli.js ， 我们来了解一下cli.js做了哪些处理：

• 首先会通过一个NON_COMPILATION_CMD的常量数组判断当前命令是否需要编译，如果不需要，则通过./utils/prompt-command来处理这个命令；
• 如果需要进入编译流程，则会通过./utils/convert-argv来将webpack.config.js和命令行中的参数合并为options；
• 接着引入webpack包，并通过上一步得到的options作为参数，初始化出一个全局唯一的compiler实例；
• 判断编译类型，如果是非watch模式（watch模式的情况不在本文讨论，有兴趣的小伙伴可自行查阅相关资料~），就直接调用compiler.run方法，开始正式的编译阶段。

// webpack-cli/bin/cli.js 
 
// NON_COMPILATION_ARGS指定不需要编译的指令； 
// 如init，执行webpack init来初始化一份webpack配置 
const NON_COMPILATION_CMD = process.argv.find(arg => { 
  return NON_COMPILATION_ARGS.find(a => a === arg); 
}); 
// 如果是不需要执行编译的指令，就会require对应的包并执行 
if (NON_COMPILATION_CMD) { 
  //  
  return require("./utils/prompt-command")(NON_COMPILATION_CMD, ...process.argv); 
} 
 
// Yargs通过解析参数来帮助构建脚手架的工具 
yargs.parse(process.argv.slice(2), (err, argv, output) => { 
    let options; 
    // 解析配置文件和命令行参数得到最终的options（webpack.config & 命令行的参数配置） 
    // 同时会根据部分参数自动加载对应插件 
    options = require("./utils/convert-argv")(argv); 
 
    // 将得到的options用于实例化compiler，并启动编译 
    function processOptions(options) { 
        // 处理options为Promise的情况 
        if (typeof options.then === "function") { 
            options.then(processOptions); 
            return; 
        } 
 
        // ... 对outputOptions进行一些设置 
         
        // 通过options实例化全局唯一的compiler对象 
        const webpack = require("webpack");  // lib/webpack.js 
        compiler = webpack(options); 
         
        // ... 判断插件的启用和tap一些事件 
 
        // 最后针对配置是否是watch监听模式，分别执行对应操作 
        if (firstOptions.watch || options.watch) { 
            // ... watch 
        } else { 
            compiler.run(...) 
        } 
    } 
     
    processOptions(options); 
})) 

PS：流程图中向下的箭头表示当前主流程的操作，向右的箭头一般表示当前大步骤的子步骤

那么上一步在调用webpack(options)时做了什么呢，是如何实例化出compiler呢？我们接下来进到其对应的 webpack/lib/webpack.js文件来了解一下：

• 首先判断options是否是数组，如果是数组的话，会将其每一项当做一个构建目标，并调用MultiCompiler来实例化compiler；

This is useful for bundling a library for multiple targets such as AMD and CommonJS

• 如果option是通常的对象，首先会通过WebpackOptionsDefaulter类添加大量默认参数给options，得到最终的options；
• 然后通过上一步得到的options来实例化全局唯一的compiler；
• 遍历options配置的plugins，调用其apply方法，初始化配置的插件；
• 最后通过WebpackOptionsApply类，将配置的options转化为插件并启用（如mode为production模式下默认开启的UglifyJSPlugin插件，无需用户配置）；

// webpack/lib/webpack.js 
 
const webpack = (options, callback) => { 
  let compiler; 
  // 多个配置的情况: https://webpack.js.org/configuration/configuration-types/#exporting-multiple-configurations 
  if (Array.isArray(options)) { 
    compiler = new MultiCompiler( 
      Array.from(options).map(options => webpack(options)) 
    ); 
  } else if (typeof options === "object") { 
    // WebpackOptionsDefaulter 对options配置对象添加了大量的默认参数 
    options = new WebpackOptionsDefaulter().process(options); 
     
    // 实例化单个option对应的全局唯一的compiler 
    compiler = new Compiler(options.context); 
    compiler.options = options; 
     
    // 启用options中配置的默认插件 
    if (options.plugins && Array.isArray(options.plugins)) { 
      for (const plugin of options.plugins) { 
        if (typeof plugin === "function") { 
          plugin.call(compiler, compiler); 
        } else { 
          plugin.apply(compiler); 
        } 
      } 
    } 
     
    // WebpackOptionsApply 主要就是将配置的options转化为插件，以及启用一些默认插件 
    compiler.options = new WebpackOptionsApply().process(options, compiler); 
  }  
   
  return compiler; 
}; 
 
// 兼容esmodule和commonjs 
exports = module.exports = webpack; 

总的来说，初始化的过程大致为：

• 初始化options参数；
• 实例化Compiler对象；
• 初始化默认的和配置的插件；
• 调用compiler的run方法开始编译

编译

调用compiler.run之后，正式进入编译阶段；该阶段核心步骤：

• 进入compile 函数，实例化compilation；
• 执行关键的make钩子，即开始执行真正的编译，这里会调用loader对代码解析，递归模块的依赖解析等；
• 结束后进入compilation的seal，这个阶段会创建chunk，并且有非常多用于处理优化的hooks；

我们来了解一下run方法里是如何进行编译的：

• 首先，经过了beforeRun、run的钩子后，进入compile方法；
• 在compile中经过beforeCompile、compile钩子后，来到真正执行编译的钩子——make；

// webpack/lib/compiler.js 
 
run() { 
    const onCompiled = (err, compilation) => { 
      this.emitAssets(compilation, err => { 
        this.emitRecords(err => { 
          this.hooks.done.callAsync(stats, err => { 
            return finalCallback(null, stats); // stats为计算编译的时间 
          }); 
        }); 
      }); 
    }; 
 
    this.hooks.beforeRun.callAsync(this, err => { 
      this.hooks.run.callAsync(this, err => { 
        this.readRecords(err => { 
          this.compile(onCompiled); 
        }); 
      }); 
    }); 
} 
 
compile(callback) { 
    const params = this.newCompilationParams(); 
    this.hooks.beforeCompile.callAsync(params, err => { 
      this.hooks.compile.call(params); 
      // 实例化一个compilation对象 
      const compilation = this.newCompilation(params); 
      // * make hook，真正开始编译 
      this.hooks.make.callAsync(compilation, err => { 
        compilation.finish(err => { 
          // seal阶段 
          compilation.seal(err => { 
            this.hooks.afterCompile.callAsync(compilation, err => { 
              return callback(null, compilation); 
            }); 
          }); 
        }); 
      }); 
    }); 
  } 
} 

• 要知道在make阶段做了什么，我们可以全局搜索一下hooks.make.tapAsync，来查询订阅了make的相关插件，其中包括了SingleEntryPlugin、MultiEntryPlugin、DynamicEntryPlugin等；
• 我们以SingleEntryPlugin作为例子进行分析：在插件的apply方法中，将入口信息、上下文环境等作为参数，调用addEntry方法，从入口开始编译；

// SingleEntryPlugin.js 
 
apply(compiler) { 
    // make 
    compiler.hooks.make.tapAsync( 
      "SingleEntryPlugin", 
      (compilation, callback) => { 
        const { entry, name, context } = this; 
        const dep = SingleEntryPlugin.createDependency(entry, name); 
        compilation.addEntry(context, dep, name, callback); 
      } 
    ); 
} 

• 在addEntry中，调用了_addModuleChain将整个module链中的所有模块都处理完成，其流程如下：
• 根据依赖的类型获取对应模块工厂moduleFactory；
• 调用moduleFactory的create方法，创建模块module；
• 调用buildModule方法，其核心是使用loaders和parser解析module；
• 解析完成回到create的回调中，继续分析该模块的依赖项，并递归解析处理其依赖项；
• 处理结束后，回到make的回调中，执行compilation.finish，准备进入seal阶段

// Compliation.js 
 
addEntry(context, entry, name, callback) { 
    this.hooks.addEntry.call(entry, name); 
     
    this._addModuleChain( 
      context, 
      entry, 
      module => this.entries.push(module), 
      (err, module) => { 
        this.hooks.succeedEntry.call(entry, name, module); 
        return callback(null, module); 
      } 
    ); 
} 
 
_addModuleChain(context, dependency, onModule, callback) { 
    const Dep = /** @type {DepConstructor} */ (dependency.constructor); 
    // 根据依赖的类型获取对应的模块工厂，用于创建模块 
    const moduleFactory = this.dependencyFactories.get(Dep); 
 
    // semaphore主要是限制同时处理的模块数量，默认值是100 
    this.semaphore.acquire(() => { 
        // * 使用模块工厂创建模块；JS等模块会使用NormalModuleFactory来创建模块对象 
        moduleFactory.create( 
        {/* params*/}, 
        (err, module) => { 
          // 添加到this.modules中 
          const addModuleResult = this.addModule(module); 
          onModule(module); // this.entries.push(module); 
         
          // module已经build完了，依赖也收集好了，开始处理依赖的module 
          const afterBuild = () => { 
            if (addModuleResult.dependencies) { 
              this.processModuleDependencies(module, err => { 
                callback(null, module); 
              }); 
            } else { 
              return callback(null, module); 
            } 
          }; 
         
          // 如果已经build过的模块，build为false 
          if (addModuleResult.build) { 
            /* 
                调用module.build开始构建模块 
                调用loader处理源文件，使用acorn生成AST， 
                将遍历AST,遇到require等依赖时，创建依赖(Dependency)加入依赖数组 
            */ 
            this.buildModule(module, false, null, null, err => { 
              afterBuild(); 
            }); 
          } 
        ); 
      } 
  } 
   
buildModule(module, optional, origin, dependencies, thisCallback) { 
    // 针对多个文件引用同一个依赖的情况，若已build并缓存，就不重复build 
    let callbackList = this._buildingModules.get(module); 
    if (callbackList) { 
      callbackList.push(thisCallback); 
      return; 
    }     
    // set cache map 
    this._buildingModules.set(module, (callbackList = [thisCallback])); 
     
    this.hooks.buildModule.call(module); 
     
    // build阶段主要就是调用loaders和parser进行解析 
    module.build( 
      // ... params 
      error => { 
        module.dependencies.sort(...); 
        this.hooks.succeedModule.call(module); 
        return callback(); 
      } 
    ); 
} 

这里我们先深入一下_module_.build方法，了解一下内部的一些核心处理流程。以NormalModule为例：

• 调用this.doBuild方法，其中主要是调用了runLoaders，执行配置的loader来解析module；
• 经过loader的解析后，得到可被js继续解析的source，此时将其交给Paser，解析为AST（依赖acron库），并遍历AST，查找Inport、require等语句，即当前模块的依赖项；

在线AST解析：https://astexplorer.net/^[3]

• 上一步结束后，会回到_addModuleChain的afterBuild回调中，并执行processModuleDependencies，递归该模块的依赖项，并对这些依赖项执行之前同样的创建模块、runLoaders、Parser解析的流程，直到解析完所有依赖项。

下面贴了一些相关代码，只保留了一些重点步骤，方便了解和阅读，有兴趣的同学可以对照源码深入了解其各实现细节。

// NormalModule.js 
 
build(options, compilation, resolver, fs, callback) { 
    // ... 设置this的一些值 
     
    return this.doBuild(options, compilation, resolver, fs, err => { 
      this._cachedSources.clear(); 
 
      const handleParseResult = result => { 
        this._initBuildHash(compilation); 
        return callback(); 
      }; 
 
        // 将经过loader处理的代码，通过parser处理转为AST，并找出依赖模块，得到最终结果 
        // 然后返回到Compilation.js的buildModule方法中，调用processModuleDependencies方法递归处理该模块依赖的模块 
        // 其callback即回到compilation.finish 
        const result = this.parser.parse( 
            this._ast || this._source.source(), 
            // ... params 
        ); 
         
        if (result !== undefined) { 
          handleParseResult(result); 
        } 
    }); 
} 
 
doBuild(options, compilation, resolver, fs, callback) { 
    const loaderContext = this.createLoaderContext(/*...*/); 
 
    runLoaders( 
      {/* param */}, 
      (err, result) => { 
        if (result) { 🐞 
          this.buildInfo.cacheable = result.cacheable; 
          this.buildInfo.fileDependencies = new Set(result.fileDependencies); 
          this.buildInfo.contextDependencies = new Set(result.contextDependencies); 
        } 
 
        // loader处理后返回的结果: 0 - result;1 - sourceMap;2 - extra 
        const source = result.result[0]; 
        const sourceMap = result.result.length >= 1 ? result.result[1] : null; 
        const extraInfo = result.result.length >= 2 ? result.result[2] : null; 
 
        // 将loader的处理结果转化为字符串的source 
        this._source = this.createSource( 
          this.binary ? asBuffer(source) : asString(source), 
          result.resourceBuffer, 
          sourceMap 
        ); 
 
        return callback(); 
      } 
    ); 
  } 

// loader-runner 
 
runLoaders(options, callback){ 
    // 设置loaderContext 
    loaderContext.xxx = xxx; 
    Object.defineProperty(loaderContext, 'xxx', {...}) 
    // 执行 
    iteratePitchingLoaders(processOptions, loaderContetxt, function(err, res){ 
        // ... 
    }) 
} 
 
iteratePitchingLoaders(options, loaderContext, callback) {     
    // 加载loader，并执行 
    loadLoader(currentLoaderObject, function(err)){ 
        // 取到loader函数 
        var fn = currentLoaderObject.pitch; 
        // 执行loader来处理文件，并在回调中继续递归执行iteratePitchingLoaders 
        runSyncOrAsync(fn, loaderContext, args, errCallback); 
    } 
} 

// Parser.parse 
 
parse(source, initialState) { // source，即源代码的字符串 
    let ast; 
    if (typeof source === "object" && source !== null) { 
        ast = source; 
    } else { 
        // 主要就是通过调用acron的parse方法来解析成AST 
        ast = Parser.parse(source, { sourceType: this.sourceType, onComment: comments }); 
    } 
     
    // 触发回调 plugin(HarmonyDetectionParserPlugin 和 UseStrictPlugin) 根据是否有 import/export 和 use strict 增加依赖：HarmonyCompatibilityDependency, HarmonyInitDependency，ConstDependency 
    if (this.hooks.program.call(ast, comments) === undefined) { 
        // 检测严格模式 
        this.detectMode(ast.body); 
        // 递归遍历语句，处理import、export等导入导出的相关依赖 
        this.prewalkStatements(ast.body); 
        // 处理块遍历 
        this.blockPrewalkStatements(ast.body); 
        // 用于深入函数内部（方法在 walkFunctionDeclaration 进行递归），然后递归继续查找 ast 上的依赖，异步此处深入会增加依赖 ImportDependenciesBlock; 
        this.walkStatements(ast.body); 
    } 
} 

• make阶段结束，将会在其回调中调用compilation.seal进入seal阶段，根据编译好的module创建chunk。其主要的逻辑：
• 根据entry生成chunk图；
• 生成构建hash；
• 生成chunk对应的资源，保存在compilation.assets中；

另外seal阶段有很大部分代码是调用性能优化相关的内置插件；

// Compilation.js 
 
seal(callback) { 
  this.hooks.seal.call(); 
 
  this.hooks.beforeChunks.call(); 
 
  // 遍历入口，生成入口的chunk，并将所有module、chunk、chunkGroup之间建立联系 
  for (const preparedEntrypoint of this._preparedEntrypoints) { 
    const chunk = this.addChunk(name); 
    const entrypoint = new Entrypoint(name); 
    this.chunkGroups.push(entrypoint); 
    GraphHelpers.connectChunkGroupAndChunk(entrypoint, chunk); 
    GraphHelpers.connectChunkAndModule(chunk, module); 
    this.assignDepth(module); 
  } 
   
  // 生成并优化 chunk 依赖图，建立起各模块之前的关系 
  buildChunkGraph( 
    this, 
    /** @type {Entrypoint[]} */ (this.chunkGroups.slice()) 
  ); 
 
  this.sortModules(this.modules); 
   
  this.hooks.optimizeTree.callAsync(this.chunks, this.modules, err => { 
 
    this.applyModuleIds(); 
    this.sortItemsWithModuleIds(); 
 
    this.applyChunkIds(); 
    this.sortItemsWithChunkIds(); 
 
    // 生成这次构建的Hash，可通过webpack.config的[hash]占位符配置 
    this.createHash(); 
     
    this.createModuleAssets(); 
     
    if (this.hooks.shouldGenerateChunkAssets.call() !== false) { 
      this.hooks.beforeChunkAssets.call(); 
      // 通过chunk的类型(enrty/动态引入)，使用对应模板生成源码 
      // 生成后调用emitAsset方法将其保存到assets属性中，即最终要生成的文件列表 
      this.createChunkAssets(); 
    } 
 
    this.summarizeDependencies(); 
  }); 
} 

编译阶段简单总结下来就是：

• 实例化compilation；
• 执行make hook的回调，递归解析module；
• 根据编译好的module创建chunk，并生成对应的资源模块，准备输出；

输出

输出部分，主要是在上一步seal阶段的回调中，进到Complier.emitAssets方法，将seal过程中处理好的资源生成具体的文件。

// Compiler.js 
 
emitAssets(compilation, callback) { 
    const emitFiles = () => { 
      asyncLib.forEachLimit( 
        compilation.getAssets(), 
        15, 
        ({ name: file, source }, callback) => { 
            // 写入文件 
            this.outputFileSystem.writeFile(targetPath, content);             
        } 
    } 
     
    // 递归创建输出目录 
    this.outputFileSystem.mkdirp(outputPath, emitFiles); 
} 

先使用outputFileSystem.mkdirp 创建文件夹，之后执行回调 emitFiles，在回调里通过 asyncLib.forEachLimit 并行执行对每个 file 资源文件进行路径拼接后，将每个 source 源码写入真实路径的 file。至此整个构建流程就基本结束了~

Webpack的构建流程总结

1. 初始化参数：从配置文件和 Shell 语句中读取与合并参数，得出最终的参数；
2. 开始编译：用上一步得到的参数初始化 Compiler 对象，加载所有配置的插件，执行对象的 run 方法开始执行编译；
3. 确定入口：根据配置中的 entry 找出所有的入口文件；
4. 编译模块：从入口文件出发，调用所有配置的 Loader 对模块进行翻译，再找出该模块依赖的模块，再递归本步骤直到所有入口依赖的文件都经过了本步骤的处理；
5. 完成模块编译：在经过第4步使用 Loader 翻译完所有模块后，得到了每个模块被翻译后的最终内容以及它们之间的依赖关系；
6. 输出资源：根据入口和模块之间的依赖关系，组装成一个个包含多个模块的 Chunk，再把每个 Chunk 转换成一个单独的文件加入到输出列表，这步是可以修改输出内容的最后机会；
7. 输出完成：在确定好输出内容后，根据配置确定输出的路径和文件名，把文件内容写入到文件系统。

如何实现一个简易Webpack

实现要点：

• 提供一个类似webpack.config.js的编译配置文件（mywebpack.config.js）
• 实现一个Compiler，用于获取配置(options)、实例化Compilation、运行构建(run)；
• 实现一个Compilation，用于解析文件(run loader)、分析依赖(parse成ast)、生成chunk(seal)；
• 支持以tapable为基础的插件化机制；
• 支持配置loader解析文件；
• 整体流程和webpack编译流程靠拢，大致为：init->run->make->seal->emit ；

实现代码：https://github.com/tangxiaojun1996/mywebpack

webpack打包生成的文件分析：https://github.com/woai3c/Front-end-articles/issues/7

写在最后

以上带领大家结合源码、以及实现的一个简易webpack，对webpack的整体构建流程做了一个大致的了解；其中每个步骤背后实际基本都涉及到非常多的细节，其源码的代码量也较为庞大，有兴趣的小伙伴可以结合本次分享的构建流程，针对其中某些有兴趣的步骤继续深入源码了解和学习~ 😄

PS：文章底部有贴一些链接，有兴趣的同学可以参考参考

参考文章：https://blog.flqin.com/categories/FE-Build/^[4]

https://juejin.cn/team/6943816493473726472/posts^[5]

https://www.zhihu.com/people/fe_korey/posts^[6]

实现一个插件：https://segmentfault.com/a/1190000021214520^[7]

webpack打包流程分析: https://github.com/darrell0904/webpack-doc/blob/master/docs/chapter4/webpack_process.md^[8]

seal封装生成文件核心流程：https://github.com/amandakelake/blog/issues/101 

实现一个简易的webpack：https://juejin.cn/post/6859538537830858759

参考资料