依赖项

依赖项更新

我们使用 Renovate GitLab Bot 来 自动为多个项目创建合并请求，以更新部分 Node 和 Ruby 依赖项。 你可以在项目的 README 文件中找到由 renovate bot 管理的最新项目列表。

一些使用 renovate 更新的关键依赖项包括：

• @gitlab/ui
• @gitlab/svgs
• @gitlab/eslint-plugin
• 以及 @gitlab/ 作用域下的任何其他软件包

我们的目标是使用 renovate 来更新所有依赖项。

自动更新依赖项有几个好处，可以看看这个示例合并请求 (MR)。

• 当新版本发布时，会自动创建合并请求 (MR)。
• 只需在合并请求 (MR) 描述中勾选一个复选框，即可轻松地对 MR 进行变基和更新。
• 合并请求 (MR) 包含变更日志摘要和用于比较不同软件包版本的链接。
• 可以将合并请求 (MR) 指派给直接负责这些依赖项的人员。

社区贡献更新依赖项

可以拒绝仅用于升级依赖项的社区贡献。 根据上述原因，简单的依赖项更新最好通过自动方式完成。 如果一个社区贡献需要变基、遇到冲突或变得过时，指导贡献者修正它所付出的努力往往会超过其带来的好处。

如果依赖项更新伴随着重大的迁移工作（例如由于主版本号更新），那么社区贡献是可以接受的。

以下是一条你可以用来向社区贡献者解释我们为何拒绝简单更新的消息：

你好，贡献者！

非常感谢你的贡献。看起来你正在进行一个“简单”的依赖项更新。

如果依赖项更新就像增加版本号一样简单，我们希望由机器人来完成这项工作，以节省你和我们双方的时间。

正如我们的<a href="https://docs.gitlab.com/ee/development/fe_guide/dependencies.html#updating-dependencies">前端开发指南</a>中所概述的，这样做有一定的好处。

你可能会发现我们目前没有自动更新 DEPENDENCY，但我们计划在[不久的将来](https://gitlab.com/gitlab-org/frontend/rfcs/-/issues/21)这样做。

感谢你的理解，我将关闭此合并请求。
/close