any guidance on how to structure monorepos and show the packages within them

[Jake Zava]

anyone have any guidance on how to structure monorepos within compass?

Ideally would like to reflect that a monorepo application contains several packages within it and these have different teams and interdependencies.

Examples could be:

- monorepo for a frontend framework application that contains several packages for specific features within that application

- monorepo for a workflow application that orchestrates several workflow processes

the overall monorepo might be owned by a team (e.g. a platform team or relevant chapter/guild) but the specific packages within it would have their own team, dependencies, etc

ideally would like to be able to report on stats at the package level while also having some view on the overall framework 

[Tomislav Tobijas]

Hey @Jake Zava ,

Have you checked this official article: Integrate Compass with Bitbucket Cloud / Monorepos?

Like, generally, you would probably have:

• Monorepo = one Compass component

• Each package/module = separate Compass component (with its own team, metrics, dependencies)

And you'd probably have to push package-level events and metrics via REST API.

We just had a discussion related to metrics roll-up here > now I'm not sure how this will work with monorepos, but it's a thing to keep in mind. 👀

If anyone's got an actual example, that would be great to hear. From my side, it's mainly theoretical.

Cheers,
Tobi

[Martin Runge]

Hi @Jake Zava

I agree with @Tomislav Tobijas answer.

In a monorepo, as you pointed out, different teams often own different folders (packages). By making each package a separate Compass component, you could assign the correct team to each one. If you had only one component for the whole repo, you couldn't track who was responsible for what.

Metrics such as "Build Success Rate" or "Unit Test Coverage" often vary by package. Treating them as separate components lets you identify which specific service is "unhealthy" without the data being muddied by other parts of the repo.

Compass excels at showing how services interact. If Package A depends on Package B within the same monorepo, Compass can only visualize that relationship if they are defined as two distinct components.

I would choose to use one or an existing component. If your packages are small utility libraries that are never deployed independently, creating a Compass component for each could generate unnecessary clutter and extra administrative work. As @Tomislav Tobijas mentioned, if you have many packages, you will likely need to automate pushing events and metrics via the Compass REST API, since the standard "out of the box" integration may only look at the root repository level.