Closed nurdism closed 9 months ago
Looking at the issues and other PRs, I can see this could solve a few issues. There are countless edge cases where the hot file and origin could not be configured correctly automatically. This approach just respects what is configured by the user in server.origin
in the original vite config.
Another approach it to just let us configure the viteDevServerUrl
via the PluginConfig
I would love to have this PR merged. I have a project running locally in Laravel Sail behind a reverse proxy, so while Vite is running inside of docker, the browser has to load the assets from the domain managed by the reverse proxy.
I'm using this fork and it's working perfectly. It also makes sense to use server.origin
since it's its purpose: https://vitejs.dev/config/server-options.html#server-origin
for a workaround/temp fix you can use something like patch-package
laravel-vite-plugin+0.8.1.patch
diff --git a/node_modules/laravel-vite-plugin/dist/index.cjs b/node_modules/laravel-vite-plugin/dist/index.cjs
index 00b1be6..6a444da 100644
--- a/node_modules/laravel-vite-plugin/dist/index.cjs
+++ b/node_modules/laravel-vite-plugin/dist/index.cjs
@@ -131,7 +131,7 @@ function resolveLaravelPlugin(pluginConfig) {
const address = server.httpServer?.address();
const isAddressInfo = (x) => typeof x === "object";
if (isAddressInfo(address)) {
- viteDevServerUrl = resolveDevServerUrl(address, server.config, userConfig);
+ viteDevServerUrl = userConfig.server?.origin ? userConfig.server.origin : resolveDevServerUrl(address, server.config, userConfig);
import_fs.default.writeFileSync(pluginConfig.hotFile, viteDevServerUrl);
setTimeout(() => {
server.config.logger.info(`
diff --git a/node_modules/laravel-vite-plugin/dist/index.mjs b/node_modules/laravel-vite-plugin/dist/index.mjs
index eee8f31..c4178a0 100644
--- a/node_modules/laravel-vite-plugin/dist/index.mjs
+++ b/node_modules/laravel-vite-plugin/dist/index.mjs
@@ -100,7 +100,7 @@ function resolveLaravelPlugin(pluginConfig) {
const address = server.httpServer?.address();
const isAddressInfo = (x) => typeof x === "object";
if (isAddressInfo(address)) {
- viteDevServerUrl = resolveDevServerUrl(address, server.config, userConfig);
+ viteDevServerUrl = userConfig.server?.origin ? userConfig.server.origin : resolveDevServerUrl(address, server.config, userConfig);
fs.writeFileSync(pluginConfig.hotFile, viteDevServerUrl);
setTimeout(() => {
server.config.logger.info(`
@nurdism I'm wondering if this can be handled using the server.proxy
configuration option instead of making changes here in the plugin?
@timacdonald The issue is the hot file not echoing the correct url, it breaks the HMR and assets regardless of what I set for the proxy inside the dev server. The hot file is loading the base url for HMR and assets on the vite server. No matter how I proxy it on the dev server, the url will continue to not be accessible on my browser. I don't have access to the vite server via any localhost as its not on my local machine its all remote, in a container. I only have access to the configured domain via a reverse proxy to the remote dev server.
Gotcha.
I think this fix makes sense.
When running vite behind a reverse proxy, often you can get into situation where your publicly facing URL differs from the internally served URL, I am running into such an issue.
My vite server is being served on
http://0.0.0.0:8080
, I am reverse proxyinghttp://0.0.0.0:8080
(via nginx) over to a domainexample.com
, so the publicly facing URL for my vite server ishttps://example.com
. My browser has 0 access tohttp://0.0.0.0:8080
, it is on a remote machine inside a container. I only have access to it via the reverse proxy.This is usually solved by setting the
server.origin: 'https://example.com'
so all assets from vite are pointed to the right domain and location. But thisvite-plugin
does not respect the user configuredserver.origin
and renders the plugin unusable in an environment that is using a reverse proxy in such a manor.