Readit Newschrismatic commented on The Ingredients of a Productive Monorepo blog.swgillespie.me/posts... · Posted by u/mifydev
I am excited to learn of this project. I started working on something quite similar recently. It's a surprisingly unaddressed niche.
One thing your tool appears to be missing (IMO) is execution sandboxing. This is useful, as you likely know, for avoiding undeclared dependencies and for avoiding dirty builds due to actions polluting the source directory, among other things. I was playing around with allowing configurable sandboxing, with symlink forest and docker as two intial options.
I fully agree. I was also thinking about docker or symlinks, but it seemed hard to design the API without any actual user feedback. Pants environments [0] look interesting.
Very cool that you are also recognizing this issue and working on it. I sent you an email in case you want to exchange further.
[0] https://www.pantsbuild.org/stable/docs/introduction/welcome-...
chrismatic commented on The Ingredients of a Productive Monorepo blog.swgillespie.me/posts... · Posted by u/mifydev
If a single language is an option you are a small project that is not facing the problems people on large projects are facing. A monorepo will be easy for you without read the article and the lessons learned.
Come back when you have millions of lines of code, written over decades by hundreds (or thousands) of full time developers.
There is a space between the two types of repositories you are describing. One where you just have enough tools/langs that a single-language setup does not cut it for you anymore, but investing all that effort into Bazel does not seem worth it yet. That is the gap that Grog is meant to fill.
chrismatic commented on The Ingredients of a Productive Monorepo blog.swgillespie.me/posts... · Posted by u/mifydev
The point about trying to stick with a single language build tooling really cannot be stressed enough. It is what prompted me to write a simplified version of Bazel, a generic "target determinator" with caching capabilities if you will. I call it "Grog", the monorepo build tool for the grug-brained developer.
Why should I use this and how is it better than Bazel?
If you are a small to mid-sized team, moving to Bazel is massively painful and basically requires up to one full-time position to provide your team with a good experience.
Grog on the other hand let's you keep your existing build setup while just parallelizing and caching it. It's not a full replacement, but it's more than enough for most mid-sized teams that want to have fast mono-repo builds.
I am working on Grog, the “grug-brained” alternative to Bazel. A mono-repo build tool where all you do is provide your build commands and interdependencies and the tool will run everything in parallel while caching as much as possible.
https://grog.build/why-grog/