Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

For me the comparison to monorepo made a lot sense. One of the main features of monorepo is maintaining a DAG of dependencies and use that to decide which tests to run given a code change. CRAN package publishing seems to follow same idea.




> One of the main features of monorepo is maintaining a DAG of dependencies

No, that's the opposite of a monorepo (w/continuous integration). A monorepo w/continuous integration does not maintain any list of dependencies or relationships, by design. Every single commit is one global "version" which represents everything inside the repo. Everything in the repo at that commit, is only guaranteed to work with everything else in the repo in that commit. You use continuous integration (w/quality gates) to ensure this, by not allowing merges which could possibly break anything if merged.

Maintaining a DAG of dependencies is a version pinning strategy, the opposite of the continuous integration version-less method. It is intended for external dependencies that do not exist in the current repository - which is why it's used for multi-repos, not monorepos.

But as I originally pointed out, you can have a monorepo where everything is version-pinned (not using continuous integration). It's just not the usual example.


That's something you can do just as well with multiple repos though

What a monorepo gives you on top of that is that you can change the dependents in the same PR


for me too - in a way a "virtual" monorepo - as if all these packages belong in some ideal monorepo, even though they don't.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: