Automated release process for (Lerna) monorepo | Hacker News Reader

Automated release process for (Lerna) monorepo

sudolabs.io

17 pointskiyanwang7 comments

Open articleView on HN

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.

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

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.

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.

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...

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

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.

Reply on news.ycombinator.com