vitejs / vite

Next generation frontend tooling. It's fast!
http://vite.dev
MIT License
68.81k stars 6.22k forks source link

Support relative base path on dev server #18612

Closed juan-rvty closed 2 weeks ago

juan-rvty commented 2 weeks ago

Description

Expanding on: https://github.com/vitejs/vite/issues/17482 Our app, which we will call A, runs inside another app B, not developed by us. App B can spawn different instances of A inside iframes, in URIs like: app-b.com/home/{id generated for instance}/index.html.

So in dev, as the routes are absolute, and we cannot know beforehand the id, it simply does not work.

We know it´s a very special use case, but it is the one we are facing. Going back to craco delays our CI build by ~7 minutes per build.

Suggested solution

 const config = {
  base: './'
}

Alternative

No response

Validations

sapphi-red commented 2 weeks ago

In your case, I guess you can workaround it by proxying all app-b.com/home/{id generated for instance}/ to app-a.com/.

juan-rvty commented 2 weeks ago

I don´t have control over B. And that ID on the URI is not known beforehand. A makes an absolute request to /src/components/mycomponent.jsx, in dev is absolute, in build it would be relative. So it goes to app-b.com/, I cannot proxy to app-b.com/home/{id generated for instance}/, each Instance of A has to proxy to the apropiate {id generated for instance}/

sapphi-red commented 2 weeks ago

What can be served from app-b.com/home/{id generated for instance}/? Is it only possible to specify a static file?

juan-rvty commented 2 weeks ago

From there files mostly yes, right now during dev we redirect the requests from there to localhost:3000 (craco). In vite we have tried the same, but as mentioned before, the problem is after the first request, the index.html goes fine, but all the relative URLs inside the index.html are converted to absolute by the vite server.

I mean it would also work, if there was a possibility for vite to keep the path that it finds.

sapphi-red commented 2 weeks ago

during dev we redirect the requests from there to localhost:3000 (craco).

Just to confirm, you mean requests are proxied to localhost:3000 rather than a redirect (HTTP redirect (e.g. 302) or <meta http-equiv="refresh">), right?


I guess supporting server.origin in HTML files (#18457) can solve your case. If that were implemented, you can set server.origin: 'http://localhost:5173', then the non-HTML requests would bypass app B and reach the Vite server in the correct path.

juan-rvty commented 2 weeks ago

during dev we redirect the requests from there to localhost:3000 (craco).

Just to confirm, you mean requests are proxied to localhost:3000 rather than a redirect (HTTP redirect (e.g. 302) or <meta http-equiv="refresh">), right?

Yes we proxy them to localhost:3000 this is all the control we are allowed to have on that part.

I guess supporting server.origin in HTML files (https://github.com/vitejs/vite/issues/18457) can solve your case. If that were implemented, you can set server.origin: 'http://localhost:5173', then the non-HTML requests would bypass app B and reach the Vite server in the correct path.

It indeed does sound like it would work. Would the rest of assets work correctly? js files that import other js files etc

juan-rvty commented 2 weeks ago

Facing the same problem as https://github.com/vitejs/vite/issues/18457#issuecomment-2436938091

sapphi-red commented 2 weeks ago

Would the rest of assets work correctly? js files that import other js files etc

Yes.

I'll close this issue as a duplicate of #18457 then.