关于前端:你给开源项目提过-PR-吗

你有给开源的库或者框架提过 PR 吗？

如果没有，那么明天的文章会教你怎么给开源库提 PR。

这件事还得从好几年前（2019 年）说起，那时候在折腾一个虚构 DOM 的玩具（参考之前的文章：🔗虚构 DOM 到底是什么？），作为一个规范的前端工程，构建工具、Lint 工具、代码格式化都是必不可少的。

在构建工具上我抉择了 Rollup，心愿每次构建的时候都能主动进行代码的 Lint，所以引入了 Rollup 的一个插件：rollup-plugin-eslint。

在应用这个插件的过程中，发现和 Webpack 对应的插件 eslint-webpack-plugin 还是有一些差距的。我在应用 Webpack 的 eslint-webpack-plugin 时候，只须要配置 fix 属性，就可能在保留代码的时候，主动对代码进行 fix。

// webpack.config.js
const ESLintPlugin = require('eslint-webpack-plugin');

module.exports = {
  // ...
  plugins: [
    new ESLintPlugin({
      fix: true,
      extensions: ['js', 'jsx']
    })
};

而在应用 rollup-plugin-eslint 的时候，看文档上，如同没有提到这个选项，也就是说 rollup-plugin-eslint 基本不反对这个性能。而后，搜寻了一下 Issues，不搜不要紧，一搜吓一跳，发现有人在 2016 年就提出了这个疑难😳。

作者的回复也很简略，欢送提交 PR。

我过后心想，这个性能这么久了都没人实现想必很难吧。然而隔壁的 eslint-webpack-plugin 明明反对这个性能，我去看看它怎么实现的不就行了🐶。

于是，我就把 eslint-webpack-plugin 的代码 clone 下来一顿搜寻，发现它实现这个性能就用了三行代码。

if (options.fix) {await ESLint.outputFixes(results);
}

冲动的心，颤动的手，我赶紧就去 rollup-plugin-eslint 那里提了个 PR。

🔗PR: https://github.com/TrySound/r…

要害是，作者都没想到这个货色竟然这么简略就实现了。

下面是我第一次提 PR 的一个心路历程，如果你也发现了你当初应用的什么开源框架有待优化的中央，这里再教大家怎么在 GitHub 上提交一个 PR。

首先把你要提交 PR 的我的项目 Fork 到本人的仓库。

而后到本人的仓库中，将 Fork 的我的项目 clone 到本地。

$ git clone git@github.com:Shenfq/rollup-plugin-eslint.git

代码 clone 到本地之后，先切换一个新的分支，分支名最好紧贴这次更新的内容。

$ git checkout -b feature/add-fix-option

在新分支批改代码：

+  if (options.fix && report) {+    CLIEngine.outputFixes(report);
+  }

提交变更：

$ git add .
$ git commit -m "feat: add options.fix"

最初将新的分支推送到近程：

$ git push --set-upstream origin feature/add-fix-option

在本人的 GitHub 仓库中找到对应我的项目，关上 Pull requests Tab，点击 New pull request 按钮，新建一个 PR。

而后，在上面的界面中，抉择刚刚提交的分支，最初点击 Create pull request 即可。

点击之后，就在对应的我的项目中提交了一个属于你的 PR 了。如果顺利的话，你就能『混』到一个开源我的项目贡献者的头衔。

关于前端:你给开源项目提过-PR-吗

为什么要给开源我的项目提 PR？

如何在 GitHub 上提 PR？

对开源我的项目进行 Fork

切换到新分支，提交变更，推送到近程

新建 PR