Having worked in both a very seperated multirepo codebase and a monorepo, I’ve got to say, at the moment, the monorepo (using pnpm) wins hands down for me.
a monorepo is far easier to develop a single-language, fairly monolithic (ie you need the whole application to develop any part) codebase in
(though as soon as you start adding multiple languages or it gets big enough that you need to work on parts without starting other parts of the application it starts to break down rather significantly)
but as soon as your app becomes less of a cohesive thing and more separated it becomes problematic… especially when it comes to deployments: a push to a repo doesn’t mean “deploy changes to everything” or “build everything” any more
i think the best solution (as with most things) is somewhere in the middle: perhaps several different repos, and a “monorepo” that’s mostly a bunch of subtrees or submodules… you can coordinate changes by committing to the monorepo (and changes are automatically duplicated), or just work on individual parts (tricky with pnpm since the workspace file would be in the monorepo)… but i’ve never really tried this: just had the thought for a while
a push to a repo doesn’t mean “deploy changes to everything” or “build everything” any more
What do you mean? I have yet to work for a company that’s organised and sophisticated enough to actually use a monorepo but my understanding is you’d set up something like Bazel so it only builds & tests (and I guess deploys) things that depend on your change.
Having worked in both a very seperated multirepo codebase and a monorepo, I’ve got to say, at the moment, the monorepo (using pnpm) wins hands down for me.
i’d say they’re pretty equivalent
a monorepo is far easier to develop a single-language, fairly monolithic (ie you need the whole application to develop any part) codebase in
(though as soon as you start adding multiple languages or it gets big enough that you need to work on parts without starting other parts of the application it starts to break down rather significantly)
but as soon as your app becomes less of a cohesive thing and more separated it becomes problematic… especially when it comes to deployments: a push to a repo doesn’t mean “deploy changes to everything” or “build everything” any more
i think the best solution (as with most things) is somewhere in the middle: perhaps several different repos, and a “monorepo” that’s mostly a bunch of subtrees or submodules… you can coordinate changes by committing to the monorepo (and changes are automatically duplicated), or just work on individual parts (tricky with pnpm since the workspace file would be in the monorepo)… but i’ve never really tried this: just had the thought for a while
What do you mean? I have yet to work for a company that’s organised and sophisticated enough to actually use a monorepo but my understanding is you’d set up something like Bazel so it only builds & tests (and I guess deploys) things that depend on your change.