-
-
Notifications
You must be signed in to change notification settings - Fork 6.7k
Allow to use different base
for dev server and generated import paths
#19980
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I'd recommend configuring the reverse proxy to keep the prefix if possible as that's much simplier. |
I'm not sure if I get what you are suggesting with |
The imports in the generated code always should have the prefix, both in dev as well as in prod. However, the dev server should not mount the root of the project under the prefix, but rather under '/'. This is for a setup where multiple sub products run in different containers, and there is a reverse proxy in the front that distinguished by the prefix to which container to forward each request. However, the reverse proxy will strip the prefix. The Foo app could run on The reverse proxy on A request to So I need the Vite dev server to generate import URLs in the form of |
Then, I think the plugin I linked in #19980 (comment) would work. |
@sapphi-red is there already an NPM package for that which we can import? |
I'm not aware of any existing package. |
Description
As a developer using Vite in development mode, I want to configure the prefix used to generate the import paths separately from the prefix used by the dev server, so that I can run Vite in dev mode in a scenario with a reverse proxy that forwards traffic to different applications based on a URL prefix but removes that prefix when forwarding the request.
Currently, I can only set
base
in the Vite config which will apply both to the prefix used by the dev server and to the import paths.Suggested solution
Add an option
server.base
that can override the sharedbase
option. With this, we could do:Alternative
Alternatively, the overriding option could be added as
build.base
:Additional context
No response
Validations
The text was updated successfully, but these errors were encountered: