On linux my experience is typically more like:

My tools, as in programs I personally use -> pretty much entirely Brew, in fact I think on my current workstation this category is 100% brew-installedĭependencies of anything I'm working on -> some language-specific version manager (which itself is may be brew-managed, actually) plus containers or VMs with scripted installs, probably. If I need something at a particular version I'd use a container, or install it manually in some isolated folder, or something like that, since odds are if I need something at a particular version I'm going to need it at multiple particular versions and to be able to re-create the installation on other environments. I use it to install tools I'll use directly, so I practically always want those to be at latest (or otherwise don't really care what version they are). I think I must use it differently from how other people do. With a network/host-guest filesystem, meanwhile, every filesystem metadata change must become its own synchronous message to the host, to be pushed to the host’s filesystem driver for linearization, so it can succeed or fail relative to other things going on within the host.) (The efficient thing about this class of solutions, if you’re wondering, is that the client mounting the loop-image ends up owning + managing the loop-image’s internal filesystem’s metadata within its own local disk cache, such that it can coalesce filesystem metadata writes and only push a new copy of the disk-image blocks backing the filesystem metadata after a potentially-huge number of changes. (It’s also what Apple themselves do for running Time Machine over SMB: they create a sparsebundle image on the remote and mount it locally, and write to that.)

It certainly is when wrangling a directory with lots of tiny inodes over SMB.

Creating and mounting a loop-volume within the HGFS and then running NPM in there, would probably also be helpful.

Docker on mac silicon