-
-
Notifications
You must be signed in to change notification settings - Fork 5.9k
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
TypeError: Failed to fetch dynamically imported module #11804
Comments
This is not something specific to Vite and happens with Webpack, too. https://mitchgavan.com/code-splitting-react-safely/ I don't have any idea to solve this on a bundler side. |
We are experiencing the same issues with a vite+vue SSR application. |
Thanks @sapphi-red, is it Vite or Rollup generating these hashes (assuming that's what they are) on the filenames? I wonder if there's a way to suppress that behaviour and if it's required for cache busting whether there's any alternative approaches. |
@sapphi-red both generate hashes when running the build. If your product it's a SPA you can try to use a service worker together with an interceptor (if you use Axios) to manage that. I did it on Vue 2 where it's basically stores on the localStorage a version of the app and then compares if the one that you access it's the same or not and if not it triggers a reload of the browser in order to get the updated version |
@victorlmneves could you provide a bit of a fuller explanation/ code snippets maybe of tha so I understand the concepts a bit more? I'd be quite interested in exploring what that might look like. |
@IPWright83 And here is an example that I did some years ago
And another one using Axios interceptors
|
@IPWright83 import { defineConfig } from 'vite'
export default defineConfig({
build: {
rollupOptions: {
entryFileNames: '[name].js',
chunkFileNames: '[name].js'
}
}
}) But yes this is recommended for cache busting. I don't know any alternatives other than the ones described in the articles I linked above. |
@IPWright83 by the way, have you tried to access directly the file that is displayed on the console that wasn't possible to import? I'm asking because on our project we get those errors randomly but when we access them directly the file exist |
I have @victorlmneves. Is there any way to adopt an approach more like this #5825 @sapphi-red? Anything after the queryString can still cache-bust, but as the file name is constant you'll get the new payload. I think that example is a little primitive (I think JS needs transforming too). Could you see any issues with this approach? |
I guess it's possbile by using a plugin. For example, // foo.js
export const foo = 'foo'
export const bar = 'bar'
// a file depends on foo.js
import('./foo.js').then(mod => {
if (mod.bar.startsWith('b')) {
console.log(mod.foo)
}
}) second version deployed // foo.js
export const foo = 'foo'
// a file depends on foo.js
import('./foo.js').then(mod => {
console.log(mod.foo)
}) |
@IPWright83
|
@victorlmneves yeah, that works for |
Any updates on this? The vue router hack could work for some imports, but we have dynamic imports outside of the router, which i don't think the hack would be able to cover. Besides, forcing a reload because an error occurred doesn't seem like the best UX, so wondering if there's a solution/workaround that is more subtle and "behind the scenes" 🤔 |
While I understand that we should try to solve this problem ourselves, it seems like this must be quite a fundamental problem that developers will have when creating apps with vite? Especially when continuous deployment comes into the mix, because the files update very often and trigger lots of errors. For now I am back to "nightly deployments" to try and minimize disruption 😬. It would be great if there was a standard solution somewhere in the docs. Preferably one without making the users manually "opt-in" to a page reload. Even nicer would be if vite could somehow handle it for us so we don't have to do anything. Eg catch the error and refresh the files without a hard reload of the page. That would greatly improve the DX 🙂. Thanks for all the great work. Vite is awesome. |
@yakobe in my case, it's not about outdated chunks. I'm getting this with existing files that is even worst to figure out the problem and try to fix it, especially because the only way I'm able to reproduce the issue it's shutting down the node server (I have SSR app) :/ |
This reverts commit b1fc7bf. Workaround for vitejs/vite#11804
For what it's worth, an ad-blocker was the root of this issue for me. Disabling it resolved my issue. |
A lot of Cypress users run into this: cypress-io/cypress#25913 I don't think I can fix it on the Cypress end. I can spend time (several days of development resources) to patch Vite if needed, but it looks like the cause isn't entirely clear. Some observations:
Any tips -- maybe from someone more familiar with Vite - on debugging this? I will inspect Cypress more first and keep the limitations in mind. |
We are just hitting this now too, but it's not just when the user has a browser tab open. It can also happen much later, if the user returns to our app after we have deployed. We're trying to work out if it's caused by the
I'm still confirming this but I wondered if it matches anyone else's experience/setup? |
Happened to me after upgrading from vite 4.0.1 to 4.1.4 |
@benadamstyles I had the same issue. I removed the hashing option in the config like another user mentioned. |
Not sure if related but I'm getting the same error when using storybook with a react component that imports a module from an |
same |
I reproduced this in CI only, you can follow my progress as I debug it in Cypress: cypress-io/cypress#25913 (comment) I suspect the same core issue. I think it's a race condition or resources related issue. |
I think there are possibly two separate issues being described by different users/teams in this thread:
For people experiencing issue 1., the solution is to organise your deployments so that old versions aren't deleted immediately. Doing a deployment of new app code doesn't mean that all users running your app in their browser will update immediately (unless you force it somehow). For those users who still have an older version running in their browser (lets say For users that load the app after a deployment, If you keep a manifest of each deployment, and your instrumentation/logging includes the "version" of the app users are using, you should be able to figure out how long old versions are still used. My team has seen users still operating in the same tab they loaded a month ago without updating, so we keep all our built assets deployed for a long time. If you want to force users to reload when a new version is deployed, that's a whole piece of engineering in itself. |
According to quite a bit of research in cypress-io/cypress#25913 at least one class of error is related to CI on GH Actions specifically - not sure if this helps anyone, but worth noting in case it does. |
I was having this same issue when serving the built website with NGINX in Docker when running CI tests, accessing it with parallelized Playwright Chrome instances inside GitHub Actions. Due to unrelated constraints I had limited the |
Came across this while researching the issue. It seems to have solved mine at least, so maybe it might help some of you too: |
I want to shine in on this: We had two issues with the chunking of vite/rollup. One like many others here was that the older files were not available anymore after a new deploy and some of the solutions in this thread helped us by forcing a refresh. The second issue we had was that some users had an CORS issue, we were seeing Failed to fetch in our error reporting software but after testing with users it showed in the console that they got a CORS error (which don't show up in error reporting). Which was actually not a cors issue but a request to an asset being blocked (see: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS/Errors/CORSDidNotSucceed). The reason why it was blocked was because some adblocker, plugin and/or virus scanner was blocking these files. We changed the default chunk names from |
We were also facing the same issue after the build. We are using the vite event to track errors and force reloading while there are errors.
|
Hi @mrsudarshanrai! I have a small question: I tried to use the same workaround you provided, but in my case, the vite:preloadError event is not being triggered. I placed it at the top of my index.jsx file, right after all imports. I'm curious if there are any additional hints for its usage. Thanks! |
@ionnikovv It worked in ours without further configuration; I just added it in the main. tsx. We are using "vite": "4.5.2." |
In case of this:
This method decides 2 problems:
|
I am seeing this in the latest version of vitest. |
@victorlmneves This is also exactly what I experience. I don't use file hashes so the filenames don't change but I see these errors happen pretty often, and also usually with the same file. Did you gain any new insights regarding this? I implemented the automatic reload on this error but I would like to know why it happens in the first place. |
Well, that's the million-dollar question |
This worked for me, but I had to bump Vite. For anyone else with a similar issue, it was added as part of v4.4, via this commit. Which caught me out, as I had to update my vite package. |
I have this problem with a low traffic app, and I don't collect info on which browsers this is happening. But good point, I should start logging that information so that I can see if there are any patterns. |
Just sharing our anecdotal experience: This error started appearing once we moved from Webpack to Vite (although I'm pretty sure it was happening with Webpack as well to some extent). Users would see this if they kept their tab open while we deployed a new version of the app. We always served the latest version, so if some hash changed after a deploy, and the user changed page triggering a lazy import, this error would appear. Six months ago, we started deploying all of our assets in Amazon S3, keeping previous versions available. Since then, we haven't received reports anymore. For reference, we are using Vite v5. We didn't have to implement any preload error handling, that change was enough to fix the issue. I don't really think it's on the bundler's side, you kinda have to fix this through infrastructure. Some people in this thread said they tried this approach and it didn't work, I'd be curious to learn why, however at least for us it worked. I hope this helps someone. |
@joaopslins we are using Amazon S3 and keeping the old files in the bucket and still seeing this error. We also saw that error appears more often on pages that bots are crawling, they may be blocking dynamic imports intentionally. |
Understood, that's unfortunate 😢 |
We didn't have this issue with webpack as it was built into one large bundle, with only few rarely loaded files as externals. However with Vite/Rollup, we cannot at least temporarily solve this issue by combining into one file, as it still keeps large amount of small external files even using I think the issue is fundamental here, If there is any issue with loading the chunk (either it is deleted after redeploy, or network connectio) we always get these errors. To reduce them there should be less files loaded which contradicts code splitting strategy of vite/rollup. |
@aodinok Same in our case, we have the very old files on our server, but we still get a bunch of errors on our Airbrake after using |
@victorlmneves |
That's an interesting discovery! I can totally see how google's bot can ignore lazy loading to save network and compute resources when indexing. |
Theres no quick work around for this? I'm seeing this after switching to vite from webpack but only on certain route files - despite them all following the same react lazy pattern. |
see https://vitejs.dev/guide/build#load-error-handling for a (user visible) fix. you may include a dynamic import early on in your app and trigger the dynamic import error and then issue a re-render. |
This actually just started happening to us - we did not get the errors before with vite even though the routes were lazy loaded. Thanks for all the useful info here to everyone who contributed. |
Describe the bug
Since switching to Vite we noticed a new production issue, where sometimes users are encountering an error if we deploy while they have an active session:
I believe this is because if any code is modified in an area that Vite would turn into a dynamic module, then the file hash changes, however when they try to visit an area that would trigger the dynamic load, those files no longer exist so they hit the error message above.
Quoting from https://stackoverflow.com/a/74057337/21061
What I expect to happen, is not to encounter any errors if the users session remains active during a deployment.
I have been unable to come up with a good workaround (specifically for me using React ErrorBoundary is the best I can do so far with a re-direct similar to https://stackoverflow.com/a/74861436/21061 which is a mitigation and provides quite a poor user experience flashing an error message).
Reproduction
https://github.com/IPWright83/vite-dynamic-import
Steps to reproduce
The above repository has been set up to mimick a production deployment as obviously that is a much more complicated set-up. It leverages
React.lazy
to force a dynamic module and uses asetTimeout
to provide a delay with which to simulate a user navigation to a page requiring a module. In a real production scenario I don't believeReact.lazy
is required.Clone the above repository
npm install
npm run build
open a 2nd terminal
Terminal 1 npx serve dist (starts a web server)
Browser open the URL (usually localhost:3000)
Text Editor modify src/Foo.jsx changing the string "Foo" to something else (within 30s of launching the page - increase the setTimeout in App.jsx if this is not long enough)
Terminal 2 npm run build
Wait... 30s after loading the page you should see a blank page render with errors in the browser console:
If you were to reload the page, you can see that
Foo-b53985a6.js
has been renamed toFoo-535d5a10.js
(or similar new hash)System Info
The text was updated successfully, but these errors were encountered: