@bluwy we have a project with 100+ devs waiting on this fix, is there a way to accelerate this? :)

Waiting on this one to be merged

I've added this to the team board for discussion. I'm unsure if this is the way we want to support externalizing things, because now a build option would affect a non-build flow, and this could indirectly expand to other flows if we don't define a scope.

This will also be indirectly covered by #11138 (comment). I've bumped up the priority on this for the next meeting.

In a recent meeting, we decided to go with resolve.external as the way of configuring things as external in dev and build. The feature is tracked at #6582. Supporting that would need some work, so it might take a while to get that done first before we can merge this. (Or if the implementation would fix this together)

@bluwy we have multiple teams waiting on this, can you maybe give some timeline?

Hi, sorry for the wait. We don't usually have timelines for features as the project is community supported. However, I might try to take a stab at this for Vite 5. There's been a couple things I'd like to do and this is one of it. I'll put this on the Vite 5 milestone so we track it.

I tried to implement resolve.external recently, but it became harder than expected. Not only we need to match rollupOptions.external, but also ssr.external. And there's multiple design questions such as:

1. Should they work mutually exclusive?
2. Or they work together, but how do we make it work predictably?
3. Should resolve.external be preferred over rollupOptions, or merged?

And it's also touching a lot of the codebase. At the moment, we're quite behind on the Vite 5 schedule so we'll have to unfortunately tackle this in a minor in the future. Dropping this off the milestone for now.

hi @bluwy, that's not good news. Is there an amount of money that could change that decision?

Thanks for the offer. I won't speak for the other team members, for me I'm limited on bandwidth currently to implement it even with so. With that said, if we manage to slim down the milestone by next week, I could also have time to revisit this.

It's also moved out of the milestone for now as it's not a breaking change we have to fit into Vite 5. The new external feature would be non-breaking, and "excluding html rewriting" would depend on the feature, so it's overall opt-in and we can do so post-Vite 5.

okay, let me know if we can help. AFAIK we are already sponsoring Vue and Vite to some extent but we would definitely be interested in paying more to resolve this specific issue :)

No accepted solution for years? May be for your current users this is minor, because they already removed external dependencies or wrote workarounds, but for migrating applications with multiple repositories to Vite it's critical.
"An edge case that only affects very specific usage" - the users who can't use vite because of this bug.

I guess, checkPublicFile should not check if file exists. Then /some.png can become ./public/some.png and back to /some.png without checking existence.

Missing files are served via proxy option on localhost, and by custom server setup in production (serving assets by one urls, and app by another)

#18315

@yyx990803, you are my last hope! we are ready to pay for this 😭😭

@leonheess yea the scope of this feature goes a bit beyond your code. If you update it to ignore relative paths and to make alias changes and to differentiate SSR and client side, they will probably merge it instantly, but as it is I don't believe they will make a move on this. They will probably make this move when they introduce rolldown to vite which may happen a lot later. I was actually thinking doing this right now bcs I have a project in mind: SSR microfrontend framework but i am still weighing if just creating a plugin is good enough for my usecase