项目维护

目的与范围

本文档概述了 Front-End Checklist 项目所采用的维护系统。它涵盖了用于确保代码库质量、准确性和可持续性的自动化和手动流程。重点关注的是随时间推移维护项目完整性的工具、工作流程和程序。

有关如何为项目做出贡献的信息，请参阅为项目做贡献。有关技术实现细节的信息，请参阅技术实现。

维护系统概述

Front-End Checklist 使用一个全面的维护系统，结合了自动化工具和手动流程来确保项目质量。该系统有助于维护清单的准确性，保持依赖项的更新，并有效地管理社区贡献。

来源：.github/workflows/stale.yml .github/workflows/readme-check.yml .github/workflows/links-checker.yml .husky/pre-push .markdownlint.json lychee.toml

自动化维护

该仓库采用多种自动化维护工具，以减少手动开销并确保质量一致。

陈旧问题管理

每周运行一次计划好的工作流，以识别和处理不活跃的 issue 和 pull request，有助于保持 issue 跟踪器的整洁和焦点。

stale issue 管理工作流每周（周六凌晨 1:30）运行一次，也可以手动触发。它会识别 40 天未活动的 issue 和 45 天未活动的 PR，并将它们标记为 stale。如果在被标记为 stale 的 10 天内没有任何活动，这些项目将被自动关闭。

某些 issue 和 PR 将免于此过程

分配给项目维护者的 issue/PR
带有特定标签的 issue/PR（keep-unstale、security 等）
带有 dependabot、wip 或 need-help 等标签的 PR

来源：.github/workflows/stale.yml1-37

链接验证

该项目使用两个互补的链接验证工作流

按需验证（由修改 README.md 的 pull request 触发）
计划验证（每周运行一次，以捕获可能随时间出现的损坏链接）

链接检查器通过 lychee.toml 进行配置，设置包括

接受特定的 HTTP 状态码（200、429、403）
设置 20 秒的请求超时
排除特定 URL（例如 caniuse.com）
缓存结果最多 2 天以提高性能

来源：.github/workflows/readme-check.yml1-40 .github/workflows/links-checker.yml1-36 lychee.toml1-21

格式强制执行

该项目通过预提交钩子和 CI 检查的组合来确保格式一致性。

本地预提交钩子在贡献者尝试推送更改时自动运行，确保代码到达存储库之前格式一致。CI 检查为修改 README.md 的 pull request 提供了第二层验证。

来源：.husky/pre-push1-2 .markdownlint.json1-6 .github/workflows/readme-check.yml32-33

手动维护流程

虽然自动化处理了许多日常任务，但手动流程在项目维护中仍然至关重要。

Pull Request 审核

Front-End Checklist 的 pull request 会经过审核，以确保其质量并符合项目标准。

审核流程考虑

更改对于项目范围的适宜性
技术信息的准确性
格式和风格一致性
链接和引用的有效性

正如贡献指南中所述，较小的 PR 更易于审核和合并，因此鼓励贡献者将大型更改分解为可管理的小块。

来源：CONTRIBUTING.md22-25

Issue 分类

Issue 由项目维护者进行分类，以

识别 bug 报告、功能请求和问题
分配适当的标签
根据影响和紧急程度对 issue 进行优先排序
关闭重复或超出范围的 issue

该项目通过 issue 系统欢迎各种贡献，包括 QA 报告、营销建议、社区倡议和代码改进。

来源：CONTRIBUTING.md7-11

文档更新

随着 Web 开发最佳实践的不断发展，Front-End Checklist 需要定期更新以保持最新。这包括

审查和更新清单项目
随着新最佳实践的出现而添加
废弃过时的建议
确保所有项目的准确优先级

维护工具和配置

GitHub Actions 工作流

项目使用了几个 GitHub Actions 工作流

工作流	文件	目的	触发器
Stale 管理	stale.yml	管理不活跃的 issue 和 PR	每周计划（周六）
README 检查	readme-check.yml	验证 README.md 中的格式和链接	修改 README.md 的 PR
链接检查	links-checker.yml	定期验证所有链接	每周计划（周一）

来源：.github/workflows/stale.yml .github/workflows/readme-check.yml .github/workflows/links-checker.yml

代码质量工具

项目采用多种工具来维护代码质量

工具	目的	配置
Husky	Git 钩子，在推送前强制执行格式	Pre-push 钩子运行 format:fix
markdownlint	Markdown linting，确保一致性	.markdownlint.json 中的自定义规则
Lychee	链接检查，验证 URL	lychee.toml 中的配置
Prettier	代码格式化	通过 format:fix 脚本应用

来源：.husky/pre-push .markdownlint.json lychee.toml

与贡献流程的整合

维护系统旨在通过以下方式支持贡献流程：

为 pull request 提供自动化反馈
确保贡献中的格式一致性
验证文档更新中的链接
管理 issue 和 pull request 的生命周期

来源： CONTRIBUTING.md .github/workflows/stale.yml .github/workflows/readme-check.yml

总结

前端清单的维护系统结合了自动化工具和手动流程，以确保该项目保持最新、准确并对前端开发人员有所帮助。自动化工作流处理诸如陈旧问题管理和链接验证等常规任务，而手动流程则通过代码审查和问题分类来确保质量。

这种全面的维护方法有助于该项目保持长期可持续性，同时减轻维护者的负担，并为贡献者提供一致的体验。