大约一个月前，我把自己拉进了关于 "零配置 "工具的优点的对话中，当时我用这个跳进了一个微博话题。
对此，有一些不同的意见。因为twitter是一个相当糟糕的媒体，无法为你的观点建立一个案例，我决定写出我对 "零配置 "工具的想法和理由。不过，我们将把这些工具称为 "工具包"🛠📦，而不是 "零配置"，这是在Dan Abramov的演讲中提出的。
工具包是 "一套任何形式的工具，允许你在没有构建配置的情况下创建应用程序"。(通过Ronald Rey在awesome-toolkits中的介绍）。举几个例子：react-scripts（create-react-app留给你的东西），我自己的paypal-scripts/kcd-scripts，parcel，preact-cli，ember-cli（第一个广泛使用的JS工具箱），以及更多。
这些工具背后的想法是，它允许你在你的项目中安装一个单一的依赖，其中通常包括一个CLI，你可以用它来为你的项目运行脚本。他们一般会在引擎盖下使用工具来完成他们的工作。一些工具包专注于项目需求的特定部分（如parcel或preact-cli，专注于构建），而其他工具则涵盖更多内容（如react-scripts，也涵盖测试和我的脚本项目，涵盖大量的东西，如更漂亮的自动格式化，发布等）。我们的目标是在不需要任何配置的情况下覆盖尽可能多的用例，并且在许多情况下允许一些额外的配置来覆盖更多的用例。
今天早上，我带着我的儿子们坐了一次城市公交车。他们很喜欢。在坐车的时候，我在想这个帖子，并意识到工具包类似于城市公交车/公共运输。一个城市公交系统通过在城市交通繁忙的地区建立公交线路，涵盖了尽可能多的使用情况。有些人确实需要他们自己车辆的动力和灵活性，但在大城市，许多人可以完全使用公共交通出行。对于这些人来说，他们甚至不需要学习如何自己开车，就可以在城市里有效地工作，更不用说拥有汽车了🚗。
拥有一辆车并学会驾驶它是很好的，但如果你可以不用担心它，那么一大类问题就可以消失了（比如把车辆的维护推给别人）。这是一个有点松散的比喻，但也许这对理解工具包所能发挥的作用有一点帮助。
那些习惯于建立/学习/配置广泛使用的工具的人问我，为什么我想建立并帮助普及工具包。以下是我为paypal和我自己的开源项目 做工具包的几个原因。
如果你曾经创建过一个以上的具有相同或类似工具用例的项目，那么你可能已经克隆了一个以前的项目，删除了部分或全部的源代码，并使工具大部分保持不变。如果你曾经复制/粘贴过一个webpack配置，请举手（/我✋）。对我来说，不可避免的情况是，当我在第二个项目上工作时，我意识到一些很好的东西并改进了配置。后来我回到原来的项目，发现我还没有更新配置，所以我也不得不更新这个项目。
这并不是什么大问题......直到你有几十个项目，而且你不是唯一在做这些项目的人。保持配置更新可能是一个真正的痛苦。
当工具被更新时，我们总是很兴奋。特别是在有突破性变化的情况下。这并不是因为这些突破性的变化，而是因为这些工具的维护者往往要等到有一个令人信服的理由时才会推动这些突破性的变化：通过功能/性能/等方式进行的重大改进。
也就是说，我不认为有人会对实际更新他们的代码库以处理这些变化感到兴奋。这就是工具包如此伟大的另一个原因。看看这个git diff。
这是对大量配置代码的删除😍
将近20个依赖关系替换成了1个，并且完全删除了这些依赖关系的配置，用几个简单的脚本替换。而这是我的一个较小/较简单的项目。
这个差异与我拥有的其他几十个开源项目的差异一致。管理所有的配置是一场噩梦 👻 🙀在我建立之前 kcd-scripts.每当babel或webpack的配置有变化，甚至是jest的简单更新，我都要去每个项目更新它们。然而现在，我可以简单地去 **kcd-scripts** ，解决任何破坏性的变化，并推送一个补丁版本，并将任何版本升级到所有底层工具。
事实证明，在大多数情况下，当工具推送破坏性的变化时，是因为配置改变了，而不是因为你需要改变你的源代码。因此，把所有的配置放在一个地方并保持更新，真的很方便。最重要的是，当我决定从webpack切换到rollup作为我的捆绑工具时，我根本不需要改变我使用kcd-scripts 。只要推送一个小的版本，所有的项目突然就有了新的功能。这真是......太棒了 🕶
当你谈到与团队合作时，所有这些好处都会变得更棒。在贝宝，我们有一群拥有专业工程师的团队。有些是我认识的最聪明的人。尽管这样，我们还是通过配置工具重复了大量的工作。我最近在我们内部的GitHub上做了一个搜索，发现我们有635个webpack.config.js ，897个.babelrc ，和5657个.eslintrc 😱 除此之外，我们中的一些有时间和知识的人花了很多时间来支持和回答关于这些工具的问题。
不是每个团队都能负担得起他们使用的每个工具的专家。我同意人们应该了解他们的底层工具，但在某些时候，你必须出货🚢，如果人们能够专注于他们最终产品的功能和错误修复，而不是磨练他们的webpack配置技巧，那肯定会很好。通过将常见的用例整合到一个单一的工具中，你可以实现这一点，人们不必担心要保持几十个工具和插件的更新。他们只需要依靠这个单一的工具。最重要的是，因为他们不必担心配置或保持更新，我们收到的问题就少了很多，可以把时间集中在改善工具的用户体验和其他对PayPal很重要的事情上。
但是......用例！？
在回应我的推文时，Sean T. Larkin 说。
这是对工具包的一个相当普遍和合理的反驳。然而，大多数工具包至少是两件事中的一件：
- 为支持常见的用例而制作，而不是所有的用例。
- 实际上还是可配置的。
普通用例
create-react-app产生一个非常简单的react应用，让你的工具包称为 react-scripts.这涵盖了你的react应用项目的构建、测试和刷新。它非常棒，在GitHub上有大量的项目使用（18万个搜索结果），你会发现在我的推特问题和丹的推特问题中提到了一些真实的世界应用。
虽然使用react-scripts 构建真实世界的生产应用令人印象深刻，但实际上这并不是该项目的核心目标。"这个工具的目的是为刚开始使用React的人提供最好的体验"（CONTRIBUTING.md#core-ideas）。
**工具包并不试图处理世界上的10000个用例。相反，它们使用底层工具和一些胶水来组合成一个单一的工具，可以处理尽可能多的用例，而不会使工具过于复杂或需要配置。**如果你的用例是一个特殊的雪花，那么你确实有一个可用的追索权。使用react-scripts ，你可以弹出。然而，对于大多数其他工具，你有另一个选择...
仍然是可配置的
大多数其他 "零配置 "的工具（工具包）**实际上仍然是可配置的。**正如我不久前在推特上所说。
这使得工具包能够覆盖更多的使用案例。例如，不想从react-scripts （因为他们喜欢上述的所有好处）的人，可以使用react-app-rewired。使用Next.js的人有一个next.config.js 文件，他们可以用来调整默认行为。事实上，即使是 webpack(部分灵感来自parcel我想)很快就会进入工具包的世界，但仍然是可配置的工具。
通过kcd-scripts 和paypal-scripts ，我已经使大多数底层生成的配置变得 "聪明"，它可以根据你的项目决定使用什么配置。例如，如果你把react 作为一个依赖项，那么ESLint的配置将包括可访问的JSX规则。有一堆这样的巧妙技巧，我认为工具可以而且确实用来给你开箱即用的最佳体验。
然而，如果这还不够，有一个简单而直观的方法来覆盖配置。你只需开始配置底层工具...jest 因此，如果你对底层的Jest配置不满意，那么你可以简单地在你的package.json ，或者在你的版本库根部添加一个jest.config.js 文件，你就可以开始行动了！paypal-scripts 将使用你的配置而不是内置配置。
除此之外，paypal-scripts 暴露了内置配置。因此，如果你喜欢大部分的内置配置，但想做一些改变，你可以这样做：
// jest.config.js
const builtInJestConfig = require('paypal-scripts/jest')
builtInJestConfig.notify = true
module.exports = builtInJestConfig
然后 "噗 "的一声!现在你仍然不需要保持你的工具是最新的，只要你所改变的配置部分没有被改变。
哦，如果你想使用另一个测试框架，那么你也可以这么做。只是不要使用paypal-scripts test 脚本。使用你想使用的工具的任何部分。
我可以理解这一点，而且你失去了可发现性是很可惜的。但我认为这是一个很好的权衡，因为前面提到的好处是80%的时间都不用配置任何东西，也不用担心保持工具的更新。如果我强迫你为这些工具中的每一个制作一个配置文件，这将是一个有利于20%需要它的人的障碍，强迫80%不需要的人。另外，你们每个人现在都在读这篇文章，都已经了解了paypal-scripts 在这方面的作用。 😉
为了进一步说明问题...大多数使用这些工具的开发者不知道或不关心它们是如何工作或配置的。他们只是想运送东西。我真的很欣赏TJ Holowaychuk在主题中给出的观点。
因此，虽然认为每个人都应该了解这些工具是如何工作的，这样他们就可以解决自己的问题，但事实是，大多数时候，这些工具的配置只是足够，直到它们勉强工作，然后工程师们就会转向其他任务，这些任务没有调整webpack配置那么艰巨（更不用说继续包括那些可以真正帮助他们的代码质量和防止错误的工具，如一个好的类型检查器或更有用的非风格化ESLint规则）。
我意识到这篇文章比正常情况下更多了一些废话。但我希望它是有帮助的。我想用Dan Abramov 在Zeit Day的演讲"The Melting Pot of JavaScript "中的一段话来结束。
我从几个人那里听说，他们把公司的工具依赖性整合到一个单一的软件包中，这对他们来说非常有效。我鼓励你尝试这种方法，并让我知道你的想法...。
试一试吧，也许你会发现这并不可怕。我知道我在我的项目中一直很喜欢kcd-scripts ，我期待着在PayPal😀有更多的人采用paypal-scripts ，祝你好运!👍
