-
-
Notifications
You must be signed in to change notification settings - Fork 6.2k
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
@vitejs/plugin-vue does not allow absolute asset URLs to be preserved as-is #4836
Comments
I should note that I filed the issue in this repo instead of vue-next because it seemed to be an issue with @vitejs/plugin-vue as opposed to something like @vue/compiler-sfc. However, I can re-file the issue in vue-next if needed. |
The issue is that @vitejs/plugin-vue is forcing vite/packages/plugin-vue/src/template.ts Lines 127 to 131 in fbd143a
This is clearly intentional, but there's no escape hatch to treat those URLs as-is without running them through the asset plugin. The asset plugin itself has handling for absolute URLs, but only if it can resolve them in the filesystem based on the configured public path. vite/packages/vite/src/node/plugins/asset.ts Lines 52 to 57 in fbd143a
On the one hand, I see how this fits the typical use case of Vite, but it does make it less usable when the Vite build is just one part of the tree that is served by the web server. |
This is indeed a potential issue with back-end frameworks integration. I use the same workaround ( I would like to provide an escape hatch for this, and ideally something that would not necessarily be in the Maybe even having better heuristics for determining when |
@innocenzi I think we could keep this issue close and create a more focused issue on the idea of other plugins modifying plugin vue options. That I think it is good in general, maybe plugin-vue could use the API scheme that we use in plugin-react for babel plugins to enable any other plugin to add Vue options, and then it will merge all. |
I'm fine with that idea yes, thanks 👍 I'll come back to this issue later once the official integration from the Laravel team is done |
Describe the bug
I've been experimenting with using Vite with WordPress, in place of an existing Webpack config. I've mostly gotten it working, but I can't find an elegant way to handle absolute paths when doing things like
<img src="/my/absolute/path.png">
in my (Vue 3) SFCs.For example, if I do
<img src="/wp-content/themes/ff-bulma/assets/images/close-button.png" alt="Close">
, I want it to request that absolute path as-is, instead of trying to resolve it as a module, because the backend is already serving the image at that path.When doing a
vite build
, Rollup sees those paths as module imports and attempts to resolve them, resulting in a failed build. If I set......then at least Rollup stops complaining, but the bundled script itself tries to import the PNG as an ES module and gets blocked by the browser "because of a disallowed MIME type (image/png)". Setting
template: { transformAssetUrls: false }
in the Vue plugin config has no effect.The only way I've found to make it work is to do
<img :src.attr="'/wp-content/themes/ff-bulma/assets/images/close-button.png'" alt="Close">
in my Vue SFC, but it seems like there should be a way to handle it via config, especially since I had it working when using Webpack.To put it another way, I've been relying on vue-loader's documented behavior, where "If the URL is an absolute path (e.g. /images/foo.png), it will be preserved as-is." I am looking for a way to get the same behavior with @vitejs/plugin-vue.
Reproduction
Here's a simplified example:
https://stackblitz.com/edit/vue-3-coaches-2blvac?file=my-absolute-path/src/App.vue
The whole dir is being served by http-server, and Vite builds from /my-absolute-path/src/ into /my-absolute-path/dist/. Look in App.vue for examples of
<img src>
.Uncomment
external: [/^\/my-absolute-path\//]
in vite.config.js to eliminate the Rollup error. However, this introduces a MIME error in your browser, due to the browser trying to load the SVG asset as an ES module.Now, comment out the
<img>
tag in App.vue that is labeled as not working on Vite, and you can confirm that the other one always works (even with thatexternal
line commented out in the config). However, the one that does works is not ideal for DX, and is not necessary when using vue-loader with Webpack.System Info
Used Package Manager
pnpm
Logs
Validations
The text was updated successfully, but these errors were encountered: