Allow hot file host to be configure

[nurdism]

My PR was closed, opening an issue to explain my issue further.

adding

server: {
        https: true,
        host: 'foo.test',
        port: '8080',
}

does not resolve the host correctly. resolveDevServerUrl returns a hard coded ${protocol}://${host}:${port}. It resolves to https://[::]:8080 not https://foo.test:8080, but even then if I wanted to set host: 'foo.test', to host: '', it will still resolve to 'https://[::]:8080' not ''.

Even if I add host: 'foo.test', to my vite config and it did resolve correctly, I would still be running into an issue. I have vite on a reverse proxy on a different port, the vite server is listening on http://localhost:8080 (not publicly accessible to the internet) and but the public url is https://example.com, I am forwarding everything from https://example.com/resources*, https://example.com/@vite*, etc. to the vite server, but because the I cant override the hotfile. It tries to load from https://[::]:8080 witch I can not access publicly. There should be a way to override the hotfile host (even if undocumented) for edge cases like this.

Just to break it down a bit more:
I want to load resources/main.ts from the vite server, https://example.com/resources/main.ts forwards to http://localhost:8080/resources/main.ts (via a reverse proxy) the hotfile says the vite host is on https://[::]:8080, https://[::]:8080 can not be accessed from the internet, it throws a 404 the site does not load. If I set the hot file to '' it will now load from https://example.com/resources/main.ts.

Now there is an argument to "Don't run a dev server exposed to the internet" but in my case I am actually running this on an intranet for clients to get fast feedback on small incremental changes to the front end design.

[timacdonald]

@nurdism thanks for following up about this after I closed the PR.

I'm unable to replicate this on my local machine, so I might need some additional information for you about your setup.

For example, running the following script I get the expected contents in the hot file that I mentioned.

composer create-project laravel/laravel vite-test \
  && cd vite-test \
  && npm install \
  && echo "import { defineConfig } from 'vite';
import laravel from 'laravel-vite-plugin';

export default defineConfig({
    plugins: [
        laravel({
            input: ['resources/css/app.css', 'resources/js/app.js'],
            refresh: true,
        }),
    ],
    server: {
        https: true,
        host: 'foo.test',
        port: '8080',
    }
});" > vite.config.js \
  && npm run dev 

Console output

Hot file contents

[nurdism]

@timacdonald I'm actually getting an error from vite when I attempt to run your example

error when starting dev server:
Error: getaddrinfo ENOTFOUND foo.test
    at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:109:26)

After looking at the vite docs, the host option is supposed to resolve to an ip address:

Specify which IP addresses the server should listen on. Set this to 0.0.0.0 or true to listen on all addresses, including LAN and public addresses.

not a domain, a better option to grab from would be server.origin

[nurdism]

Looking at the plugin again, I see you are overriding the origin and transforming it later. I don't think this is a very good approach as now the underlying software (vite) does not preform as intended. I'm going to experiment with this and see if I can come up with a workable solution, is there a particular reason the origin has to be so strictly enforced to ${protocol}://${host}:${port} and is being overridden like this?

[timacdonald]

@nurdism you should just switch foo.test with whatever IP / domain you want the server to listen on. foo.test works on my machine because I have it configured to work with .test domains.

That functionality you have linked to is the essence of the Laravel plugin. Without it, the Laravel integration simply would not work across the boundaries that exists between the PHP process and the Node process.

Feel free to comment or open a PR if you believe you can improve things further. Additionally you may want to create a reproduction repository of the issue so we can better understand the issue you are facing.