vite-plugin: Dev server ping fails with secured Valet site

Hey, so I just tried and at least the following server configuration is needed for https to work and the websocket to connect:

import { defineConfig } from 'vite';
import laravel from 'laravel-vite-plugin';

export default defineConfig({
    plugins: [
        laravel([
            'resources/css/app.css',
            'resources/js/app.js',
        ]),
    ],
    server: {
      https: true,
      hmr: {
        host: 'localhost',
      }
    }
});

The host is necessary because otherwise the websocket will try to connect using location.hostname.

@jessarcher I think the hmr host should always be set, and https should be auto-determined depending on APP_URL, like vite-plugin-laravel does.

I haven’t looked into why ws://browser-hostname works and wss://browser-hostname doesn’t, but setting the host to the dev server’s host works in both cases.

This is probably not Valet related. I have the same issue serving the local dev site with Lando (Docker).

I had the same problem, I fixed it by adding the key and certificate as I already did with laravel mix.

I created an article to show this working.

👉 https://dev.to/paulocastellano/how-to-make-vite-valet-and-ssl-works-together-5hbb

I’m not shutting down the idea at all, just sharing a perspective. Will chat to Jess more about it and maybe have a play with the idea a bit more.

Thanks for all the discussion folks ❤️

@jessarcher thanks a lot! Glad this is documented now, and I think accepting the additional certificate is a good workaround.

I still think it makes sense to use APP_URL to do even more automatically when possible. This won’t cover absolutely every use case, but I think it actually is—usually—directly related to the URL that the site is being viewed at.

Thanks for reporting this, @bakerkretzmar.

The __vite_ping issue is known and will be fixed in Vite 3 as mentioned by @innocenzi.

I don’t have a Mac (and therefore Valet) to reproduce the socket issue, but I’ll check it out with @timacdonald’s help tomorrow.

@timacdonald I still think APP_URL is a good heuristic - it should correspond to most defaults, and one can override the server configuration anyway.

I can confirm we still need to accept the certificate, but we indeed need to do that only once. Laravel Vite auto-detects Valet and Laragon certificates and uses them, which reduces the configuration needed by the user to get https working.

I don’t think it’s bad to have good defaults that would work in a lot of cases, even if not all of them.

That’s a good point @timacdonald.

Also, if no one provides a server.host setting, the hot file will get https://127.0.0.1:3000 (auto-detected from the Vite dev server) while the Vite client will auto-detect wss://valet-vite.test:3000 from the browser, meaning that the user would need to accept two certificates, in addition to the one they already have to accept at https://valet-vite.test.

Until we can think of something more reliable, I think we’ll just document adding this to vite.config.js:

server: {
    https: true,
    host: 'localhost',
}

And then to make sure to visit the following link to accept the certificate:

This is only an issue with Vite 2.x, the ping works differently in Vite 3.x which will be released in the upcoming days/weeks (see https://github.com/vitejs/vite/pull/6819). I’m not even sure if this is fixable on our side because the ping uses the base URL, which must be /.