The longer answer is, earlier in my career I ended up spending a not-insignificant amount of time helping people debug things, and about 70% of the time the issue was their local build environment. Everyone did it differently and it was very messy.
I only made a few "rules" to follow. 1.) Your local folder structure must mirror exactly the structure in our central repo. 2.) Must use relative paths, which works when you follow rule 1. 3.) No ad-hoc "new shiny things" without team buy-in. If it can be used locally only and won't affect the team obviously I don't care.
Do you use a monorepo at work, or do you have like a repo for a 'local dev environment' or something like that?
Eventually I forced everyone to work with a controlled dev environment on a remote server. They can work over ssh with command line tools or VSCode. Dev environments get rigorously maintained to mirror production. I got some grumbling about latency (everyone works remotely from around the world), but that turns out to present much less friction than the almost-daily debugging sessions and dealing with MacOS vs Windows vs Linux inconsistencies.
I have staunchly refused to allow this at my current employ, and I’ve been there long enough where I can steer this.
This isn’t acceptable and all it does is help introduce inconsistency and regressions.
I realize I am fortunate in that I can effect change at my job in this arena.