5 ms·

Automated release process for (Lerna) monorepo

17 points by kiyanwang 6y ago

prepperdev 6y ago
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.
- elcomet 6y ago
  One common issue is that build can be very long if you rebuild all the apps from your monorepo
- pards 6y ago
  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.
  - randymarsh77 6y ago
    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.
lmeyerov 6y ago
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...
- haskellandchill 6y ago
  Have you seen Optic (https://www.useoptic.com https://www.useoptic.com)? It’s a git-like tool for capturing API documentation.
  - lmeyerov 6y ago
    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.

17 points by kiyanwang 6y ago

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.

elcomet 6y ago
One common issue is that build can be very long if you rebuild all the apps from your monorepo
pards 6y ago
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.
- randymarsh77 6y ago
  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.

lmeyerov 6y ago

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

haskellandchill 6y ago
Have you seen Optic (https://www.useoptic.com https://www.useoptic.com)? It’s a git-like tool for capturing API documentation.
- lmeyerov 6y ago
  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.