webpack源码-依赖收集

webpack源码-依赖收集

version:3.12.0

程序主要流程:
  • 触发make钩子 Compilation.js
  • 执行EntryOptionPlugin 中注册的make钩子
  • 执行compilation.addEntry
  • 执行compilation._addModuleChain Compilation.js
  • 执行moduleFactory.create(this.semaphore.avaiable 初始化为100) Compilation.js
  • 执行this.buildModule Compilation.js
  • 执行this.processModuleDependencies Compilation.js
  • this.addModuleDependencies Compilation.js
  • buildModule过程中,使用acorn将代码js代码转换为ast,分析require 和 import 语句,触发对应的钩子收集相关依赖。

require

触发 call require:commonjs:item 钩子,在CommonJsRequireDependencyParserPlugin.js

const dep = new CommonJsRequireDependency(param.string, param.range);
dep.loc = expr.loc;
dep.optional = !!parser.scope.inTry;
parser.state.current.addDependency(dep);

import

触发 program钩子 在HarmonyDetectionParserPlugin.js

const module = parser.state.module;
const dep = new HarmonyCompatibilityDependency(module);
dep.loc = {
   start: {
      line: -1,
      column: 0
   },
   end: {
      line: -1,
      column: 0
   },
   index: -2
};
module.addDependency(dep);

每一个依赖(Dependency)的实体都包含一个module字段,指向被依赖的Module. 这样通过Module的dependencies数组成员就能找出该模块所依赖的其它模块。 webpack使用不同的Dependency子类,如AMDRequireDependency ,AMDDefineDependency ,AMDRequireArrayDependency,CommonJsRequireDependency,SystemImportDependency来表式不同的模块加载规范, 通过对应的DependencyParserPlugin来加载 AMD或CMD的模块。

原文地址:https://www.cnblogs.com/walkermag/p/webpack-yuan-mayi-lai-shou-ji.html

时间: 2024-11-09 03:03:36

webpack源码-依赖收集的相关文章

webpack源码分析——配置调试环境

无论是阅读webpack源码,还是编写webpack的plugin和loader,配置调试环境都是很有必要的.weabpack的运行环境是nodejs,调试webpack就是调试nodejs程序.我们平时使用的IDE如eclipse.webstorm都支持nodejs的调试.本文以eclipse(Version: Oxygen.1a Release (4.7.1a))为例,进行讲解. 在这个例子里面,我们使用webpack <entry> [<entry>] <output&

.10-浅析webpack源码之graceful-fs模块

在cachedInput.output.watch三大文件系统中,output非常简单,没有必要讲,其余两个模块依赖于input模块,而input主要是引用了graceful-fs的部分API,所以这节来讲讲graceful-fs. 上一节整理的源码如下: var fs = require('fs') // ...工具方法 module.exports = patch(require('./fs.js')) if (process.env.TEST_GRACEFUL_FS_GLOBAL_PATC

.1-浅析webpack源码之webpack.cmd

此系列随时可能断更,毕竟我是解释型源码分析-- 尝试看过Spring的源码,有点烧脑,所以还是重回JS吧! 在配置完环境变量后,可以通过webpack指令进行打包,需要知道的是,如果当前路径存在webpack.config.js文件,会被默认指定为配置JS文件 官网原文如下:If a webpack.config.js is present, the webpack command picks it up by default 也就是说直接执行webpack指令会默认执行webpack webp

.5-浅析webpack源码之入口函数

从convert-argv出来后,目前进度在这: yargs.parse(process.argv.slice(2), (err, argv, output) => { // ... // 从这里出来 var options = require("./convert-argv")(yargs, argv); // 跟convert-argv中的一样 function ifArg(name, fn, init) { /* ... */ } // 传入返回的options funct

.26-浅析webpack源码之事件流make(1)

compilation事件流中,依然只是针对细节步骤做事件流注入,代码流程如图: // apply => this-compilation // apply => compilation // return compialtion const compilation = this.newCompilation(params); this.applyPluginsParallel("make", compilation, err => { // callback...

webpack源码分析——参数初始化

webpack比较常见的用法有两种:一.使用配置文件:二.不使用配置文件(用命令 webpack <entry> [<entry>] <output>).这两种方式参数的初始化方式不太一样: 方式一.从配置文件和shell语句中读取并合并参数:方式二.从shell语句从直接读取入口和出口参数.本文会结合源码,分析一下这两种方式的实现.(文章使用的webpack版本是3.10.0) webpack执行的入口文件是bin目录下面的webpack.js,负责参数转换处理的文件

高德APP全链路源码依赖分析工程

一.背景 高德 App 经过多年的发展,其代码量已达到数百万行级别,支撑了高德地图复杂的业务功能.但与此同时,随着团队的扩张和业务的复杂化,越来越碎片化的代码以及代码之间复杂的依赖关系带来诸多维护性问题,较为突出的问题包括: 不敢轻易修改或下线对外暴露的接口或组件,因为不知道有什么地方对自己有依赖.会受到影响,于是代码变得臃肿,包大小也变得越来越大: 模块在没有变动的情况下,发布到新版本的客户端时,需要全量回归测试整个功能,因为不知道所依赖的模块是否有变动: 难以判断 Native 从业务实现转

.11-浅析webpack源码之Storage模块

至此已完成NodeJsInputFileSysten模块的讲解,下一步就是实际实用的模块: compiler.inputFileSystem = new CachedInputFileSystem(new NodeJsInputFileSystem(), 60000); 挂载到compiler对象上的输入模块其实是带有缓存的输入模块,源码整理如下(用ES6的class重写): class CachedInputFileSystem { constructor() { // fileSystem

.15-浅析webpack源码之WebpackOptionsApply模块之插件王中王

总体过了一下后面的流程,发现Compiler模块确实不适合单独讲解,这里继续讲解后面的代码: compiler.options = new WebpackOptionsApply().process(options, compiler); 这行代码与之前设置options默认值非常相似,但是复杂程度根本不是一个次元的. 这一节只能简单的看一眼内部到底有多少东西,整理后源码如下: "use strict"; const OptionsApply = require("./Opt