我报名参与金石方案1期应战——分割10万奖池,这是我的第2篇文章,点击检查活动概况

前语

我不是标题党啊,是真的给webpack提了一个pr,提交之后,脑子里便是一句话:“纸上学来终觉浅,绝知此事要躬行”。

欲知来龙去脉,听我娓娓道来。

给webpack提了一个pr之后......

pr 如下,github.com/webpack/web…,现在还是unreviewed状况。

给webpack提了一个pr之后......


阅览此文章你将会了解以下知识点,

  • webstrom 调试webpack源码过程
  • webpack优化->deterministic 属性作用
  • 怎么提给开源库房pr
  • 怎么修正commit 信息
  • 怎么兼并commit 信息
  • EasyCLA开源协议签署遇到的问题

看到 = 学会,假如对屏幕前的大帅比大美丽有协助的话,点个赞什么的就太好了!

给webpack提了一个pr之后......

背景

那是一个周五的晚上,11.左右,大部分人都预备休息了,我正在做山月的linux训练营,赶巧,山月在webpack训练营里,圈出一处webpack的源码,8行左右吧。提到,此处有优化空间,能够提pr。

给webpack提了一个pr之后......

盯着这段代码,我看了半天,没有上下文,一脸懵圈。大部分人,没有看过源码,直接看必定看不出毛病,我也是这部分人的一部分。

后来找了一个做前端的朋友一起看,寻取协助,他刚刚团建完到家,毫无学习状况。

我知道有些路注定要一个人走,自己调试webpack源码吧。

调试

我是用的东西是webstorm。

首先我在node_modules中webpack目录下,全局搜索,敏捷定位到图示函数。

不得不说,webstorm 的搜索功能真是嘎嘎强!
定位到文件,lib/ids/DeterministicModuleIdsPlugin.js下,看代码不一定知道是什么逻辑,不过看姓名却很清楚了,是处理DeterministicModuleIds的一个插件函数。

先简单说说Deterministic

deterministic

正巧,最近刚刚在webpack 训练营学习了Deterministic
正好复习一遍。

这是一个webpack 优化项

optimization: {
    moduleIds: 'deterministic',
    chunkIds: 'deterministic'
}

在生产环境下,二者将被 webpack 默许装备为 deterministic。

这阐明这个装备项十分nice,webpack 现已帮咱们用了,那聪明的你必定要问了,它是干什么的呢?

告知 webpack 当挑选moduleId 和chunkId时需求运用哪种算法

deterministic在不同的编译中不变的短数字 id(最少三位)。有益于长时刻缓存。


翻译翻译便是=>


生成承认的id,这样能够有用防止由于模块引进的次序改动而导致的产物大面积更改的问题,每个module/chunk都有自己确认的 id。

举例阐明

比如在某项目某文件中,引进A模块,第一行import(A)过了一段时刻,需求引进B,新的模块,一般来说咱们会放在模块引进最下面,可是有个菜鸟,他在第一行添加import(B),import(A)就放在了第2行,并提交构建。

那么新增B,导致A,以及以前原有模块(我叫它们A+),引进次序都发生了改变,导致模块id发生改变,从而导致文件打包出来的文件名发生改变。

聪明的你,必定要问了,这有问题吗。其实没啥大问题!不会有任何反常。

可是有没有更好的解决方案,有!

deterministic 这个装备项就能够协助咱们,不管新增或者削减模块,把原有的模块对应的moduleId 和chunkId 每次打包出来都相同。

这样咱们就能够有用的利用浏览器缓存了。

当然了,不做也能够,大不了新增模块,所有chunk都发现了改变,翻开页面慢一点罢了。

给webpack提了一个pr之后......

现在其实也现已能够不关心了,因为webpack现已是默许装备了。

我只是大概说了下deterministic的作用,关于deterministic的原理,等后边有余力了,再整一篇。

开始调试

说了这么多,便是为了铺垫,现在咱们开始调试。
在webpack训练营的demo中,有这么一个比如,正好用到了deterministic。

//build.js
const path = require('path')
const webpack = require('webpack')
const normalConfig = {
  entry: './index.js',
  mode: 'none',
  output: {
    filename: '[name].[id].[contenthash].js',
    chunkFilename: '[name].[id].[contenthash].chunk.js',
    path: path.resolve(__dirname, 'dist/normal'),
  },
  optimization: {
    runtimeChunk: {
      name: entrypoint => `runtime-${entrypoint.name}`,
    },
    chunkIds: 'deterministic',
    moduleIds: 'deterministic'
  }
}
f1().run((err, stat) => {
  console.log(JSON.stringify(stat.toJson(), null, 2))
})

我运用的开发东西是webstorm,调试代码特别的方便。
在f1函数处,点击一下打上断点。

给webpack提了一个pr之后......

进入到node_modules的webpack/lib/ids/DeterministicModuleIdsPlugin.js

打上断点

给webpack提了一个pr之后......

右键build.js,挑选调试build.js,翻开webpack 调试界面,代码此时现已运行到咱们的咱们设置的第一个断点处
给webpack提了一个pr之后......


给webpack提了一个pr之后......

点击 >>| 按钮,直接运行到下一个断点处,能够看到圈出来的代码,usedIds 是一个set,用来存放moduleId
原代码逻辑是,先获取了原usedIds的长度size,插入新的id,假如发现size没变,阐明id 重复了,假如size变了,则阐明id 没有重复。
给webpack提了一个pr之后......

其实便是想判别usedIs中有没有id,没有必要绕这么一大圈用size来判别,能够直接用has来判别id 在不在usedIds中。时刻复杂度相同,还不必额定声明变量。

所以对上述代码进行改写
改写前

(module, id) => {
    const size = usedIds.size;
    usedIds.add(`${id}`);
        if (size === usedIds.size) {
            conflicts++;
            return false;
        }						    
    chunkGraph.setModuleId(module, id);    
    return true;
},

改写后

(module, id) => {
    if (usedIds.has(`${id}`) {
        conflicts++;
        return false;
    }
    usedIds.add(`${id}`);
    chunkGraph.setModuleId(module, id);
    return true;
},

创建提交pr

  • fork,webpack库房到自己github库房
  • git clone 到本地
  • 从main分支拉过来,新建一个靠谱的分支 feature
  • 修正代码
  • git add . 提交信息
  • git commit -m “XXXX” 填写靠谱的描绘信息
  • git push –set-upstream origin feature
  • 此时登陆github 就会看到自己fork的库房呈现一个Compare & pull request
    给webpack提了一个pr之后......
  • 点击,进入webpack库房代码提交兼并页面,仿照以前的提交的git log 格式,填写信息,之后,点击 create pull request
    给webpack提了一个pr之后......
  • 创建pr之后,就成功了,咱们就能够在webpack源码库房看到提交的pr了。

给webpack提了一个pr之后......

怎么修正commit

当咱们提交之后,发现自己commit 信息提交的不合适,或者有歧义,怎么修正呢?

  • git log之后,能够看到你之前提交过的git历史:
  • 接下来,在bash里输入wq退出log状况,执行:

给webpack提了一个pr之后......

  • git commit –amend

这时bash里会呈现以下内容:

给webpack提了一个pr之后......

  • 键入i 进入输出模式。修正commit 信息
  • 修正结束之后,:wq 坚持修正
  • 此时git log 现已能看到咱们的修正了

给webpack提了一个pr之后......

  • git push -f 提交修正

怎么兼并commit

因为是给源码提pr,所以其时很稳重,我分几回提交,导致有3次commit,山月老师主张兼并成一次,自己开发随心所欲惯了,遽然要兼并几回提交,就十分生疏,特意查了一下,所以记载一下。

  • git log,获取commit id

  • 假如需求兼并最近两个,需求获取倒数第3个commitId

  • git rebase -i e0108eeb2972553d

给webpack提了一个pr之后......

  • 按照默许次序,能够将除第一个提交外,都运用 fixup 或 squash 进行符号,终究你将得到这些commit向上兼并,终究变成一个,提交信息是 pick 符号的信息。
    • pick:运用此提交不做操作
    • squash:将指定的提交兼并到上边的pick恳求中,保存提交信息
    • fixup:与 squash 相似,但不保存提交信息
  • 把不需求的记载 改成fixup ,:wq保存

  • git push origin –force

完结上述操作之后,整个git提交记载就会彻底改动了,并且是不可逆操作,当然这也意味着rebase操作是有一定风险的,假如你不太清楚需求做什么的话就不要做。

签署EasyCLA

一个开源协议,许诺自己的代码可供开源运用

给webpack提了一个pr之后......

这儿需求留意,自己提交信息中的邮箱作者信息,需求和签署的邮箱一致,假如不一致,即使签署仍然显现无效。
而我这儿遇到的问题便是邮箱作者信息用的是公司gitLab的邮箱信息,所以github识别不到。

怎么修正邮箱作者信息

git commit --amend --author="otheruser <otheremail@qq.com>"
git rebase --continue
git push -f origin

总结

以上便是我提交pr的来龙去脉,至于提交pr的意义我们自己体会。

假如对屏幕前的大帅比大美丽有协助的话,点个赞什么的就太好了!

不管pr 会不会被merge,这都是webpack 团队工作了,对于我而言,从这个过程中,其实用到的知识点许多,都会细碎,也很简单,一但连贯起来。我遇到了许多许多问题,所以才深深感觉到“纸上学来终觉浅, 绝知此事要躬行”。

看再多博客知识视频,不如自己动手操作一次!

参阅

zhuanlan.zhihu.com/p/100243017
wangbjun.site/2022/coding…
oschina.gitee.io/opensource-…