migrate-to-rslint

迁移到 Rslint

目标

以最小的行为变更迁移 lint 工具，并进行清晰的验证。

支持的源代码 linter

• ESLint flat config
• Oxlint

迁移原则（必须遵循）

1. 优先查阅官方文档：CLI、配置、内联指令、VS Code 设置、规则和预设均以 Rslint 文档为准。根据已安装版本确认功能；历史迁移缺口和变通方案并非永久限制。
2. 优先采用最小变更：先迁移包、命令、配置和编辑器接线，再更改源文件。
3. 保留 lint 意图：在 Rslint 支持的范围内，保留规则的严重级别和选项；明确指出不支持的规则/插件，不要悄悄丢弃其行为。
4. 保留内联抑制意图：保留生效的指令、其目标规则及作用范围。除非用户要求重命名，否则保留兼容的前缀；转换仅适用于源 linter 的语法，并在对应的源代码专用指南中说明已禁用的指令兼容性。
5. 验证后再清理：将 lint 入口切换到 Rslint，并验证迁移范围，然后再移除过时的源 linter 产物。报告不支持规则造成的覆盖差异，但不要将其视为阻碍，也不需要单独征求批准。

工作流

1. 检测源代码检查工具

   • ESLint 扁平配置：eslint.config.*、eslint 依赖，或运行 eslint 的 package 脚本。
   • Oxlint：.oxlintrc.json、.oxlintrc.jsonc、oxlint.config.*、oxlint 依赖，或运行 oxlint 的命令。
   • 记录已安装的版本、命令、工作目录、环境开关，以及要迁移的范围。在该范围内，纳入共享配置、嵌套配置和根目录回退行为。
   • 如果尚无适用于源代码检查工具的迁移参考资料，请清点当前行为，并说明没有专门的迁移参考资料。

2. 准备 Rslint 并应用源代码检查工具专用指南

   • 在检查规则、配置和插件 API 之前，先使用仓库的包管理器选择并安装目标 @rslint/core 版本。遵守现有版本约束，并保留源代码检查工具以供验证。
   • ESLint 扁平配置：references/eslint-flat-config.md
   • Oxlint：references/oxlint.md
   • 如果任一源代码检查工具使用了社区或本地 JS 插件，还需阅读 references/eslint-plugins.md。

3. 更新检查入口

   • 使用受支持的 rslint.config.* 格式。保留翻译后的配置所需的源插件依赖。
   • 更新迁移范围内的 package 脚本、CI、钩子和暂存文件命令。使用 Rslint CLI 参考资料转换标志，同时保留工作目录、文件参数、警告阈值和环境开关。
   • 使用 Rslint VS Code 指南更新现有的编辑器集成。保留无关的编辑器工具和设置。

4. 验证行为

   • 运行迁移后的检查命令。
   • 根据源代码清单检查生效的规则和选项、文件覆盖范围、抑制项及插件执行情况。仅退出成功并不能证明行为等效。
   • 对于已启用、但尚未验证有原生替代方案或兼容 JS 插件替代方案的源规则，请省略不受支持的目标配置键，并在最终报告中记录规则名称、受影响的文件范围和覆盖缺失情况。继续迁移受支持的规则。
   • 如果项目原本有修复命令，仅在适合任务时运行迁移后的修复命令。
   • 清理前，解决目标配置加载错误、受支持规则的无效选项、命令失败和编辑器集成错误。

5. 清理并总结

   • 确认迁移范围内的所有检查入口都使用 Rslint，然后在验证后移除过时的源代码检查命令、配置和依赖。
   • 总结已完成的切换和验证，并列出任何省略的规则或插件、受影响的范围，以及覆盖范围或行为变化。