info:To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
---
# Dependencies
## Dependency updates
We use the [Renovate GitLab Bot](https://gitlab.com/gitlab-org/frontend/renovate-gitlab-bot) to
automatically create merge requests for updating (some) Node and Ruby dependencies in several projects.
You can find the up-to-date list of projects managed by the renovate bot in the project's README.
We have the goal of updating [_all_ dependencies with renovate](https://gitlab.com/gitlab-org/frontend/rfcs/-/issues/21).
Updating dependencies automatically has several benefits, have a look at this [example MR](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/53613).
- MRs are created automatically when new versions are released.
- MRs can easily be rebased and updated by just checking a checkbox in the MR description.
- MRs contain changelog summaries and links to compare the different package versions.
- MRs can be assigned to people directly responsible for the dependencies.
### Community contributions updating dependencies
It is okay to reject Community Contributions that solely bump dependencies.
Simple dependency updates are better done automatically for the reasons provided above.
If a community contribution needs to be rebased, runs into conflicts, or goes stale, the effort required
to instruct the contributor to correct it often outweighs the benefits.
If a dependency update is accompanied with significant migration efforts, due to major version updates,
a community contribution is acceptable.
Here is a message you can use to explain to community contributors as to why we reject simple updates:
```markdown
Hello CONTRIBUTOR!
Thank you very much for this contribution. It seems like you are doing a "simple" dependency update.
If a dependency update is as simple as increasing the version number, we'd like a Bot to do this to save you and ourselves some time.
This has certain benefits as outlined in our <ahref="https://docs.gitlab.com/ee/development/fe_guide/dependencies.html#updating-dependencies">Frontend development guidelines</a>.
You might find that we do not currently update DEPENDENCY automatically, but we are planning to do so in [the near future](https://gitlab.com/gitlab-org/frontend/rfcs/-/issues/21).
Thank you for understanding, I will close this Merge Request.
We have the goal of updating [_all_ dependencies with renovate](https://gitlab.com/gitlab-org/frontend/rfcs/-/issues/21).
Updating dependencies automatically has several benefits, have a look at this [example MR](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/53613).
- MRs will be created automatically when new versions are released
- MRs can easily be rebased and updated with just checking a checkbox in the MR description
- MRs contain changelog summaries and links to compare the different package versions
- MRs can be assigned to people directly responsible for the dependencies
### Community contributions updating dependencies
It is okay to reject Community Contributions that solely bump dependencies.
Simple dependency updates are better done automatically for the reasons provided above.
If a community contribution needs to be rebased, runs into conflicts, or goes stale, the effort required
to instruct the contributor to correct it often outweighs the benefits.
If a dependency update is accompanied with significant migration efforts, due to major version updates,
a community contribution is acceptable.
Here is a message you can use to explain to community contributors as to why we reject simple updates:
```markdown
Hello CONTRIBUTOR!
Thank you very much for this contribution. It seems like you are doing a "simple" dependency update.
If a dependency update is as simple as increasing the version number, we'd like a Bot to do this to save you and ourselves some time.
This has certain benefits as outlined in our <ahref="https://docs.gitlab.com/ee/development/fe_guide/dependencies.html#updating-dependencies">Frontend development guidelines</a>.
You might find that we do not currently update DEPENDENCY automatically, but we are planning to do so in [the near future](https://gitlab.com/gitlab-org/frontend/rfcs/-/issues/21).
Thank you for understanding, I will close this Merge Request.
-[GitLab core team & GitLab Inc. contribution process](https://gitlab.com/gitlab-org/gitlab/-/blob/master/PROCESS.md)
-[GitLab core team & GitLab Inc. contribution process](https://gitlab.com/gitlab-org/gitlab/-/blob/master/PROCESS.md)
-[Security process for developers](https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md#security-releases-critical-non-critical-as-a-developer)
-[Security process for developers](https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/developer.md#security-releases-critical-non-critical-as-a-developer)
-[Patch release process for developers](https://gitlab.com/gitlab-org/release/docs/blob/master/general/patch/process.md#process-for-developers)
-[Guidelines for implementing Enterprise Edition features](ee_features.md)
-[Guidelines for implementing Enterprise Edition features](ee_features.md)
-[Danger bot](dangerbot.md)
-[Adding a new service component to GitLab](adding_service_component.md)
-[Guidelines for changelogs](changelog.md)
-[Guidelines for changelogs](changelog.md)
-[Dependencies](dependencies.md)
-[Danger bot](dangerbot.md)
-[Requesting access to ChatOps on GitLab.com](chatops_on_gitlabcom.md#requesting-access)(for GitLab team members)
-[Requesting access to ChatOps on GitLab.com](chatops_on_gitlabcom.md#requesting-access)(for GitLab team members)
-[Patch release process for developers](https://gitlab.com/gitlab-org/release/docs/blob/master/general/patch/process.md#process-for-developers)
-[Adding a new service component to GitLab](adding_service_component.md)
