To me, a monorepo exists of a set of related or semi related services or runtimes that can operate autonomously, but have a dependency on their siblings to oper

To me, a monorepo exists of a set of related or semi related services or runtimes that can operate autonomously, but have a dependency on their siblings to operate correctly. In some cases, this could be two separate backend projects where you want to re-use the same deployment pipeline. Often, I find that API wrappers are something that I share across frontends and backends in the JS world, so it often makes sense to separate my projects into: - backend - frontend - common In Typescript I really like this pattern and can namespace shared types so that it’s very clear to the future reader that this type is probably used outside of the current context. So, to reply to your comment — I think the term “monorepo” can encompass a lot of different project types. I think Dan Luu covers the bases quite well here: https://danluu.com/monorepo/ https://danluu.com/monorepo/