summaryrefslogtreecommitdiff
path: root/doc/development/dependencies.md
blob: 329539f0cc2c8b40e4864828527070c1a022e99b (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
---
stage: none
group: unassigned
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.

Some key dependencies updated using renovate are:

- [`@gitlab/ui`](https://gitlab.com/gitlab-org/gitlab-ui)
- [`@gitlab/svgs`](https://gitlab.com/gitlab-org/gitlab-svgs)
- [`@gitlab/eslint-plugin`](https://gitlab.com/gitlab-org/frontend/eslint-plugin)
- And any other package in the `@gitlab/` scope

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 <a href="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.
/close
```