Automated release process for (Lerna) monorepo(sudolabs.io)

17 pointsby kiyanwangvor 5 Jahren7 comments

Automated release process for (Lerna) monorepo

https://sudolabs.io/blog/automated-release-process-for-lerna-monorepo

7 comments

Monorepos are underappreciated.

- Dealing with cross-repositories changes is unproductive.

- Relying on external servers (git / npm / whatever) is risky.

- Visibility of what goes to your servers is never easy without having everything in one (well-organized) monorepo.

Monorepos solve it all, without adding any issues, if done right.

pardsvor 5 Jahren

Is there a good solution for only building the projects that have changed? We looked at bazel.build but found it to be too complex.

randymarsh77vor 5 Jahren

CI systems (or surrounding community) typically give a mechanism for “last successful commit”. Executing a diff of changes and detecting from that which projects should be built from is something you can build using that data. If you have a lot of interconnected project dependencies in a mono repo, this logic might be more challenging to write, but there it is.

elcometvor 5 Jahren

One common issue is that build can be very long if you rebuild all the apps from your monorepo

lmeyerovvor 5 Jahren

We do yarn/lerna for the js side of our monorepo, and it's pretty ok. Hard to imagine not doing lerna/yarn/npm workspaces at this point, esp. vs say git submodules. Our warts here are more on getting docker incrementalized well, incl. for smaller air-gapped friendly builds + fast dev cycles.

More interesting to me is changelogs + docs. We juggle multiple server APIs and multiple rest + client APIs over them. At this point, I'm pretty against fully-auto-changelogs for medium projects with current tools. I suspect there are some missing SaaS companies here. ReadTheDocs + these kinds of changelog tools leave a lot to be desired. Maybe not VC-scale, but definitely bootstrap-scale...

haskellandchillvor 5 Jahren

Have you seen Optic (https://www.useoptic.com)? It’s a git-like tool for capturing API documentation.

lmeyerovvor 5 Jahren

a former colleague started another startup here, Akita, so I've been thinking a bit about these. I like this idea as a developer for when a third-party API stinks, but as an API provider, this a painfully indirect approach. I want to document our APIs and generate good UIs for that, and less interested in reverse engineering & comparing, which these focus on, and I assume, are thus less focused on doing a good job when we can give that data.