-
-
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
Pre-bundling should be more resilient to errors #3715
Comments
We experience this issue aswell, when updating from 2.3.0 -> 2.5.7 (through svelte-kit) most dependencies that were previously only exposed to the server is now exposed to the browser. And everything fails. |
@AndreasHald Could be a |
I'm running into a similar issue related to an attempt at client-bundling an unnecessary package. In my case, I have two packages in a mono-repo:
I would assume that, between SvelteKit and Vite, the bundler should be smart enough to know that the SvelteKit itself could definitely be the problem here, but they don't really have any settings related to building; as far as I can tell, it delegates entirely to Vite, which makes me think there's something wrong or missing on the Vite side of things as well. I think that a concrete improvement that Vite could make here -- with or without SvelteKit being involved -- is being more clear about why the offending package is being imported at all. In my case, the error output looks like this I see that it's choking on importing |
It seems like there's two issues with prebundling here:
I'll be sending PRs soon. |
I found that lazily prebundle for dynamic imports to not always be a good default as some apps may re-prebundle more often which would be poor DX in some cases. I think we could keep it as-is for now given no1 is solved. Closing for now. |
Clear and concise description of the problem
When Vite fails during the pre-bundling of a particular dependency for the browser, it seems to get into a state where it refuses to pre-bundle any further dependencies. Even if the reference to the offending dependency is removed, in dev mode Vite remains in this state until the server is restarted.
This is an issue because some dependencies simply can't be pre-bundled for the browser (for example, if they make use of Node APIs). Mentioning these in code that's meant to be isomorphic for the browser and the server - even if it's inside
if (false) { import ('something'); }
- causes Vite to attempt to pre-bundle them, resulting in an error, and also resulting in other dependencies not being pre-bundled, resulting in (for example) CJS being served to the browser when it's expecting ESM.Suggested solution
I do not know Vite's internals well enough to suggest what should be changed.
Alternative
Other options that seem less good to me (because they don't solve the underlying brittleness issue) would be to make Vite smarter about
import()
s that it sees could never be reached, or to make Vite only actually bundle dependencies for the browser when they are requested. Both of these might be good ideas by themselves, but even if someone does accidentally import something on the browser that cannot be bundled for the browser, this shouldn't prevent other dependencies from being pre-bundled until Vite is restarted.Additional context
See sveltejs/kit#1570 which contains a reproduction using SvelteKit.
For now, my workaround is to hide the
import()
s from Vite that I don't want it to try to pre-bundle by wrapping them in another function call, which then callsimport()
.The text was updated successfully, but these errors were encountered: