vite: Vite dev hangs indefinitely without errors on page with many components and imports

So I found the fix (at least to my problem). This problem is similar to this one: https://github.com/vitejs/vite/issues/5310

In case you have a big project with plenty of files Chrome demands more file descriptors than system allows (1000 by default). I have Ubuntu Linux, so using ulimit -Sn didn’t work for me. Like, it updates the amount of descriptors but that has to be done permanently as Chrome doesn’t use it.

so, for Ubuntu Linux you have to add line * - nofile 65536 (or whatever amount of opened files you need) to the file /etc/security/limits.conf and reboot.

For Arch Linux they say to add DefaultLimitNOFILE=65536 line to both /etc/systemd/system.conf and /etc/systemd/user.conf file. Didn’t check that.

Upd. LOL. Just figured out that DefaultLimitNOFILE can be applied to Ubuntu as also but it simply doesn’t work, so limits.conf is the only working solution there. Will provde PR.

I think I am having the same issue, ie. specifically when running the vite dev server the browser tab will hang on the initial load.

However for me it is not just that the vite dev server is not responding, it seems like the browser tab is frozen, ie. when I press the close or back button on the tab in chrome it will not respond, and I need to press close many times to force close the tab from chrome. Is anyone else experiencing the same behavior in Chrome?

Should also note that in my team I am the only non-Mac user, and none of the Mac users seems to be having issues. (I am on Linux)

I have seen this as well, with SvelteKit. In my case I get a log that ssr compilation starts, but it never finishes. It is non-deterministic and only happens in dev. If you figure out what’s causing it, I’d love to know— it’s driving me crazy.

I am also having the same issue. The dev server hangs seemingly randomly and the site is not accessible on subsequent restarts. The built version works fine but I’m unable to work on the project locally which is very annoying.

I’m also using Sveltekit on a relatively big project so I cannot reproduce it. I’ve tried using the older versions of Vite, going back to 4.0.0, and the issue happens on all versions.

This leads me to believe that this might be a Sveltekit issue.

Might not be related at all but I noticed that the site hangs each time after this message: ✨ optimized dependencies changed. reloading

This drives me crazy. I’m using both mac and windows and both occur.

Here to +1 a few things in this issue related to file descriptor limits (TypeScript 5.0.4, Sveltekit 1.16.3, Vite 4.3.5, Node 18.14.0, mac OS 13.3.1, Chrome 113.0.5672.92).

• The hang I experience is similar to the OP: the browser tab does not load, and vite dev --debug just stops resolving imports before it’s finished on a vite:transform, with no errors. It tends to halt on different imports each time. Killing vite dev shows ssr compile done.
• This only happens on routes with a large number of transitive imports, and only when files are first imported. On my smaller projects (<100 .ts, .svelte files), I never see this hang. On my larger projects and on routes with a large number of transitive imports (>500 .ts, .svelte files), it happens consistently on particular high volume routes.
• Setting ulimit -n 12288 and sudo launchctl limit maxfiles 65536 200000 in mac OS on a fresh boot prior to vite dev, mirroring the advice on the troubleshooting page, does not prevent the hang.
• While I’m primarily working in Chrome, the same hang consistently occurs in Firefox, 109.0.1, and Safari 16.
• All of this is entirely unrelated to the parallel issues described in this thread about TLS requests, since I’m not doing any TLS.
• Any intermittent behavior is largely due to the issue being caused on first load, before any imports are cached, and there is a large number of files. Edits that cause a large lumber of reimports

The only workaround I’ve found is temporarily commenting out high volume transitive imports, loading, then uncommenting the import to finish loading the remaining imports, similar to others’ workarounds. It’s possible that my mac OS file descriptor increases aren’t being applied in the right way or on the right process; I don’t know how to confirm that.

This could be either Vite, Sveltekit, or TypeScript, depending on which is getting hung up.

I’ve frequently had a similar issue as the OP, where many pages of my SvelteKit app will hang forever in the Vite dev server, while a small number of simple pages still work.

Here’s my environment:

OS: Windows 10 10.0.22621
Node: 18.16.0
Browser: Chrome 114.0.5735.134

Vite: 4.3.9
SvelteKit: 1.16.2

I’ve tried countless things to get more details on what’s going on and I finally got something today by adding debugger breakpoints into the guts of Vite (I started out with a breakpoint on the first line of ssrLoadModule which in my case was in node_modules/vite/dist/node/chunks/dep-e8f070e8.js).

With the debugger, I was able to determine that for the pages that were hanging, Vite had several promises in pendingModules (see here) that never resolved, even after the dev server had been in this state for hours.

Here’s the function from Vite:

export async function ssrLoadModule(
  url: string,
  server: ViteDevServer,
  context: SSRContext = { global },
  urlStack: string[] = [],
  fixStacktrace?: boolean,
): Promise<SSRModule> {
  url = unwrapId(url)

  // when we instantiate multiple dependency modules in parallel, they may
  // point to shared modules. We need to avoid duplicate instantiation attempts
  // by register every module as pending synchronously so that all subsequent
  // request to that module are simply waiting on the same promise.
  const pending = pendingModules.get(url)
  if (pending) {
    return pending
  }

  const modulePromise = instantiateModule(
    url,
    server,
    context,
    urlStack,
    fixStacktrace,
  )
  pendingModules.set(url, modulePromise)
  modulePromise
    .catch(() => {
      pendingImports.delete(url)
    })
    .finally(() => {
      pendingModules.delete(url)
    })
  return modulePromise
}

See this screenshot from the debugger for more info:

It’s worth noting that some of the modules that are pending in this screenshot have circular dependencies among them. I’m not sure if that is relevant here, but it seems suspicious.

I’ve found some endpoints in my application that don’t rely on any of these modules, and Vite will continue to serve those without any issue.

My hypothesis is that there’s something wrong with the error handling in here somewhere. Is it possible that pendingImports.delete in the .catch should be pendingModules.delete?

For those subscribed to this issue, @shYkiSto implemented a fix for hanging circular imports https://github.com/vitejs/vite/pull/15395. Hopefully the PR gets landed soon!

When you say it stops working/hangs, what does it show in the browser?

Nothing at all. Just a pending request and a spinner. The hanging only happens on requests to this ‘route’/page, the vite process/server still accepts other requests even after the hanging happened. And handles them just fine without requiring a restart.

I have no idea where to even start to ‘debug’ this problem.

It does not seem chrome related, it happens in Firefox and Safari as well.

This happened to me also an took a looooooooooooooooooooooong… time to discover the source of the circular issue, since my projects have more that 500 svelte files and currently there are not a way to find the problem from a log or something else. vite should have a better circular reference handling and avoid recursive/circular references loading, in most systems there is a max recursive loading then and automatic abort should be fired and tell the source where. I’ve tried latest version of vite 5.x and still faced this problem.

If increasing the max number of file descriptors doesn’t work, disable SSR altogether. On SveteKit this can be done globally. See the docs.

My solution is to disable SSR on dev mode. src/routes/+layout.ts

import { dev } from '$app/environment';
// Disable SSR when running the dev server
export const ssr = !dev;

I have exactly the same problem, and I’ve managed to solve it for my case, but I’m not sure if this the solution to every other case in this thread. So my problem was:

• Running in dev mode http://localhost:5173
• Complex React page with lot of components in TS
• Vite dev hangs indefinitely without errors randomly after a while

I’m developing on WSL on windows, and the localhost is routed to WSL. Instead of running vite on localhost, I do vite --host 0.0.0.0 and access it with the WSL network in my case http://172.20.102.240:5173/
With this setup vite runs fine, but I’m not sure this is a WSL problem, because I have node servers on WSL and they run fine with localhost.

Hope this helps somebody !

So I learned a couple things about this after spending most of yesterday on this problem.

First, it seems vite hangs/locks up much more frequently when you have multiple browsers accessing vite dev. I’m on a PWA project, so I’m accessing vite dev with my development system as well as Android and iOS devices at the same time. It locks up constantly when trying to do this. If I only use one connection, it still locks up, but much less frequently. So, this is one reason why some may experience this issue more than others. It may also be useful for duplicating or isolating the problem.

Secondly, after upgrading everything, trying multiple projects, etc. I’ve noticed when it would hang, node would be maxing out my CPU (I’m running on MacOS Intel). I was running node v18.14.1, so I upgraded to the latest LTS release (v18.17.0) with the same results. I then tried other versions of node with the same result. Finally, I installed the very latest current release (v20.5.0) started up vite dev environment, ran my 3 browser connections, and it seems to work! I haven’t had it hang or lock up since setting node v20.5.0 as my default. I’ve ran vite dev all day without a single lockup!

So try node v20.5.0 nvm install 20.5.0 and see if that fixes things for you.

If increasing the max number of file descriptors doesn’t work, disable SSR altogether. On SveteKit this can be done globally. See the docs.

My solution is to disable SSR on dev mode. src/routes/+layout.ts

import { dev } from '$app/environment';
// Disable SSR when running the dev server
export const ssr = !dev;

Bumping this in hopes that others can see. This fix was the only thing in this thread that addressed my issue and it has made HMR much quicker for me.

In my case, I am using SvelteKit and did not experience this until re-enabling SSR project-wide. Prior to that, I only used SSR on SEO-sensitive routes. At that time, SSR routes were very slow to load initially, but did not hang. CSR routes (meanwhile) worked plenty fine.

If you’re using SvelteKit, certainly give this a try. Seems to be a SvelteKit issue for us, rather than a Vite one.

Cheers 👍

I’ve removed all circular imports in our codebase, but that hasn’t solved the issue. I’ve verified using both vite-plugin-circular-dependency and dpdm (even without the -T flag) that there are no circular imports, but the application still hangs in Chrome for some of our developers (mostly on Linux, but we had one report of it hanging on MacOSX also).

Seems there’s more to this than just the circular imports.

I’ve also made the limit changes mentioned above, and no luck there either.

I will note that occasionally the app does actually load in Chrome, and works well. But then after a few page refreshes, same issue again.

I’ve used Wireshark to determine that the “Pending” files are actually sent over the network, so the issue appears to be more on the Chrome side than on the vite side (also, the app loads fine with Firefox even while it is hanging in Chrome).

For Ubuntu 22.10 I needed to modify three files to get things to apply:

In the /etc/security/limits.conf

* soft nproc 65535
* hard nproc 65535
* soft nofile 65535
* hard nofile 65535

in /etc/systemd/system.conf

DefaultLimitNOFILE=65535:524288

in /etc/systemd/user.conf

DefaultLimitNOFILE=65535:524288

reboot

Once you are logged in you can use this command:

ulimit -a |grep open

This should confirm that the limit has taken effect.

delmendo@cu:~$ ulimit -a |grep open
open files                          (-n) 65535

This happens for me on macOS even for a very minimal project with only a few changes from the empty npm init vue. I don’t have a lot of transitive imports or anything like that.

Following the advice from @fc I disabled https and that seems to help with my issues. I used "@vitejs/plugin-basic-ssl" to provide a self signed certificate.

I then checked also HMR and the updates are instant! So https seems definitely to be an issue with the dev server/browser.

I found a (consistent) way to temporary fix a hanging route.

• I delete a bunch of imports (and the code using them) in the file.
• Restart the server.
• Reload the hanging page (it loads).
• Paste imports back in the file. Save.
• HMR does it’s thing.
• Route can be reloaded and works fine.

Changing anything in one of the imported files (something as simple as adding a console log) can result in the HMR making the page hang again.

Here to +1 a few things in this issue related to file descriptor limits (TypeScript 5.0.4, Sveltekit 1.16.3, Vite 4.3.5, Node 18.14.0, mac OS 13.3.1, Chrome 113.0.5672.92).

• The hang I experience is similar to the OP: the browser tab does not load, and vite dev --debug just stops resolving imports before it’s finished on a vite:transform, with no errors. It tends to halt on different imports each time. Killing vite dev shows ssr compile done.
• This only happens on routes with a large number of transitive imports, and only when files are first imported. On my smaller projects (<100 .ts, .svelte files), I never see this hang. On my larger projects and on routes with a large number of transitive imports (>500 .ts, .svelte files), it happens consistently on particular high volume routes.
• Setting ulimit -n 12288 and sudo launchctl limit maxfiles 65536 200000 in mac OS on a fresh boot prior to vite dev, mirroring the advice on the troubleshooting page, does not prevent the hang.
• While I’m primarily working in Chrome, the same hang consistently occurs in Firefox, 109.0.1, and Safari 16.
• All of this is entirely unrelated to the parallel issues described in this thread about TLS requests, since I’m not doing any TLS.
• Any intermittent behavior is largely due to the issue being caused on first load, before any imports are cached, and there is a large number of files. Edits that cause a large lumber of reimports

The only workaround I’ve found is temporarily commenting out high volume transitive imports, loading, then uncommenting the import to finish loading the remaining imports, similar to others’ workarounds. It’s possible that my mac OS file descriptor increases aren’t being applied in the right way or on the right process; I don’t know how to confirm that.

This could be either Vite, Sveltekit, or TypeScript, depending on which is getting hung up.

+1 to seeing this behavior when a component or file is edited that imports or is imported by several other files.

Is there anyway to surface further debug messages to try and dig into this further?

The same here but on Chrome 109 for Linux. Firefox works, though Chrome 109 on MacOS also works fine. That’s pretty annoying 😃

The project is quite large.

Runing with --debug option doesn’t show any errors, it just goes sequentially across multiple project files and then just stops at some time.

Upd. Just tried Chrome 110 Beta on Linux with the same results.

This is happening to me now starting with 5.2.0. If I drop down to the previous version, it works again.

Scratch that, its happening again.

Has anyone gotten a fix because doing the above didn’t help

It certainly feels like there’s a lot going on this thread, which likely means the Vite team won’t be in any rush to prioritize anything written here, since we’ve taken so many directions (I don’t blame them!).

I wonder, now that we’ve shown repeatedly that we can trigger this issue with circular dependencies, if we should try to hone this down to a minimum test case and resubmit as a new issue for visibility? Even if Vite can’t fix the core issue easily, simply logging that it is happening will allow most users to rectify the situation in userland.

On Thu, Sep 28, 2023, 7:16 AM MarArMar @.***> wrote:

In my case after solving all madge & vite-plugin-circular-dependency it finally worked fine

— Reply to this email directly, view it on GitHub https://github.com/vitejs/vite/issues/11468#issuecomment-1738950942, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHET4KNSETB7RZVHPFGAOTX4VMBHANCNFSM6AAAAAATHDOWQQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

I have managed to resolve the issue by tracking down and eliminating circular import references, specifically those relating to stores.

The file containing my custom stores used functions from various other files. Some other functions in those files themselves used stores, either directly or through other functions.

The key was to ensure that my stores file does not import any file which itself requires the import of the stores file, either directly or indirectly.

To make it simple, my stores now only use functions from a single utilities file, and that utilities file is pure native code, apart from importing types.

I agree with your solution, today I tracked down the circular dependencies with: https://www.npmjs.com/package/vite-plugin-circular-dependency and I eliminated them in the project. Now Vite dev seems more stable. At this point if the elimination of these circular dependencies is so crucial to Vite operation, why don’t Vite developers intregrate this tool directly into the project? It would be useful for everyone. Thank you, regards 😉

same problem，How to solve it in Windows system

Yes I tried that before opening the issue (as it already was in the vite docs). I have many imports, but from only a few files (about 20-30). That’s not a big project in terms of file descriptors.

Just tried it again, same predictable hang when I edit an imported function.

Weird stuff. Using SvelteKit as well.

• vite dev then request from Chrome => hangs
• vite dev then request from Firefox => works, subsequent request from Chrome => works

wtfnode shows that the socket from chrome is never closed, just hangs. But there are no node hooks waiting except for the vite connect app server.

I can see the commit where this behaviour begins in my codebase. But nothing stands out. Here’s the patch if anyone is curious, but it’s just business logic changes relevant to my app (warning: large commit) (ignore the ruby code).

I’ll have to keep looking.

UPDATE: just showed up again randomly. This time firefox requests don’t help. UPDATE 2: Now the firefox request thing works again

If increasing the max number of file descriptors doesn’t work, disable SSR altogether. On SveteKit this can be done globally. See the docs. My solution is to disable SSR on dev mode. src/routes/+layout.ts

import { dev } from '$app/environment';
// Disable SSR when running the dev server
export const ssr = !dev;

Bumping this in hopes that others can see. This fix was the only thing in this thread that addressed my issue and it has made HMR much quicker for me.

In my case, I am using SvelteKit and did not experience this until re-enabling SSR project-wide. Prior to that, I only used SSR on SEO-sensitive routes. At that time, SSR routes were very slow to load initially, but did not hang. CSR routes (meanwhile) worked plenty fine.

If you’re using SvelteKit, certainly give this a try. Seems to be a SvelteKit issue for us, rather than a Vite one.

Cheers 👍

This resolved it for me. On MacOS, Sveltekit 2.0.0, Svelte 5.0.0-next.55, Vite 5.1.4

Faced the same issuer, here are my 2 cents based, hope this is helpful.

• SvelteKit 1.23.0
• Vite 4.4.9
• MacOS Ventura 13.1 | M1 Max
• Same issue in both Chrome and Firefox
• Not HTTPS/SSL/TLS on localhost
• vite config is very basic, the only plugin I have is @rollup/plugin-replace (doubt it has anything to do with hanging).
• The project is big, but not huge. Although there are a lot of imports everywhere (small components, helper functions, state subscriptions, etc).
• localhost tab hangs forever
• no logs in browser console
• no logs in terminal (just says it’s ready as normal)
• when I uncomment one import (the one that started all this) - it comes back to functioning as normal, I can even bring back the import and do anything, but at some point if I refresh the page it goes into “forever loading state”, seemingly for no particular reason.

This issue is a bit scary, since there are no logs or metrics to start fixing on the app side. I’ll try to look for circular dependencies with plugin mentioned by @MattiaPeterle and clean up the code, but this might come back again at any point as new code is written.

Update: happy to report that after fixing circular dependencies with https://www.npmjs.com/package/vite-plugin-circular-dependency the issue went away. From now on I’ll just monitor and removing circleDeps, need to keep it tidy anyway…

So try node v20.5.0 nvm install 20.5.0 and see if that fixes things for you.

No joy for me. I have fixed it though in my instance.

I found a reliable way to reproduce (just add a debugger statement to one of my files and let it refresh and hang). I then binary chopped the GIT commit’s (just checked them out and ran them up) until I found the one where it started happening, then did a similar thing to the code changes in that commit until I found a single import that caused the issue. When it was there, it hung after one or two refreshes. Take it out, and no problem. It was not a circular dependency (or if it was, it was a very convoluted one - possible but not obvious). Perhaps it just caused the dependency tree to be sufficiently different so that the issue wasn’t triggered… who knows. It does feel like there’s some edge case(s) somewhere in vite though that needs working on - an error message would be wonderful here!

I would add that my colleague experienced none of this working on a different machine at the same time.

When you have a circular dependency, will vite notify you on that? If not, I believe this would be a great feature. When using Angular for example, you get a “Circular Dependency Error” and you can fix it right away.

@itayperry No, Vite does not notify you about circular dependencies AFAIK. There is code in Vite that is supposed to handle circular dependencies (e.g. this PR https://github.com/vitejs/vite/pull/3950) but perhaps there is an edge case that doesn’t work. My rough theory is that the edge case could be when there are some kind of IO errors when Vite reads source code off of the disk, so perhaps that is why raising ulimits helps in some cases.

We have vite-plugin-circular-dependency installed, but it did not find some circular dependencies in our codebase. We found those remaining circular dependencies in a much more manual way - see my comments here for more details. TL;DR we found a list of modules that were stuck in a pending state when debugging vite internals, and then realized by looking at those modules in our code that some of those modules had a circular dependency loop.

Is there a way to view in Vite what the actual problem is? We might all be experiencing different issues i.e. if it is ulimit for example in my case, then should there be logs or errors or something?

@tomcharwood I’ve been running Vite with the --debug CLI flag (ref) which spits out a ton of logs of things that Vite is doing. It’s been marginally helpful to see what the last few log lines are if Vite freezes up. For us, it was usually a line like “vite:transform”.

Check it : https://vitejs.dev/guide/troubleshooting.html#requests-are-stalled-forever

A lot of us have tried bumping file descriptor limits, but have not had success with it fixing the issue

Same as the other posters; Ubuntu 23.04, Chrome 114.0.5735.90 (64-bit), Top-end Ryzen with 64GB RAM.

Now, some additional things I’ve not seen anyone else mention, but MIGHT be diagnostically significant: We’re also, perforce, running docker in the background. Ours is a massive WebApp AI project (1,478 requests being made on initial hit) that communicates with Rust and C SO’s. “Resource intensive” is not overstating it.

Behavior is similar to that described above: the issues are, hands-down, most prevalent in Linux, though manifest in MacOS and WSL as well. There appears to be some threshold of accumulation, too. That is to say, something will abruptly knock it into functioning again, temporarily, and then, after an indeterminate amount of - time? Uptime? Requests? Throughput? Cache/page file availability? SOMETHING - the behavior resumes.

I have a strong suspicion this is a faulty caching mechanism of some flavor, either precipitating an infinite recursion or causing some form of overflow and the errors aren’t bubbling. No reason to assert this other many, many years as a front-end dev and recollected parallels of other, vague, similarly-enraging, intermittent issues.

so, for Ubuntu Linux you have to add line * - nofile 65536 (or whatever amount of opened files you need) to the file /etc/security/limits.conf and reboot.

Thank you @ximus This solved the issue for me 1st_place_medal

FYI I wrote that this fixed the issue for me, but it is back it seems 🤷

Edit: Downgrading to vite@3.2.5 worked for some of us.

I found what looks like a solution that works for me but it would be good to get validation or improvements from this approach. My previous looking into the root cause of this it seemed like it was an issue with node’s http. Well, someone wrote undici which is an HTTP client written from scratch. @fastify/http-proxy is a module that uses undici under the hood. server.proxy settings remain in vite.config and nothing special is really required.

const fs = require("fs");
const path = require("path");
const proxy = require("@fastify/http-proxy");

const serverDirectory = "/path/to/ssl";
const fastify = require("fastify")({
  logger: false,
  http2: true,
 /* enable if you need it
  https: {
    key: fs.readFileSync(path.join(serverDirectory, "proxy.key")),
    cert: fs.readFileSync(path.join(serverDirectory, "proxy.cer")),
  }, */
});

fastify.register(proxy, {
   // change to https if you need it
  upstream: "http://localhost:3000",
  prefix: "/",
  // enables vite's HMR, might also need to update server.clientPort in vite config
  // https://vitejs.dev/config/server-options.html#server-hmr
  websocket: true, 
});

fastify.server.on("secureConnection", (sock) => {
  sock.on("error", (err) => {
    console.log("Socket error", err);
  });
});

fastify.listen({ port: 3001 }, (err, address) => {
  if (err) {
    console.log("ERR:", err);
  }
});

Feel like there must be some http setting that would work but no idea what that would be as things I tried didn’t work. If you google around, you’ll find people who run into the issue with pending requests it could be related to a request that is hanging open and not closed. Could there be a catch or error event handler that is swallowing what would normally be an error and silently failing? Could there be a middleware that is encountering an unexpected situation and just returning early?

For all the newcomers, I’m going to echo what was said before: The issue is fixed on https://github.com/vitejs/vite/pull/15395 and is waiting to be merged/released.

You can clone and use the branch from @shYkiSto locally while we wait for the fix to be officially released. Simply follow the docs to build Vite locally and link it to your project.

To use the local version of Vite you can do:

"devDependencies": {
  "vite": "file:/path/to/vite/packages/vite"
}

Then I had to run yarn link && yarn. Don’t ask me how to do this with other package managers, Google is your friend. Once the installation is done, you should be able to start your dev server normally and your the app should no longer hang.

Hope this helps.

Nothing helps, I use linux ubuntu , I did everything .

@dennisjlee for the win.

vite-plugin-circular-dependency had turned up nothing.

only when I added some debugging did i see the circular dep lingering in pendingModules:

setInterval(() => {
  console.log('pendingModules', [...pendingModules])
  console.log('pendingImports', [...pendingImports])
}, 200)

super weird intermittent issue, hard to catch.

I can confirm that hanging is related to circular imports. Removing them or even merely altering the import graph can fix the hanging. That being said, it seems not all cycles will result in hanging.

Anecdotally, I would say our situation may not be caused by circular dependencies, given that it works on one laptop and not on another identical laptop (same codebase). So while circular dependencies could be one cause, there must be others.

I suspect a race condition given the information in this thread and our observations.

We are currently experiencing this on one machine (@bmcdaniel11), but not another (mine) with vite 4.4.1. Same codebase, same macos M1 Ventura 13.4.1 (22F82) machines, same versions of node 18.10.0. Using yarn 3.5.1 with nodeLinker: node-modules. Both machines have the same sysctl/ulimit parameters and both have the same xcode-select version, and brew fully updated. Always after any of these changes we have cleanly rebuilt node_modules due to the suspicion of a native cause. Issue is reproducible with multiple browsers.

This appears to be a native issue since the same codebase works on one machine and not another with all the rest being equal. We have not however been able to find the difference between the two machines.

I’m wondering if we can help debug further, since one machine works and the other hangs on the 2-6th refresh. If there are any pointers to information we could provide that could be helpful, please let us know.

I have exactly the same problem: React app with many components, chrome only crash everytime, everything is correct on Firefox. Commenting huge parts of my project fix chrome, but we can’t use that to collaborate with other persons.

tested on 3.2.5 and on 4.0.4, and on 4.3.9 and get the same result.

Everything works fine when building. Couldn’t do anything with vite config options 😕

@dennisjlee FWIW that logic was added and discussed in https://github.com/vitejs/vite/pull/3950/files#r681153240

It’s important to mention that this problem accrues even if you don’t have “many components and imports”

We were experiencing this just on our Linux machines. Tried all of the above and downgrading to vite@3.2.5 worked for us.

I’ve just encountered this issue on Linux (Ubuntu 20.04) and Chrome. No errors, just infinite loading. @aspnetde mentioned that for him it’s browser related, so I went on and tried and - yes, it loads just fine in Firefox. I thought it should be some invalid Chrome env, so I loaded it in incognito mode. Same infinite loading.

There got to be some issue in communications protocol in Chrome, or something along the lines.

I have the same problem with Windows. is there some known solution to fix it?

Fixed this by deleting imports on the route that hangs, or the root level .svelte, .tsx file depending on your framework, saving the file, and adding the files back in. 😃

Update: I removed the basic-ssl plugin and set up the dev server to use our (self signed) server cert. Everything connects and the page looks good at first look. But as soon as I start using the web workers I’m back to square one: after reloading the page or restarting the browser entirely, the web workers don’t do anything anymore and the dev server just hangs.

In fact it looks as if the dev server doesn’t serve anything from this moment on. When I do yet another page refresh in the browser I only get a timeout error.

I’ve run into infinite pending requests and other issues but here are a few thoughts that maybe will help you although what you describe doesn’t sound exactly the same as what I ran into…

Untrusted SSL/cache issues - for SSL we needed to have a trusted SSL certificate - it doesn’t look like you’re using SSL based on your screenshot but mentioning it just in case because there were equally frustrating and baffling issues with that. Using an untrusted SSL could lead to unexpected behavior since it wouldn’t correctly cache anything. I see that ‘Disable cache’ is checked in your screenshot, and I wonder if that is maybe causing problems (or just a coincidence).

Infinite pending requests - the infinite pending request problem that we had was caused by a bug in http that we could never fully root cause (http is used under the hood by the vite proxy). To workaround this, we setup a proxy that doesn’t use node at all that would act as a reverse proxy to all requests to vite, e.g., localhost:9000 would proxy all the requests to localhost:5173. We also had to remove to the server.proxy settings from our vite config. There is a GitHub issue that says this may be a problem with a file descriptor limit although increasing the file descriptor limit didn’t seem to resolve it for us.

We suffer from this at least more than a year. In SvelteKit perspective: For us, mostly happened in containerized environment. We tried with ingress and nginx reverse proxy as well. Mostly happening on .ts file changes, which is imported by +layout.ts or +page.ts. The vite crashes somehow and get into a dead state without restart. Mostly the HMR and the ws connection want to communicate with it and if we just restart the container, it won’t help. Need to close the actual browser tab as well.

We spent hours to debug it and it’s very sneaky bug. Which can pain in the a** if you have to restart things frequently. HMR disable may help you, but that’s also breaks DX.

I have a similar issue (5.2.8 now, but tested 5.1.6 and 5.2.10), that happen whether I use dev or preview. I am able to build without errors. But it seems the server is not responding to request. In fact, the HRM doesn’t even trigger when I modify a source file; except for the vite.config.ts. Last time I did use the dev server, it worked without any issues. I had to take a break of a week to deal with other tasks, coming back, everything as I left it, it is not working anymore!

It’s like all of a sudden, vite dev is lifeless 🤷🏼‍♂️

Update 1 I went back in my code history to few previous version that worked and still nothing. However I noticed that vite does create files in the configured cacheDir. But it only contains some of my dependencies. It never reaches my own source code. I will try to downgrade node and pnpm and see if something there changed for vite.

Update 2 I tried node 20.9.0, 20.10.0, 20.12.2 and 21.7.3. I also tried pnpm 9.0.5 and 8.15.7. No changes in the behavior. The only thing left to check for me is trying outside a dev container.

Update 3 I tried outside my dev container and it worked without any issues. So, during the week I touched nothing, something happened between my dev containers and vite 🤔

Update 4 After a refreshing night, I tested to downgrade Docker from the new v26 to the previous v25 and it resolve my issue. Now, it’s left to dig up what changed in Docker to make my dev containers not working correctly regarding the vite dev and preview server.

Update 5 Under docker v26, my dotnet preview server seems to be working fine. So this issue seems limited to either Vite or whatever backend Vite is using for its server. I’ll open another issue to track this one.

I was having the same problem, running SvelteKit 2.5 on Svelte 5 alpha.

Creskendoll wrote:

If increasing the max number of file descriptors doesn’t work, disable SSR altogether. On SveteKit this can be done globally. See the docs.

My solution is to disable SSR on dev mode. src/routes/+layout.ts

import { dev } from '$app/environment';
// Disable SSR when running the dev server
export const ssr = !dev;

I put those two lines in a +layout.server.js file and it totally resolved my problem. Of course it means I cannot confirm the SSR case for production, but at least I can now debug my Svelte app, vite successfully loads the page.

Thank you @Creskendoll !

I’m almost sure this is the problem with 90% of my bugs in my project.

My dev environment won’t trigger the file changes (so no hot reload and no page refresh) even after I fix my circular imports with madge. Meanwhile, my production environment throws an error when I refresh some of my views but its not possible to reach it because the problem is in a file in the dist folder.

I am trying to understand how a REACT page served by VITE works as expected in FireFox 121.0.1, but fails in both Chrome 117.0.5938.132 (company default) and also fails in Edge 120.0.2210.144. I start up my REACT with npm run dev which executes vite.

FireFox gives me a very nice network trace (attached). I have tried various settings in vite.config.js. All work in FireFox, but not in Chrome or Edge. I have tried clearing the browsers, rebooting my WinPC 10 Enterprise, Version 10.0.19045 Build 19045. Turning off extensions, etc. as suggested by an assortment of Stack Overflow et al suggestions. Those suggestions lead me to believe the problem rests with how I use VITE and not the browsers.

vite.config.js

import { defineConfig } from ‘vite’ import react from ‘@vitejs/plugin-react’

export default defineConfig({ plugins: [react()], define: { global: ‘globalThis’ }, server: { host: ‘375IT062368W1’, // Set this to your machine’s name port: 5173, // Set the desired port stringPort: true, hmr: { clientPort: 5173, strictPort: true, }, // open: process.env.BROWSER || ‘chrome’, }, })

package.json: { “name”: “dspo”, “private”: true, “version”: “0.0.0”, “type”: “module”, “scripts”: { “dev”: “vite”, “build”: “vite build”, “buildNote”: “when running vite build, it will load the env variables from .env.production if there is one”, “preview”: “vite preview” }, “dependencies”: { “@emotion/react”: “^11.11.3”, “@emotion/styled”: “^11.11.0”, “@mui/material”: “^5.15.3”, “@reduxjs/toolkit”: “^2.0.1”, “axios”: “^1.6.2”, “btoa-lite”: “^1.0.0”, “formik”: “^2.2.9”, “formik-material-ui”: “^4.0.0-alpha.2”, “mui”: “^0.0.1”, “react”: “^18.2.0”, “react-dom”: “^18.2.0”, “react-redux”: “^9.0.4”, “redux”: “^5.0.1”, “redux-thunk”: “^3.1.0” }, “devDependencies”: { “@types/react”: “^18.0.28”, “@types/react-dom”: “^18.0.11”, “@vitejs/plugin-react”: “^4.2.1”, “cross-env”: “^7.0.3”, “hint”: “^7.1.10”, “vite”: “^5.0.7” } }

vite handles imports like any other buildler like webpack, rollup, etc. Just because vite is who will join N-Files to single 1 . They should improve its circular imports error handling and should fails in compile time and provide a error stack to helps to identify the circular import problem, I’m working in golang and compiler always provide info about what files is causing the circular import issue, I know other bundlers already have it.

I also had this problem, and followed the instructions in this section of the Vite website: https://vitejs.dev/guide/troubleshooting.html#requests-are-stalled-forever

To use Ubuntu, what worked was the line * - nofile 65536 and restarting the machine.

Several people at our company started encountering this issue, and editing the .conf files fixed it for everyone. Manually changing ulimit and changing fs.inotify didn’t seem to do anything for us. We were all on Ubuntu or Mint, and the optional step of editing /etc/security/limits.conf didn’t seem to affect anything, either; one person just made that change and it didn’t fix it, but editing /etc/systemd/system.conf and /etc/systemd/user.conf did.

Apparently it worked for me, I’ve changed system and user .conf files

I think that’s only a temporal solution it will break soon or later once again, you need to find the file or files that importing circular references to definitively fix it

I also had this problem, and followed the instructions in this section of the Vite website: https://vitejs.dev/guide/troubleshooting.html#requests-are-stalled-forever

To use Ubuntu, what worked was the line * - nofile 65536 and restarting the machine.

Several people at our company started encountering this issue, and editing the .conf files fixed it for everyone. Manually changing ulimit and changing fs.inotify didn’t seem to do anything for us. We were all on Ubuntu or Mint, and the optional step of editing /etc/security/limits.conf didn’t seem to affect anything, either; one person just made that change and it didn’t fix it, but editing /etc/systemd/system.conf and /etc/systemd/user.conf did.

Incrementing ulimit doesn’t solve anything you need to find the files with circular imports to fix the problem, what could be very hard or depends if you’re lucky, Regards.

I also had this problem, and followed the instructions in this section of the Vite website: https://vitejs.dev/guide/troubleshooting.html#requests-are-stalled-forever

To use Ubuntu, what worked was the line * - nofile 65536 and restarting the machine.

Several people at our company started encountering this issue, and editing the .conf files fixed it for everyone. Manually changing ulimit and changing fs.inotify didn’t seem to do anything for us. We were all on Ubuntu or Mint, and the optional step of editing /etc/security/limits.conf didn’t seem to affect anything, either; one person just made that change and it didn’t fix it, but editing /etc/systemd/system.conf and /etc/systemd/user.conf did.

I also had this problem, and followed the instructions in this section of the Vite website: https://vitejs.dev/guide/troubleshooting.html#requests-are-stalled-forever

To use Ubuntu, what worked was the line * - nofile 65536 and restarting the machine.

How about windows users?

I also had this problem, and followed the instructions in this section of the Vite website: https://vitejs.dev/guide/troubleshooting.html#requests-are-stalled-forever

To use Ubuntu, what worked was the line * - nofile 65536 and restarting the machine.

OK. So I found something that seems to be working for me so far. I noticed that the app gets into an unhappy state once I hit a page that has some Capacitor dependencies. I see the message that Vite optimizes those dependencies and then the issue surfaces.

I disabled dependency optimization from occurring in Dev by adding the following to the vite.config.js (using SvelteKit) configuration:

optimizeDeps: {
    disabled: 'dev'
}

So far it seems fairly consistent of a fix on my end. YMMV

I am also having the same issue. The dev server hangs seemingly randomly and the site is not accessible on subsequent restarts. The built version works fine but I’m unable to work on the project locally which is very annoying.

I’m also using Sveltekit on a relatively big project so I cannot reproduce it. I’ve tried using the older versions of Vite, going back to 4.0.0, and the issue happens on all versions.

This leads me to believe that this might be a Sveltekit issue.

Might not be related at all but I noticed that the site hangs each time after this message: ✨ optimized dependencies changed. reloading

mine is a React application , and it i have the same issue.

For those that only reproduces with Chrome and using mac, this issue in Chrome might be related. https://bugs.chromium.org/p/chromium/issues/detail?id=1428744

I fixed all circular imports that were detected by https://www.npmjs.com/package/vite-plugin-circular-dependency, Vite dev is running fine. yay

I have recently update a project from Vue2 + Webpack to Vue3 + Vite and I have the same issue! Vite devs hangs indefinitely may probably occur in the following scenarios:

• After a clean build and restaring the server
• After some refreshing (F5)
• After some time when the user is using other tabs

The important thing I noticed is that the problem seems to be related to the browser cache. Specifically forcing the browser tab to close, clearing the browser cache, reopening the tab solves the problem. UPDATE: In Incognito tabs it works perferctly and it is even faster 🤔

Obviously the problem occurs often and is quite frustrating and this is rather sad considering Vite is very fast. On windows it is not even possible to use the config reported for Linux. Has anyone discovered anything along the way? Thank you

Spent 1.5 hrs trying to track this down, working all of the above possible issues only to find it was my @vscode insiders version not forwarding the port correctly. I don’t have a root cause, but flipping back to the stable release resolved the issue.

#11468 (comment)

Following up here - it’s been more than a month since we cleaned out all the circular dependencies we could find, and we have had substantially better stability.

I can confirm that hanging is related to circular imports. Removing them or even merely altering the import graph can fix the hanging. That being said, it seems not all cycles will result in hanging.

I’m working on putting together a minimal reproduction, but it’s proving a bit tricky because the example I have stops hanging when I simplify the dependency graph.

https://github.com/vitejs/vite/issues/11468#issuecomment-1607465388

Following up here - it’s been more than a month since we cleaned out all the circular dependencies we could find, and we have had substantially better stability.

So… This has become so bad now that I can’t get anything done. It locks up about every 2 minutes. I get to run something once, and when I refresh, it’s locked up again.

For the very simple demo I’m working on, I upgraded vite to the very latest v4.4.8 as well as everything else as shown here:

  "dependencies": {
    "@jamescoyle/vue-icon": "^0.1.2",
    "@mdi/font": "~7.2.96",
    "@mdi/js": "^7.2.96",
    "@teckel/vue-barcode-reader": "^1.0.4",
    "vue": "~3.3.4"
  },
  "devDependencies": {
    "@vitejs/plugin-basic-ssl": "^1.0.1",
    "@vitejs/plugin-vue": "~4.2.3",
    "vite": "~4.4.8"
  }

With the latest release, it’s even worse. Instead just hanging, the shell window totally locks up with vite --host running. I can’t hit r or h, not even ctrl-c will work. It’s totally hung. I need to close the shell and start over.

I tried a bunch of things, updated Chrome, disabled all Chrome extensions, running in Incognito, cleared all browser data, using Safari, etc. No change, vite locks up the terminal window. Tried different shells with the same result. At this point, I’d say vite development is 100% not functional on the Mac.

The number is probably an artifact from me testing. I set a different number in each setting to make confirm which settings where winning and just forgot to go back to the original value.

It looks like you have to both set the limit and adjust the security to allow you to set the limit. If you just set the limit ( but no security changes) the security settings prevent the change. If you adjust the security but not the limit - then you have permission to make the change but there is no change to apply. When you do them both you make a change that you have a permission to make.

This is my understanding from my experiments

@Creskendoll’s workaround of disabling Svelte SSR in dev also worked for me: I went from consistent hangs on a fresh load to no hangs.

Further investigation suggests that the * - nofile 65536 proposal, above, may indeed be at the heart of this, though I’m disinclined to think the presented diagnosis is accurate.

The etc/security/limits.conf dictates the max number of concurrent file descriptors a given process may have open, not the OS.

In support of this: Kafka has an interesting notation on the topic, specifically:

Many modern Linux distributions ship with only 1,024 file descriptors allowed per process. This is too low for Kafka.

You should increase your file descriptor count to at least 100,000, and possibly much more. This process can be difficult and is highly dependent on your particular OS and distribution. Consult the documentation for your OS to determine how best to change the allowed file descriptor count.

Chrome can be fairly demanding as far as processes go, but, more relevantly (to Vite, anyway), is a quote from David Schwartz:

If the number is growing because they’re legitimately using more network connections or files, then you can keep raising it, at least until you hit the limit of what the software can handle. But if it’s a file descriptor leak, that should be investigated and fixed (emphasis added by me).

I suspect, strongly, that there’s something bleeding folk up over this line. More prevalent in large file-count, high resource applications, and more noticeable on Linux, which still ships with a comically-low preset max, evidently. And I’ll just bet that, when taken with a secondary process - yanno, like the one that ships with React? - that precipitates the forceful reloading of a huge number of itty bitty files - possibly if two such events overlap? Like saving twice in rapid succession? - that such a bleed would prove nearly inevitable.

UPDATE (Ubuntu fix, for us, at least; YMMV):

For me/us at least, upping the max in limits.conf appears to have done the trick. For those who want a nice and easy way to accomplish same… paste the following command into your terminal (doesn’t matter, your starting folder, although you must have sudo rights for this command to work):

LIMCONF=/etc/security/limits.conf;  [ ! -f $LIMCONF ] && sudo touch $LIMCONF;  sudo chown $(whoami) $LIMCONF;  sudo chmod 666 $LIMCONF;  sudo echo "* - nofile 262144" >> $LIMCONF;  sudo chmod 644 $LIMCONF;  sudo chown root $LIMCONF;  unset LIMCONF

…and since you should NEVER run shell code without understanding precisely what it’s doing (you can totally run the below block instead, if you feel better about it):

LIMCONF=/etc/security/limits.conf;                  # Create shorthand variable to file path
[ ! -f $LIMCONF ] && sudo touch $LIMCONF;           # If a file at this path doesn't exist, create it.
sudo chown $(whoami) $LIMCONF;                      # Set the currently-active user as the file's owner
sudo chmod 666 $LIMCONF;                            # Set its perms to Write/Write/Write (make it editable)
sudo echo "* - nofile 262144" >> $LIMCONF;          # For the default (all) domains: set max open file 
                                                    # descriptors to 512^2 (2^18), & APPEND command to file
sudo chmod 644 $LIMCONF;                            # Reset file to original perms (Write/Read/Read)
sudo chown root $LIMCONF;                           # Reset file to original owner (root)
unset LIMCONF                                       # Remove shorthand variable path

…hope this helps!

(Note: you must REBOOT your machine after this alteration for it to take effect. Not restart your shell. Not log out and log back in. Reboot. Off, then on again).

Same as the other posters; Ubuntu 23.04, Chrome 114.0.5735.90 (64-bit), Top-end Ryzen with 64GB RAM.

Now, some additional things I’ve not seen anyone else mention, but MIGHT be diagnostically significant: We’re also, perforce, running docker in the background. Ours is a massive WebApp AI project (1,478 requests being made on initial hit) that communicates with Rust and C SO’s. “Resource intensive” is not overstating it.

Behavior is similar to that described above: the issues are, hands-down, most prevalent in Linux, though manifest in MacOS and WSL as well. There appears to be some threshold of accumulation, too. That is to say, something will abruptly knock it into functioning again, temporarily, and then, after an indeterminate amount of - time? Uptime? Requests? Throughput? Cache/page file availability? SOMETHING - the behavior resumes.

I have a strong suspicion this is a faulty caching mechanism of some flavor, either precipitating an infinite recursion or causing some form of overflow and the errors aren’t bubbling. No reason to assert this other many, many years as a front-end dev and recollected parallels of other, vague, similarly-enraging, intermittent issues.

great call out on docker usage, we also have docker running our whole db set up. Not sure if this is the same behavior your experiencing, but our vite server only seems to hang when certain components are edited but not others it also does not hang if code is directly edited in a +page.svelte file. I don’t have enough low-level knowledge of what might be going on under the hood but not sure why that would be the case regardless of whether or not docker (or a similarly memory / resource intensive service) is running on the same machine.

Update:

It seems to be entirely related to accessing the dev server on an external ip when using host: true. The first access will work, but any subsequent access will freeze the server, requiring the user to terminate the terminal as even cmd+c/d doesn’t work.

Having the problem on windows too

Additional note : even adding a character in a comment strings makes the tab completely freeze

Yet, stopping yarn and restaring it works everytime. But it is very unpractical as for every modifications you would have to do it

I’ve just encountered this issue on Linux (Ubuntu 20.04) and Chrome. No errors, just infinite loading. @aspnetde mentioned that for him it’s browser related, so I went on and tried and - yes, it loads just fine in Firefox. I thought it should be some invalid Chrome env, so I loaded it in incognito mode. Same infinite loading.

There got to be some issue in communications protocol in Chrome, or something along the lines.

Did you try any of the suggested suggested Linux fixes? https://github.com/vitejs/vite/issues/11468#issuecomment-1419820986 https://vitejs.dev/guide/troubleshooting.html#dev-server

@fc do you know if fastify-vite can achieve similar results?

@benatshippabo, I do not know and am unable to test that so easily. We had to customize the fastify config beyond what I posted since we have a number of dynamic routes that needed to be forwarded.

I was pretty curious about this comment since I had never tried that but we had migrated over to fastify and haven’t needed revisit the problem since then.

Hello ! We experienced a similar issue on MacOS & Chrome, with Vite and dev server in https mode. (No Nuxt here)

This is a webgl experience website and we need to preload lots of texture images. The issue happens almost every time when loading a lot of png in parallel, using a standard img.onload method.

• Using a valid certificate with mkcert instead of a self-signed didn’t do anything for us for the first visit and when the chrome cache is disabled via the inspector.
• Switching to http instead of https fixes the issue
• Limiting the number of file preloaded in parallel manually in JS also fixes the issue
• We did not experience the issue when proxying the devserver through cloudflare tunnel or ngrok.

@fc can you explain more how to set up the fastify proxy to replace the default vite one?

@maxsalven: 1 - add dependencies yarn add -D @fastify/http-proxy fastify 2 - copy and the paste the code in my previous post into a file at the root of project called proxy.js 3 - start vite yarn dev 4 - from the CLI run node proxy.js 5 - go to http://localhost:3001 in your browser

You could add a scripts command with node proxy.js in your package.json to make it easier to run in the future.

You could also turn this into a vite plugin to be a far more seamless DX.

This will specifically solve the issue where network requests get stuck in pending.

I had the same problem (pretty frustrating), and as I figured out, the issue was that I mistakenly nested a React component inside itself, which probably resulted in infinite recursion. (I’m not implying that other people’s problems are caused by their own bugs! just my experience).

@roligheten That sounds like you have an infinite loop somewhere in your app.

In this particular issue, the dev server fails to respond during server-side rendering. I am using SvelteKit and In my case, the fetch requests made from +layout.ts never resolve. Those requests are made to the SvelteKit endpoints like /account/me.json and those endpoints never receive the requests. This causes the load function to never finish since it’s stuck awaiting the requests to resolve, thus hanging the app indefinitely.

// +layout.ts
// This runs but never resolves
const accountRes = await fetch(`/account/me.json`).then((res) => res.json()).catch(console.error);

// routes/account/me.json/+server.ts
export const GET: RequestHandler = async ({ request }) => {
// This function never gets called
})

I don’t use Sveltekit and had to switch to non-secure connections (http) during debugging (which is not a big deal, just a bit annoying, having this working for such a long time, before I switched to vite).