Request for tips: how to handle product life cycle with mono_repo?

[daniel-v]

I've been looking into mono_repo to adopt. There are some really nice features that would make my life easier (mono_repo pub get eg.). I was looking at package:build for inspiration how it is done properly.

Things I noticed:

1. different packages are tagged by their release versions
2. checking out, say build_runner_core-v6.1.12 doesn't necessarily mean that at that revision all the other packages in the repo are compatible with build_runner_core @ that revision -> I drew the conclusion that the in the repo packages have their own life/release-cycle

Q1: is that conclusion correct?

Next things I'd like to explore is how you handle development. Hypothetical scenario (that kind of happened to me with package:build) is that I would like 1 package at a specific revision (tag) and have all the other packages at such a state that works well with that specific revision (eg. based on pubspec.lock file).

I was thinking on having multiple working copies and do sparse checkouts for package directories. That way the repository could remain a mono repo while locally I can handle different revisions/package version independently from each-other.

Q2: how do you go about mixing independent package life/release-cycle and having locally exactly what you need on a per package basis?

Thank you in advance!

ps. this could also help me a lot exploring build repository - I need breakpoints to see what's going on inside

[natebosch]

2. doesn't necessarily mean that at that revision all the other packages in the repo are compatible with build_runner_core @ that revision -> I drew the conclusion that the in the repo packages have their own life/release-cycle

Correct, although most of the time packages within that repo are cross compatible because we have integration test that use path dependencies on all of them to run tests.

how you handle development. Hypothetical scenario (that kind of happened to me with package:build) is that I would like 1 package at a specific revision (tag) and have all the other packages at such a state that works well with that specific revision (eg. based on pubspec.lock file).

Yeah it's common to make a quick local edit to a pubspec.yaml to flip between path and hosted dependencies and then running a pub get to resolve things.
We've left this entirely up to manual processes and it has generally worked out OK for us. @jakemac53 or @kevmoo might have different opinions on that part.

I was thinking on having multiple working copies and do sparse checkouts for package directories. That way the repository could remain a mono repo while locally I can handle different revisions/package version independently from each-other.

I only ever make full working copies - I don't bother with partial copies. Often I won't bother with a pub get in most of the package directories, but it's still an entirely manual process and I sometimes need to double check that I've done a pub resolve since the last time I change deps.