Skip to content
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

Respect Vite's "server.origin" option. #568

Closed
pavlo-tk opened this issue Jun 5, 2023 · 1 comment · Fixed by #690
Closed

Respect Vite's "server.origin" option. #568

pavlo-tk opened this issue Jun 5, 2023 · 1 comment · Fixed by #690

Comments

@pavlo-tk
Copy link

pavlo-tk commented Jun 5, 2023

Hello,

I noticed that while running Vite's dev server, URLs for images generated by vite-imagetools are relative (i.e. /@imagetools/c224b1fb8dcc644a0adf403cda4d43b3390bbf1f). For the most part, this is fine, but as soon as you're integrating with the backend, these relative paths break images.

Vite has server.origin option specifically for these cases: https://vitejs.dev/config/server-options.html#server-origin
It's also explained in the "Backend Integration" section in their docs: https://vitejs.dev/guide/backend-integration.html:

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

1. Make sure the server is configured to proxy static assets requests to the Vite server
2. Set `server.origin` so that generated asset URLs will be resolved using the back-end server URL instead of a relative path
This is needed for assets such as images to load properly.

Right now the only way to work with vite-imagetools while the app is integrated with any backend is to rewrite URLs server-side (Apache, NGINX).

It would be nice if vite-imagetools would respect server.origin option and we could stop hardcoding those rewrite rules.

@jrmyio
Copy link
Contributor

jrmyio commented Jan 26, 2024

Created a PR for this:
#690

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants