Issues with the hotfile and the host configuration

[Madscientiste]

Currently the hot file will only store one interface address

eg: vite --host 0.0.0.0 will output http://0.0.0.0:7894, However you cannot connect to 0.0.0.0 directly.

Let say you have a system that has 2 network interfaces like 10.5.0.5 and 172.26.80.1, so then you can connect to either of these externally, and 127.0.0.1 internally

So having http://0.0.0.0:7894 is not valid.

what i've done to fix this is (as a workaround for now), i just put all my network addresses ( that vite already gives me ) in the hotfile
eg: vite --host 0.0.0.0 will give me

➜  Local:	http://localhost:7894
➜  Network: http://192.168.1.182:7894
➜  Network: http://192.168.137.1:7894
➜  Network: http://172.26.80.1:7894

and tell laravel to use whatever host is being used.

if i go to my laravel url (http://172.26.80.1:8000), it will give me

<script type="module" src="http://172.26.80.1:7894/@vite/client" />
<script type="module" src="http://172.26.80.1:7894/resources/js/app.jsx" />

There are other issues like it outputs the ipv6 loopback http://[::1]:7894 when no --host is given
which also doesn't work when fetching the assets.

And also where the given base isn't appended at the end, eg: when i set my vite.config with base: '/something/'
i expect also to have http://172.26.80.1:7894/something in my hotfile

But i think there are open or closed issues regarding these 2 ...

I'm not sure if i was clear enough with my explanation, i hope it make sense 😅
and please do tell me if there is anything i can help out with 👍

My configuration

• Laravel Vite Plugin Version: 0.7.3
• Laravel Version: 9.48.0
• Node Version: LTS-18.12.1
• NPM Version: 8.19.2
• Host operating system: Windows 11
• Running in Sail / Docker: No

[jessarcher]

The issue of not being able to connect to 0.0.0.0 is a known issue with Windows. On Mac and Linux it behaves similarly to the loopback address when connecting to it. I'm not aware of a great solution for Windows yet - it's hard to simultaneously tell Vite to listen on all addresses but then only be able to use one of those addresses for asset links.

What should an ipv6 loopback address look like on Windows if not what is currently provided?

If you need to access it via ipv4 loopback, does it work if you specify the host as either localhost or 127.0.0.1?

If you want to access it externally, can you specify the exact address you want? I know this is a bit inconvenient if your address changes, but the only other thing I can think of is to maybe prompt with all of the detected addresses so that a specific address can be selected. I don't know if that is possible unless it could block Vite from loading until an answer is provided.

As for the base option, I can't remember off the top of my head if there's a specific reason why it doesn't get added to the hot file. What is the use case for changing it from the defaults?

[Madscientiste]

The issue of not being able to connect to 0.0.0.0 is a known issue with Windows. On Mac and Linux it behaves similarly to the loopback address when connecting to it.

From what i've read, 0.0.0.0 is not meant to be routable. It's a special address that means "any address". So it's not meant to be used to connect to a server, which is why it's not working on windows.

it's hard to simultaneously tell Vite to listen on all addresses but then only be able to use one of those addresses for asset links.

I think there is a missunderstanding here... since vite will listen to all addresses, you can use any of those addresses to access the assets.

Let say vite, is listening to 192.168.1.182 & 172.26.80.1 on port 7894.

then http://192.168.1.182:7894/asset.js and http://172.26.80.1:7894/asset.js will both work.

Vite by itself does it, you can test that by creating a vanilla vite project and running vite --host 0.0.0.0,

then going to one of the addresses that vite is listening to, and you will see that the assets are loaded from the same address as the one you are using to access the page.

there are probaly better explanations out there, i hope what i said make sense ..

If you need to access it via ipv4 loopback, does it work if you specify the host as either localhost or 127.0.0.1?

i'm not sure what you mean by that..

but if we say the host is 127.0.0.1 then you will be able to access the assets from either localhost or 127.0.0.1 and not from any other address, but i don't think that was your question 😅

If you want to access it externally, can you specify the exact address you want? I know this is a bit inconvenient if your address changes, but the only other thing I can think of is to maybe prompt with all of the detected addresses so that a specific address can be selected. I don't know if that is possible unless it could block Vite from loading until an answer is provided.

I think laravel should resolve the appropriate address to use, the host of laravel should match the one on vite's side or at least be able to configure that.

if i'm navigating to http://169.254.123.57:8000/ (laravel app) then the assets urls should have the same host as laravel's http://169.254.123.57:5789/myasset.js

we can do that by getting the current host of the request

for example request()->getHttpHost() will return 169.254.123.57:8000 and we can use that to build the asset url.

i'm not sure if we need to put all the addresses in the hot file though, we might need only the hot file and omit the addresses if laravel resolves it that way 🤔

Sources

• https://superuser.com/questions/949428/whats-the-difference-between-127-0-0-1-and-0-0-0-0/949522#949522
• https://superuser.com/questions/1307050/how-does-the-os-resolve-a-request-to-connect-to-0-0-0-0
• https://stackoverflow.com/a/21057974/11383209

---

As for the base option, I can't remember off the top of my head if there's a specific reason why it doesn't get added to the hot file. What is the use case for changing it from the defaults?

If you specify a base path to vite, it means all the assets will be served from that base path. so if you have a base path of /somebasepath then all the assets will be served from http://localhost:3000/somebasepath/asset.js instead of http://localhost:3000/asset.js. This is useful if you want to serve vite from a subpath of your domain.

Maybe public base path is a better name for this option, but it's already called base in the vite config so I just kept it the same. sorry if this was confusing

Vite doc : https://vitejs.dev/config/shared-options.html#base

[jessarcher]

Hey @Madscientiste,

I'm open to looking into how we could do this, but there are scenarios that complicate things (which are also complicated to explain!). I'll do my best to explain, even if just to help myself remember how this all works in order to think of a potential solution.

For example, imagine you have:

• An image at resources/images/foo.jpg

• A resources/css/app.css file like this:

  .foo {
      background-image: url('../images/foo.jpg')
  }

• A resources/js/app.js file like this:

  import '../css/app.css'

If we ignore the Laravel Vite plugin for a second, in Vite's "serve" mode, it makes the image available via the Vite dev server (e.g. at http://localhost:5173/resources/images/foo.jpg) and will update the URL in the CSS to be /resources/images/foo.jpg.

If we're running a Laravel dev server (e.g. at http://localhost:8000) and load the JavaScript from the Vite dev server at http://localhost:5173/resources/js/app.js, then Vite will dynamically insert the compiled CSS from the imported app.css into a <style>...</style> tag on the page. It does not link to the CSS file.

Unfortunately, the URL in the CSS (/resources/images/foo.jpg) doesn't specify a host, so it will be requested via the host where the CSS came from. Because this was dynamically injected into a <style>...</style> tag on the page that we're accessing at http://localhost:8000, the browser will try to load the image file from http://localhost:8000/resources/images/foo.jpg instead of from Vite at http://localhost:5173/resources/images/foo.jpg.

To work around this, the Laravel Vite plugin configure Vite's server.origin option to make Vite generate full URLs that point back to itself (e.g. http://localhost:5173/resources/images/foo.jpg instead of just /resources/images/foo.jpg).

This is where it gets really complicated.

At the time when we configure server.origin, the Vite dev server hasn't yet started, so we don't know what address(es) it will have. So, we set server.origin to __laravel_vite_placeholder__:

vite-plugin/src/index.ts

Line 140 in 453a39b

origin: userConfig.server?.origin ?? '__laravel_vite_placeholder__',

This will result in that image URL being written as __laravel_vite_placeholder__/resources/images/foo.jpg in the compiled CSS.

We then use a transform hook at runtime to replace __laravel_vite_placeholder__ with the Vite dev server address that we've detected:

vite-plugin/src/index.ts

Lines 180 to 186 in 453a39b

	transform(code) {
	if (resolvedConfig.command === 'serve') {
	code = code.replace(/__laravel_vite_placeholder__/g, viteDevServerUrl)
	return pluginConfig.transformOnServe(code, viteDevServerUrl)
	}
	},

The detection is based on any user Vite config overrides, but by default, it will be the address reported to us by Vite's dev server, which by default will be 127.0.0.1 (or the ipv6 equivalent) and so the image URL will be written as http://127.0.0.1:5173/resources/images/foo.jpg, which is what we want.

If you've changed the host to 0.0.0.0 to listen on all addresses, that is also the address that the Vite dev server will give to us (or the ipv6 equivalent) as it only provides a single address. We have no way of knowing which address you'll actually be accessing Vite on, so we leave the 0.0.0.0 intact. At this point, we have no way of accessing Laravel's request()->getHttpHost() so even if we were to use that address to load the initial JavaScript, the subsequent request for the image would fail.

Leaving the 0.0.0.0 intact works okay on Linux and macOS because both operating systems will resolve that to 127.0.0.1 when trying to connect to it (as opposed to "all addresses" when listening on it). This doesn't work if you're not on the same machine as the Vite dev server though.

I hope that all makes sense.

I am curious whether we can check the requested address made to Vite during the transform hook and dynamically update the placeholder with whichever address Vite is being accessed on 🤔

Edit: I can't find a way to determine the requested host during the transform hook. The current request is not passed to this hook, and due to the async nature of things, I don't think we can safely capture it during a request middleware to retrieve later, as there are no guarantees it will have been set by the same request. I've tried installing a post middleware to manipulate the output there instead, but it does not seem to be called.

[Madscientiste]

Yeah it make more sense to me now, i do have kind of solution not sure if its a good idea but anyway :

So vite docs says:

In order to properly serve assets, you have two options:

• Make sure the server is configured to proxy static assets requests to the Vite server
• Set server.origin so that generated asset URLs will be resolved using the back-end server URL instead of a relative path

So i was thinking, using a reverse proxy (eg: ngnix) this can be solved, prefix the assets urls with /:vite:/ and redirect it the vite dev server .. but how about instead, we let laravel handle this while vite is running ?

i tested this and its seems to work, now maybe there are issues with that...

Here is how i've done it:

• Create a new laravel project
• Setup vite.config.js to use server.origin with /:vite: instead
• Have an image at resources/images/foo.jpg
• A resources/css/app.css with:

.foo {
    background-image: url('../images/foo.jpg')
}

• A resources/js/app.js that imports import '../css/app.css'
• Go to routes/web.php and add this route:

Route::get('/{vite}', function () {
    $uri = str_replace(':vite:/', '', request()->getRequestUri());
    $host = request()->getHost();

    $vitePort = 5173; // this can be fetched from the hotfile or by a given configuration

    return redirect()->to("http://" . $host . ':' . $vitePort . $uri);
})->where('vite', ':vite:(.*)');

What do you think about this approach ? @jessarcher

Edit: forgot to mention, i also have "patched" locally Illuminate\Foundation\Vite::hotAsset with this:

    protected function hotAsset($asset) {
        $reqHttpHost = request()->getSchemeAndHttpHost();

        $protocol = explode(":", $reqHttpHost)[0];
        $host = str_replace("//", "", explode(":", $reqHttpHost)[1]);

        $viteHttpHost = rtrim(file_get_contents($this->hotFile()));
        $vitePort = explode(":", $viteHttpHost)[2];

        return sprintf("%s://%s:%s/%s", $protocol, $host, $vitePort, $asset);
    }

[jessarcher]

Hey @Madscientiste,

Interesting idea. It feels a bit weird to route asset requests via Laravel. The redirect would also result in double entries for each asset in your network tab, right?

I think my preferred solution would be to see if we could PR Vite with an option to prefix URLs with whatever host it was requested on. I might hack around with it once Laravel 10 is released and things have settled down.

[Madscientiste]

The redirect would also result in double entries for each asset in your network tab, right?

Yep

But then if i let laravel 'serve' the assets (no redirect):

I think my preferred solution would be to see if we could PR Vite with an option to prefix URLs with whatever host it was requested on. I might hack around with it once Laravel 10 is released and things have settled down.

alright 👍

[driesvints]

@jessarcher what should we do with this issue going forward?

[jessarcher]

@driesvints it's on my todos to PR Vite.

In the meantime, a specific host address can be specified, instead of 0.0.0.0, when sharing on the local network.