Monorepo gitlab-ui and gitlab-ce
(Previously called move gitlab-ui to gitlab-ce
which is different than monorepoing. Some of the comments refer to this earlier proposal).
Monorepo noun
- One repository for your individual but related microservices and libraries
Proposal
Let's co-locate the gitlab-ui
code with gitlab-ce
. We can use yarn workspaces to manage gitlab-ui
like a separate package while sharing some configurations from gitlab-ce
.
Separate the packages. Unify the repo.
Why is this worth considering?
It seems like we might be spending extra effort to solve the wrong problems (e.g. auto creating MR's to bump versions). We have established our engineering culture to value velocity and if our current setup hurts this, it's worth reevaluating.
As a side note, a co-located monorepo is frequently discussed amongst the BE team (issue?) when faced with cross-cutting MR's.
Analysis
Pros:
- Current workflow is hugely inefficient - multiple people have spoken to me with concerns about getting change freeze because of the multiple MR dance.
- Where to raise issues - We move issues back and forth between CE and UI repos, and it is unclear to all but the frontiest of frontenders where the bug resides. Example: make jest (in CE) work with gitlab-ui
- Packaging is completely independent of development - Reusability/sharing/publishing of npm package should not dictate how we write and store our code
- gitlab-ui cannnot be used separately in its current form It depends on styles added in CE.
- “faster pipelines” is still achievable We have CI/CD for external repos. We are encouraged to dogfood everything. We should treat the pain of slow CE pipelines as an incentive to make them faster (or make FE-only pipelines).
- Moving components from vue_shared to gitlab-ui is currently painful. If in one project, it’d be a simpl e find/replace of paths. Users of JetBrains products will basically start doing these renames for fun to show how great their editor is.
- Build Tool Inconsistency - why are we rolling up gitlab-ui shows the challenges of both measuring and monintoring the impact of bundle size across projects. See also this discussion around webpack/rollup challenges we face
- The handbook prefers it - according to the Basics of GitLab Development: “Every time you choose between changes in the application code or adding new dependencies, you should give priority to the first because this is easier to maintain and set up”
- High friction for contributors If we eventually decide to publish a more complete, functional lib, then we can start to worry about standalone, deps, etc. For now we should encourage and reduce friction for contributors
- The “frontend-only contributions” argument has some merit. However:
- we have a project called “gitlab development kit”. This is the first place people look to start developing gitlab, and the better-documented project.
- Recent reports indicate GDK takes about an hour to setup. Not ideal, but again a good reason for us to improve this. Projects like gitlab-compose-kit are a great step toward reducing setup requirements and dependencies
Cons:
- Pipelines and Overall Project size - Its faster and way more convenient to work with really fast pipelines and small iterations. Same as we have a couple of projects in seperate repos.
- Easier Overview of a specific topic - Makes it easier to understand
- Separation - Way easier to have different workflows and/or keep us from doing shortcuts (especially in CSS) and/or easier working in parallel
- Versioning - In the Future it also might happen that gitlab-ui is ahead but we don't have time for integrating it in CE but then still gitlab-ui can easily go ahead without the confusion of having in CE a different NPM package and different actual source
- Saving on unnecessary Dev Dependencies - We might have dev dependencies that are only needed for actual ui development
- Reusability from different projects - On the long term we might go the way of having separate repositories for specific SPA's