来自 React 项目的长期累积警告列表。保留它们还是清除它们？
A long accumulated list of warnings from a React's project. Keep them or clear them up?
我手头有一个大型项目，其中积累了大量 React 的各种警告 - 大部分与 useEffect 相关。
不过，该应用 运行 没有严重错误。
但是在每个 launching/reloading.
中看到所有这些警告是很烦人的
我知道有一个简单的解决方案，可以插入 // eslint-disable-next-line 甚至禁用整个文件，但是手动执行此操作会出现 +300 条警告，并且很多文件都非常困难且耗时。
此外，我在尝试手动修复所有这些警告时遇到了糟糕的经历，只是不得不恢复到之前的提交，因为它以某种方式恶化了应用程序的性能，而且我找不到问题的根源——这是多个问题- 在许多修改过的文件中，即使比较 Github 中的差异也没有揭示它们。
那么，您是否有更好的方法来清除它们或更好地保留它们并遵循“如果它正在工作就不要修复它”的原则？
注意：本项目使用create-react-app运行最新的React version 17，未注入
你想离开也可以，但长期下来，你会得不偿失。同样重要的是，如果您决定采取行动并修复它们，请在专门的分支上工作。
好吧，我在遗留项目和从一开始就没有配置 linter 的项目中遇到了类似的问题。
我遵循的一个策略可以这样描述：
- 在开始修复与 linter 相关的问题之前，请确保定义的规则尽可能接近您要在代码库中检查的规则
这是一个重要的阶段，因为如果您计划修复数百个与 linter 相关的问题，您不希望发现自己再次做同样的工作。
- 与您的团队确认是否需要添加额外的规则，尝试在所有项目中遵循一个标准
重要的是要与您的队友保持一致，以防止出现这种情况，如果队友在代码编辑器中打开了一个启用了 linter 的文件，而该文件的配置方式与您的配置方式不同，您的工作将会丢失。请注意，最佳做法是将 linter 配置文件包含在代码存储库中。相反，这是为了避免将编辑器的配置文件放入存储库，因为它们可能因环境而异。
- 使用命令行配置执行 lint 检查和 lint 修复所需的所有命令
例如，在 package.json 文件中，您可以在脚本部分添加如下内容：
"lint:check": "eslint ./src/**/*.ts*",
"lint:fix": "eslint ./src/**/*.ts* --fix"
- 让我们开始做肮脏的工作，调用您之前定义的命令来修复所有可自动修复的问题
类似这样的事情：
yarn link:fix
- 按顺序执行手动操作
从一种错误开始，按顺序进行。按类型进行操作很重要，因为通过这种方式，您可以使用代码编辑器的搜索工具来搜索给定的模式，并在某些情况下使用“复制粘贴”修复。您可能很想一次处理一个文件，但在这种情况下，您必须在每一行代码中改变您的思维方式，并且更容易出现错误。
我手头有一个大型项目，其中积累了大量 React 的各种警告 - 大部分与 useEffect 相关。
不过，该应用 运行 没有严重错误。
但是在每个 launching/reloading.
中看到所有这些警告是很烦人的我知道有一个简单的解决方案，可以插入 // eslint-disable-next-line 甚至禁用整个文件，但是手动执行此操作会出现 +300 条警告，并且很多文件都非常困难且耗时。
此外，我在尝试手动修复所有这些警告时遇到了糟糕的经历，只是不得不恢复到之前的提交，因为它以某种方式恶化了应用程序的性能，而且我找不到问题的根源——这是多个问题- 在许多修改过的文件中，即使比较 Github 中的差异也没有揭示它们。
那么，您是否有更好的方法来清除它们或更好地保留它们并遵循“如果它正在工作就不要修复它”的原则？
注意：本项目使用create-react-app运行最新的React version 17，未注入
你想离开也可以，但长期下来，你会得不偿失。同样重要的是，如果您决定采取行动并修复它们，请在专门的分支上工作。
好吧，我在遗留项目和从一开始就没有配置 linter 的项目中遇到了类似的问题。
我遵循的一个策略可以这样描述：
- 在开始修复与 linter 相关的问题之前，请确保定义的规则尽可能接近您要在代码库中检查的规则
这是一个重要的阶段，因为如果您计划修复数百个与 linter 相关的问题，您不希望发现自己再次做同样的工作。
- 与您的团队确认是否需要添加额外的规则，尝试在所有项目中遵循一个标准
重要的是要与您的队友保持一致，以防止出现这种情况，如果队友在代码编辑器中打开了一个启用了 linter 的文件，而该文件的配置方式与您的配置方式不同，您的工作将会丢失。请注意，最佳做法是将 linter 配置文件包含在代码存储库中。相反，这是为了避免将编辑器的配置文件放入存储库，因为它们可能因环境而异。
- 使用命令行配置执行 lint 检查和 lint 修复所需的所有命令
例如，在 package.json 文件中，您可以在脚本部分添加如下内容：
"lint:check": "eslint ./src/**/*.ts*",
"lint:fix": "eslint ./src/**/*.ts* --fix"
- 让我们开始做肮脏的工作，调用您之前定义的命令来修复所有可自动修复的问题
类似这样的事情：
yarn link:fix
- 按顺序执行手动操作
从一种错误开始，按顺序进行。按类型进行操作很重要，因为通过这种方式，您可以使用代码编辑器的搜索工具来搜索给定的模式，并在某些情况下使用“复制粘贴”修复。您可能很想一次处理一个文件，但在这种情况下，您必须在每一行代码中改变您的思维方式，并且更容易出现错误。