I recently built mani[0], a cli tool used to manage multiple repositories, which can solve some of the same issues with many-repo solutions, though I have a lot less packages than the author. It's similar to the package meta mentioned in the article, but comes with improved filtering of projects when running commands, a way to organize your projects from a single config, create scripts that target certain projects/groups only, auto-completion and some other helpful features.
mani is a CLI tool that helps you manage multiple repositories. It's useful when you are working with microservices, multi-project systems, many libraries or just a bunch of repositories and want a central place for pulling all repositories and running commands over them.
You specify repository and commands in a config file and then run the commands over all or a subset of the repositories.
Of course, but HCL imo is a much better alternative when compared to how yaml is used in k8s.
With nomad resulting HCL code even in unrendered state is a much more readable when compared to most k8s manifests.
With k8s yaml at some point becomes cumbersome and clunky to use. There might be some practices regarding writing manifests, that i am unaware of that alleviate these issues, but atm i would prefer working with HCL over yaml.
And regarding consul. K8s and consul use go templating, which in general feels ok.
Building an editor to create, view and edit vim color themes in your browser. Half-baked app architecture with a self-built redux and event emitter and code structure, gets the job done though.
Also building mani, a tool that helps you manage multiple repositories. It's helpful when you are working with microservices or multi-project system and libraries and want a central place for pulling all repositories and running commands over the different projects. You specify projects and commands in a yaml config and then run the commands over all or a subset of the projects.
It depends, in some regards it's kind as the results are seen immediately (is a path bringing more or less compilation errors, etc), whereas as in others it takes time to see if the decision you made was good or bad (did the architecture you chose scale).
