I personally found Homebrew to be really helpful when I looked at MacOS as a unix environment and tried to engage in local development as if it were a unix environment.
[Un]fortunately, I've stopped looking at MacOS in this way. I now look at MacOS as the better version of ChromeOS that runs on non-shit hardware (two time PixelBook owner, both of them had serious hardware issues, and getting support from Google for what they view as throwaway devices is not at the same level as the Apple Store/Genius Bar experience).
Taking the view that MacOS is a fat client for apps and browser use, that is capable of also running [Uni|linu]x VMs, and pushing myself to adopt the "local editor, remote runtime" working model, has been really liberating.
I now no longer look at Homebrew as necessary. Instead, I can use package managers built for operating systems that are intended to work with package managers and that whole ecosystem, rather than fighting against Apple's efforts to improve the local security environment.
In many ways, I feel like I've come full circle to where I was at in the mid-00's, working in a SaaS/enterprise environment developing on Windows using VMs for actual dev work so as to keep my local machine safe, healthy, and productive.
Rather than dealing with the annoyance of Docker for Mac, I can instead just work in a VM running normal docker, or one of the competing solutions, and this translates very closely to what I run if I'm working against a VM.
And if you are doing anything "serverless" or "server-light", it's even less helpful to try and continue working with the MacOS terminal userland.
So, hats off to homebrew for all they do, but I really think the puck is moving elsewhere and that's where I'm headed instead.
I use homebrew on my personal machine mostly to get more modern versions of the terribly outdated commands that Apple ships but that's .. a small surface. I don't use it for anything really appropriate and would not.
Professionally - for people who build locally on the mac - the sheer awkwardness of pinning specific versions so all developers have a common environment regardless of install order or timeframe is quite painful with homebrew vs. apt.
There are a couple different ways to implement this type of workflow. You can use tools like VSCode's remote development features, you can use an IDE/editor with built-in rsync/sftp capabilities, you can also use git via a local command line (though that defeats the purpose), or a tool like Mountain Duck if you want to 100% eschew a CLI. Admittedly, for myself, I prefer to simply shell into a remote machine and use vim. But, that's "remote editor; remote runtime".
The remote runtime can be either a local Linux VM or a remote VM. That's kind of the beauty of this approach. You can generate a machine image and have a consistent environment either locally or remote, depending on your current needs. Obviously, when working with a local VM, you can use host mounted directories using one of the various tools for doing so, in a much more efficient manner.
I tend to not run git locally, but prefer to run it on my source on the remote environment. This is mostly because I'm not wanting to use the native Mac OS userland.
I do not run tests locally, that's very much the intention.
I don't have a link to an article handy. You already seem familiar with the VS Code tooling, so it's a good place to start.
I'm not a pedant about this. There are some rough edges, especially in the file sync'ing for the local editor, and integration with IDEs. But you can get most of the way there and be pretty happy.
edit...
When I was working on ChromeOS, the actual workflow was more like "host OS" -> "local VM" -> "remote VM". The Crostini environment itself runs in a local VM and container. So you would essentially be running an editor inside that local VM (I ran VSCode this way for a hot minute), and I was working with an sshfs mounted src directory from a remote VM. This was mostly because I was doing work against a dev environment that relied on a number of hosted services that were only accessible to the remote VM. The hoops we sometimes have to jump through...
[Un]fortunately, I've stopped looking at MacOS in this way. I now look at MacOS as the better version of ChromeOS that runs on non-shit hardware (two time PixelBook owner, both of them had serious hardware issues, and getting support from Google for what they view as throwaway devices is not at the same level as the Apple Store/Genius Bar experience).
Taking the view that MacOS is a fat client for apps and browser use, that is capable of also running [Uni|linu]x VMs, and pushing myself to adopt the "local editor, remote runtime" working model, has been really liberating.
I now no longer look at Homebrew as necessary. Instead, I can use package managers built for operating systems that are intended to work with package managers and that whole ecosystem, rather than fighting against Apple's efforts to improve the local security environment.
In many ways, I feel like I've come full circle to where I was at in the mid-00's, working in a SaaS/enterprise environment developing on Windows using VMs for actual dev work so as to keep my local machine safe, healthy, and productive.
Rather than dealing with the annoyance of Docker for Mac, I can instead just work in a VM running normal docker, or one of the competing solutions, and this translates very closely to what I run if I'm working against a VM.
And if you are doing anything "serverless" or "server-light", it's even less helpful to try and continue working with the MacOS terminal userland.
So, hats off to homebrew for all they do, but I really think the puck is moving elsewhere and that's where I'm headed instead.