For that you could use something like ajv.
Json schema has the advantage of being usable across different languages, but it does come with the overhead of maintaining those files and keeping it in sync with your other repos.
It's much nicer to have everything you could ever need in one place, instead of having to know what is in what repo. Especially when you have versions that need to correspond in the different repos...
ok. But _much_ easier to have compile time checking between projects in the same language/repo. Not saying this approach is wrong, but it's a little like riding a unicycle when a perfectly good bicycle is sitting right there.
Even as a developer, I don't always know which repo to file something against. And most "issues" span multiple repositories. Sure, I need to add feature X to repository A and feature Y to repository B (in order to implement some bigger project) but that's not how we plan or assign work.
More importantly, at our daily standup, we need a single view across all of our tasks/work, not the work within a single repository.
It just seems like such a miniscule benefit, and you have to deal with the massive headache of a multi-repo setup.
If you don't want people making changes to multiple projects at the same time, it would be trivial to add a pre-submit check to enforce that anyway. There's no need to switch your entire repository layout just to remind people that the code in different folders belongs to different projects.
Not particularly - unless different teams are highly focused on certain subsections of the repository. If everyone might have to look anywhere than you'll need to download all the repos - whether that's one or five hundred.
Very much agree, most projects I work on these days have components in multiple repositories and trying to coordinate work among them is challenging. We use Github Issues as a source of truth but have resorted to using third-party software on top of them to help get a bigger-picture view. Currently we're using Codetree: https://codetree.com/
Oh yeah in that case it'd be a problem. There might be a way around that but that case definitely isn't ideal. albeit you could probably sparse-checkout your repo to avoid that if you don't need all of it.
definitely not ideal and I agree that until lazy file mapping, content addressed derivations, and file deduplication get implemented that the UX will be rough in some cases.
Yes, the problem is that due to the size most of it lives in different repositories so it's hard to know what version you're supposed to build and when something you depend on changes.
reply