Should meshkit, meshery-adapter-library, and all adapters be merged into a monorepo?

Starting a discussion on whether to combine meshkit, meshery-adapter-library, and all adapters into a single monorepo. Each adapter would still be released as a unique build (up for discussion).

Pros:

  • Easier maintainability: dependency management will be easier since all these components can be updated at the same time (common go.mod file).
  • Easier development/debugging: since adapter code is spread across 3 separate repositories, it is very difficult to ramp up and contribute to the adapters.

Cons:

  • Refactoring at this point in the project: making such a drastic change will require quite a bit of effort and could introduce unforeseen issues.
  • Decreased flexibility: if all the adapters are in a single repository, it might result in them all being versioned the same (not sure how GitHub handles that). A change to one adapter or library will result in a version bump to all of them.

Please add more pros, cons, and/or other comments to the discussion.

My vote is to merge Meshkit and Adapter Library and leave the adapters as it is. Since there’s a big number of adapters out there, and we definitely loose flexibility if we merge adapters. So, +1 to merging Meshkit and Adapter Library but -1 for merging all the adapters because I think they’re better kept separated.

1 Like

@piyushsingariya can you please elaborate on what flexibility aspects would be lost?

This suggestion was brought in this week’s Meshery Development meeting and its not about merging all adapters into a single one but only move them to a Monorepo so code reuse and dependency updates are simplified, if I understoond @jbyers19 correctly.

Reasoning behind this is a recent negative dev experience from Jared in which unknowns about the right “ordering” of how dependencies should be updated between libs and adapters resulted in problems that took about 1 week to resolve from his side. (Maybe @jbyers19 could exemplify this better, what happened, etc.)

@MarioArriaga92, the reasoning behind this is to improve maintainability of the project and make it easier for people to contribute.

Look at the diagram below. With the current structure, any change to meshkit will result in an extra 18 PRs to update all the other components with that change!!! Let me say that again: 1 single change to meshkit will require EIGHTEEN different pull requests to fully update all Meshery components to implement that change. Every new adapter will add an additional PR. Dependency management is already difficult enough without adding this much overhead.

Before taking the time to create this graph, I didn’t realize how many components pulled in meshkit. Now I think it would be better to leave meshkit as it’s own repo and combine all the adapters and meshery-adapter-library into a single repo. Doing so will drastically decrease the amount of work that will need to be done to maintain the project while also making it easier for people to contribute to the adapters.

1 Like