And*_*ill 6 configuration frontend web-frontend reactjs package.json
在我的前端项目中，我一直在他们自己的文件中放置不同的“工具配置”。
例如： babel in babel.config.js、 jest in jest.config.js、 eslint in an.eslintrc.json等。
然而，我最近注意到，可以将许多这些配置直接放在项目package.json文件中。
我在网上做了一些挖掘并询问了一些同事，但似乎没有人能给我一个明确的答案，为什么人们可能更喜欢一种方法而不是另一种方法。
这纯粹是喜好问题吗？
我的建议是避免填充package.json自定义配置，主要有两个原因。
首先是关于开发人员的期望。将自己置于刚刚开始使用 JavaScript 和 NPM 生态系统的人的位置，您会看到一些未记录的内容，至少不是您期望的位置。这种体验很容易把人们赶走，特别是如果他们来自更严格的开发平台和语言。
其次，关键字冲突或更重要的是这样的想法是可能的。我们不希望 NPM 考虑在未来不使用某些关键字，因为一些闪亮的新库也在使用它，是吗？
另一方面，拥有 babel、browserlist、postcss 的专用文件是更简单、不言自明的方法，并且这些项目中的每一个都已经建议使用专用文件进行配置。
以下是 IMO 配置的优点和缺点package.json：
Pro package.json成为您的应用程序包、脚本以及现在的配置的单一事实来源。这是与您的应用程序相关的一切的一站式服务。
Pro它可以整理您的根目录。为所有不同的包提供单独的配置文件会变得混乱。
Con关键字冲突的可能性。如果 Node 推出的新关键字恰好与现有包配置的关键字相匹配，那么您必须要么不使用该关键字，要么将该配置移至单独的文件中。
大多数包文档在其示例中引用了单独的配置文件。这可能会让故障排除或新团队成员感到困惑。
缺点您的package.json文件可能会变得巨大。如果管理许多配置，与其他团队成员发生合并冲突的可能性就会大大增加。
总的来说，这取决于个人喜好。有一些工具，例如 husky ( https://github.com/typicode/husky )，默认情况下会放入配置package.json。我们的团队将两者结合起来。