前端的业务越来越庞大,导致我们需要引入的js等静态资源文件的体积也越来越大,不得不使用压缩js文件的方式来提高加载的效率. 编译工具的诞生,极大地方便了我们处理js文件的这一过程,但压缩后的js文件极难阅读,也难以调试,所以就产生了sourcemap这个功能. webpack开启sourcemap功能可以通过压缩代码的堆栈行.列号定位到源码的具体位置,我们就以webpack为例来看看如何利用sourcemap反向定位线上源码. SourceMap是一种映射关系.当项目运行后,如果出现错误,我们可

使用 paazmaya/shuji: Reverse engineering JavaScript and CSS sources from sourcemaps 可以从 sourcemap 中获取源码. 一个故事: 今天同事在完全没将代码加到过 stage 的情况下按了 VSCode 的Discard All Changes,然后这个版本的所有代码都丢失了(他也真是心大,整个这个版本的代码从头到尾都没有进入过 stage,我感觉用 git 是完全无法找回了),能找到的只有发布的代码. 原本当没

环境: Google Chrome  V72.0.3626.109 vue-dev V 2.6.10 爬坑的乐趣就不说了(我恨啊),以下说一下出坑要点 1. 在vue-dev的package.json文件如下位置加 --sourcemap, 用于生成.map文件 "scripts": { "dev": "rollup -w -c scripts/config.js --environment TARGET:web-full-dev --sourcemap&

上一篇文章我写了tapable的基本用法,我们知道他是一个增强版版的发布订阅模式,本文想来学习下他的源码.tapable的源码我读了一下,发现他的抽象程度比较高,直接扎进去反而会让人云里雾里的,所以本文会从最简单的SyncHook和发布订阅模式入手,再一步一步抽象,慢慢变成他源码的样子. 本文可运行示例代码已经上传GitHub,大家拿下来一边玩一边看文章效果更佳:https://github.com/dennis-jiang/Front-End-Knowledges/tree/master/Ex

经过非常非常长无聊的流程,只是将获取到的module信息做了一些缓存,然后生成了loaderContext对象. 这里上个图整理一下这节的流程: 这一节来看webpack是如何将babel-loader与js文件结合的,首先总览一下runLoaders函数: /* options => { resource: 'd:\\workspace\\doc\\input.js', loaders: [ { loader: 'd:\\workspace\\node_modules\\babel-loade

上一节看了一眼预编译的总体代码,这一节分析convert-argv模块. 这个模块主要是对命令参数的解析,也是yargs框架的核心用处. 生成默认配置文件名数组 module.exports = function(yargs, argv, convertOptions) { var options = []; // webapck -d // 生成map映射文件,告知模块打包地点 if(argv.d) { /* ... */ } // webpack -p // 压缩文件 if(argv.p)

webpack+vue 2.0打包发布之后,将发布的文件部署到服务器中之后,浏览器中访问的时候会出现一个webpack文件夹,里边会显示vue文件源码 如果不想让vue源文件显示出来,可以在config/index.js 中 build 下的 productionSourceMap: true, 改为 productionSourceMap: false, 即可

这里所有的插件都对应着一个小功能,画个图整理下目前流程: 上节是从ParsePlugin中出来,对'./input.js'入口文件的路径做了处理,返回如下: ParsePlugin.prototype.apply = function(resolver) { var target = this.target; resolver.plugin(this.source, function(request, callback) { // 分析request是否为模块或文件夹 var parsed =

在上一节中,最后返回了一个resolver,本质上就是一个Resolver对象: resolver = new Resolver(fileSystem); 这个对象的构造函数非常简单,只是简单的继承了Tapable,并接收了fileSystem参数: function Resolver(fileSystem) { Tapable.call(this); this.fileSystem = fileSystem; } module.exports = Resolver; resolve 而在mak

正式开始跑编译,依次解析,首先是: compiler.apply( new JsonpTemplatePlugin(options.output), // start new FunctionModulePlugin(options.output), new NodeSourcePlugin(options.node), new LoaderTargetPlugin(options.target) ); 流程图如下: 这里是第一个compilation事件注入的地方,注入代码如下: compil

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

Tapable工具 完成webpack默认参数注入后,下一步虽然是 new Compiler() ,但是这东西不是一下可以讲完的,复杂的一批. 不如先从工具入手,分块讲解compiler,首先来看看事件流执行器Tapable工具. tips:这里的Tapable源码来自于webpack内部自带的tapable,如果通过npm i tapable查看会发现完全不一样. 出现地点如下: class Compiler extends Tapable { // ... } class Compilati

validateSchema模块 首先来看错误检测: const webpackOptionsValidationErrors = validateSchema(webpackOptionsSchema, options); if(webpackOptionsValidationErrors.length) { throw new WebpackOptionsValidationError(webpackOptionsValidationErrors); } 可以注意到,这里传了两个参数,其实第

上一节生成Compilation实例后,添加了一些属性,随后触发this-compilation事件流,如下: Compiler.prototype.newCompilation = (params) => { // new Compilation() const compilation = this.createCompilation(); compilation.fileTimestamps = this.fileTimestamps; compilation.contextTimestam

这里的编译前指的是开始触发主要的事件流this-compilaiton.compilation之前,由于还有一些准备代码,这一节全部弄出来. 模块基本上只走构造函数,具体的方法调用的时候再具体讲解. 上一节NormalModuleFactory模块的构造函数中,在处理完rules后,注入两个事件流就结束了,所以可以回到如下代码: createNormalModuleFactory() { // 构造完成 const normalModuleFactory = new NormalModuleFa

Tips:写到这里,需要对当初的规则进行修改.在必要的地方,会在webpack.config.js中设置特殊的参数来跑源码,例如本例会使用module:{rules:[...]}来测试,基本上测试参数均取自于vue脚手架(太复杂的删掉). 下面两节的主要流程图如下: 在进入compile方法后,迎面而来的就是这么一行代码: const params = this.newCompilationParams(); 简单看一下方法,源码如下: Compiler.prototype.newCompila

本节流程如图: 现在正式进入打包流程,起步方法为run: Compiler.prototype.run = (callback) => { const startTime = Date.now(); const onCompiled = (err, compilation) => { /**/ }; this.applyPluginsAsync("before-run", this, err => { if (err) return callback(err); th

这节把编译打包后的流程梳理一下,然后集中处理compile. 之前忽略了一个点,如下: new NodeEnvironmentPlugin().apply(compiler); // 引入插件加载 if (options.plugins && Array.isArray(options.plugins)) { compiler.apply.apply(compiler, options.plugins); } compiler.applyPlugins("environment&

因为换了个工作,所以博客停了一段时间. 这是上个月留下来的坑,webpack的源码已经不太想看了,又臭又长,恶心的要死,想去看node的源码……总之先补完这个 上一节完成了babel-loader对JS文件字符串的转换,最后返回后进入如下代码: // NormalModule.js build(options, compilation, resolver, fs, callback) { // ... return this.doBuild(options, compilation, resol

新年好呀~过个年光打游戏,function都写不顺溜了. 上一节的代码到这里了: // NormalModuleFactory的resolver事件流 this.plugin("resolver", () => (data, callback) => { // ... asyncLib.parallel( /*...*/ , /* results: [ [], { resourceResolveData: { context: { issuer: '', compiler: