We are only interested in whether this override is set or not. Using whether we are operating on localhost or 127.0.0.1 is incorrect. There are two modes of usage:
Via the APL code. This uses one single port for everything, and doesn't care about vite. Only that it has the build artefacts. This is how customers are mostly expected to use the tool.
Developers who are customising the JS side - they can set the env var and use it so they can load the page via :5173 and then make calls to :22322 (or any other custom port).
Also includes removing a couple of unnecessary warnings that are mistakes in the code, rather than the build being too strict.
So:
VITE_APL_URL overrides everything, this also enables a setup where one might have a local JS instance talking to a remote APL instance.
If the Vite DEV env var is found, a popup is shown with the exact instructions to populate a .env file.
This works whether accessing through the APL server (which only has the build artefacts) and via vite.
We are only interested in whether this override is set or not. Using whether we are operating on localhost or 127.0.0.1 is incorrect. There are two modes of usage:
Also includes removing a couple of unnecessary warnings that are mistakes in the code, rather than the build being too strict.
So:
This works whether accessing through the APL server (which only has the build artefacts) and via vite.