It's easy to follow, it's a knee jerk tribalism reaction and not a logical or informed one. Go attracts backend or anti-frontend people so anything intermingling the two will draw out the commenters who bemoan anything that realistically builds a modern website. Just ignore it, your choice for dev tooling is practical and makes sense to me.
As someone who has had to clean up systems that only did a _npm install_ to get compromised, despite being good Renovate citizens, it doesn't matter if it is not "on the production path".
I don't care to hear arguments about how npm was _configured wrong_.
A tool with insecure defaults, with a long and storied history of being the vector by which data has been exfiltrated and companies hacked, needs to do an awful lot to justify still being used for any infrastructure our team is responsible for.
The proxy caches and package solution for Go has had its own drama.
My big contention with this project is that if I wanted to use node (or npm; or vite) in any capacity, I would have chosen node for that. I don’t want to use those tools in this context because it serves me worse than a well thought out solution.
The thought out solution is to isolate your frontend into its own directory. You can embed and serve that as part of your Go server. That frontend could have been done with react, vite, jsx, whatever typescript nonsense you want; without the Go parts necessarily needing npm or node in the build process.
