3 ms·

I've found that many developers do not pay attention to dependency management, so this approach of "it's either in the repo or it doesn't exist" is actually a n

I've found that many developers do not pay attention to dependency management, so this approach of "it's either in the repo or it doesn't exist" is actually a nice guard rail. I'm reading between the lines here, but, I'm assuming you've setup your tooling to enforce this. As in: the various projects in the repo don't just optionally decide to have external references, i.e., Maven central, npm, etc. This puts quite a lot of "stuff" in the repo, but with improvements like this article mentioned, makes monorepos in git much easier to use. I'd have to think, you could generate a lot of automation and reports triggering out of commits pretty easily, too. I'd say that would make the monorepo even easier to observe with a modicum of the tooling required to maintain independent repositories.

no_wizard 5y ago
That is accurate, I wouldn't use a monorepo without tooling, and in the JavaScript / TypeScript ecosystem, you really can't do much without tooling (though npm supports workspaces now, it doesn't support much else yet, like plugins or hooks etc). I have tried in the past, trying to achieve the same goals, particularly around the dependency graph and not duplicating functionality found in shared libraries (though this concern goes in hand with solving another concern I have, which is documentation enforcement), were just not really possible in a way that I could automate with a high degree of accuracy and confidence, without even more complexity, like having to use some kind of CI integration to pull dependency files across packages and compare them, in a monorepo I have a single tool that does this for all dependencies whenever any package.json file is updated or the lock file is updated If you care at all about your dependency graph, and in my not so humble opinion every developer should have some high-level awareness here in their given domain, I haven't found a better solution that is less complex than leveraging a monorepo

no_wizard 5y ago

That is accurate, I wouldn't use a monorepo without tooling, and in the JavaScript / TypeScript ecosystem, you really can't do much without tooling (though npm supports workspaces now, it doesn't support much else yet, like plugins or hooks etc). I have tried in the past, trying to achieve the same goals, particularly around the dependency graph and not duplicating functionality found in shared libraries (though this concern goes in hand with solving another concern I have, which is documentation enforcement), were just not really possible in a way that I could automate with a high degree of accuracy and confidence, without even more complexity, like having to use some kind of CI integration to pull dependency files across packages and compare them, in a monorepo I have a single tool that does this for all dependencies whenever any package.json file is updated or the lock file is updated If you care at all about your dependency graph, and in my not so humble opinion every developer should have some high-level awareness here in their given domain, I haven't found a better solution that is less complex than leveraging a monorepo