Hello, everyone. Just a few minutes ago I had a troubleshooting session with one of my devs (a new one). "client-env is not loading (gives 404)", was the main issue. We clicked on devtools, Network, client-env. URL reads: http://localhost:4100/@id/client-env.js. "Well, why did you add that @id part to the URL ?", I asked arrogantly! LOL. Turns out, he didn't. Source code reads import env from "@project/client-env;. This @project/client-env is a bare specifier that goes through ID resolution as per Vite's pipeline.
We have a small plug-in in place with the resolveId hook with a simple if statement: If the id is @project/client-env, return public/client-env.js, because the actual JS file is in the public folder because we don't want it bundled, which brings me to: We have rollupOptions.build.externals set to a one-element array that excludes @project/client-env, but this shouldn't matter because when the project is built, everything is OK. This @id thing is only happening with npm run dev.
To summarize, I have no explanation to the matter. I could only suspect of Vite itself. We were using v5.0.11. So we started changing Vite's version. Version 5.0.5 had the same behavior, but then we moved to Vite v4, latest (I think it is v4.5.0). With Vite v4 inserts @fs instead of @id. But the weirdest thing is: It correctly serves the contents of public/client-env.js!!
So my question is twofold (+ 1):
- Why is this happening? Why is Vite adding stuff to the URL's?
- Why does it work even with a wrong url with @fs in it?
- Should I be doing something differently?
Thanks for your time.