-
Notifications
You must be signed in to change notification settings - Fork 26
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
Assets are loaded from single spa url instead of microfrontends #13
Comments
I have the same issue. Opened it in the other repo for single spa and vite (joeldenning/vite-single-spa-root-config#2) |
I am facing the same issue. did you guys able to find a fix for this? |
+1 |
I found a solution: Set the export default {
...
server: {
origin: 'http://localhost:3000',
},
} --> vite reference to Additionally you need import the asset via javascript to get it's url. Apparently only then the url gets adjusted from vite automatically: <script setup>
import logo from "./assets/logo.png"
</script>
<template>
<img alt="Vue logo" :src="logo" />
...
</template> Edit: I just noticed that for some reason, you have to reinstall the dependencies, so delete the |
I even found a solution that does not need to import the asset via javascript but makes use of the import { fileURLToPath, URL } from 'url'
export default {
...
server: {
origin: 'http://localhost:3000',
},
resolve: {
alias: {
"@": fileURLToPath(new URL("./src", import.meta.url)),
},
},
} You can then import it with the <template>
<img alt="Vue logo" src="@/assets/logo.png" />
...
</template> A relative path |
@jones1008 the problem is that it also happens with bundles that were split. It could be a CSS bundle, an async Vue component that got into another bundle. And informing the URL it is going to be deployed sounds more like a quick fix and anti-pattern than a solution. Don't you think? |
yes... you may be right... |
I clone the project and run it without changing anything and microfrontend is unable to pull the assets from correct url.
Microfrontend tries to fetch assets from root-config server instead of his own.
The text was updated successfully, but these errors were encountered: