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

[hanszoons]

Describe the bug

I use SvelteKit. I have a somewhat complex page that contains quite a lot of components and imported functions. I had sporadic problems with this page hanging in the browser (both Firefox and Chrome). However, no error or notification in the vite cli. I was usually able to fix this by restarting the dev server several times whether or not in combination with restarting the browser. Other, simpler pages, always just kept working. Restarting my computer always works.

In recent days, I have been adding extra functionality, and the more I added, the more often the page kept hanging and the harder I got it to work again. When I get the page online (after frequently restarting everything I get restarted), everything just works. Until I make an adjustment in the code and because of the HMR the thing hangs again. I don't see any other pattern to it.

The problem does not occur when I build and preview the page, the production code always works.

It's driving me crazy, I can hardly get anything developed.

Reproduction

I can't build a reproduction, there is no pattern.

Steps to reproduce

It happens only on the dev server. I can find no pattern, cannot pinpoint a cause and thus cannot foresee any reproduction. There is nothing wrong with the code itself, the production build works perfectly.

The debug logs below are what I get when browsing to /leerlijn/54159.
It starts doing it's thing, and then just randomly stops at some point.

System Info

System:
    OS: macOS 13.0.1
    CPU: (10) arm64 Apple M1 Pro
    Memory: 12.20 GB / 32.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 18.12.1 - ~/.nvm/versions/node/v18.12.1/bin/node
    npm: 8.19.2 - ~/.nvm/versions/node/v18.12.1/bin/npm
  Browsers:
    Chrome: 108.0.5359.124
    Firefox: 108.0.1
    Safari: 16.1
  npmPackages:
    vite: ^4.0.3 => 4.0.3

Used Package Manager

npm

Logs

Posted here: https://gist.github.com/hanszoons/2c511fa66ad76bd5181f84f7f7115eb5 because of the maximum 65536 characters.

These are the logs when requesting the page /leerlijn/54159, after wich it simply hangs indefinitely.

The second file are the logs when the page is rendered successfully. Same exact code, same config, same everything. Just some dev server restarts and good luck. 1 code change with HMR and the thing hang again.

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[fc]

I have also run into chrome spontaneously crashing (well just the tab) seemingly due to HMR but there was nothing useful that came out of verbose logging or anywhere else. When you say it stops working/hangs, what does it show in the browser?

[hanszoons]

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.

[hanszoons]

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.

[fc]

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.

[wtachau]

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.

[mike-lischke]

Same problem here, but with a preact app that uses web workers with very large TS files (a parser). HMR is not my problem, though. I can run the app once. Have to wait a couple of seconds until everything is loaded. Then I go to the page that requires parsing and get a couple of these messages:

[BABEL] Note: The code generator has deoptimised the styling of undefined as it exceeds the max of 500KB.

Once the last of the message is through I can actually use the page and the worker (pool) works. Then I try to restart the app and nothing works anymore. It just hangs and after a while I get a timeout error.

When I now try to stop the dev server (by pressing q in the VS Code terminal) nothing happens. Same for ctrl+c. I have to kill the process and start the dev server again before I can continue. This is so annoying. If I only had a log that would tell me what's going wrong...

[mike-lischke]

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.

[fc]

@mike-lischke if you do need/want https, you need to trust the ssl by manually setting it to be trusted in Keychain Access on macOS.

I had submitted a PR that added instructions/info about this on the troubleshooting page.

#11126

[mike-lischke]

Yes, I know. We do this automatically in our VS Code extension. But for the dev builds I hoped I could get away with that plugin and didn't expect such troubles once the browser accepted the connection. Thanks a bunch for your help @fc!

[mike-lischke]

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.

[Creskendoll]

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

[mike-lischke]

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).

[fc]

Based on this comment - has anyone tried using an older version of node (16.15 instead 18.x) - this could be a possible solution for the infinite pending requests in the network tab:
#7620 (comment)

[Creskendoll]

@fc I am using v16.18.0. I tried 16.15.0 and the same thing still happens. I've been using the same version of Node all along and this issue started happening recently.

[ruigil]

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 !

[roligheten]

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)

[Creskendoll]

@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
})

[rkurbatov]

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.

[rkurbatov]

Based on this comment - has anyone tried using an older version of node (16.15 instead 18.x) - this could be a possible solution for the infinite pending requests in the network tab: #7620 (comment)

I tried versions 14, 16 and 18. It looks like Chrome problem, not the Node problem because it works on FF on all Node versions but hangs in Chrome only.

[rkurbatov]

So I found the fix (at least to my problem). This problem is similar to this one:
#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.

[ximus]

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

[rkurbatov]

I'll have to keep looking.

Did you try what I suggested? Seems like that's a known issue but proposed fix doesn't work.

[roligheten]

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 🥇

[hanszoons]

I am not on Linux, but on a Mac and Firefox has the same issue. In what way does #11959 close this?

[chanmathew]

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

[brittneypostma]

I had this same issue on a mac and this seems to have fixed it for now.. I searched around for how to check max files similar to the ubuntu linux fix and found this info for macs.
Check the current limit:
launchctl limit maxfiles
The response output should have numbers like this:
maxfiles 65536 200000
If instead, you have an output like this, then you need to change the numbers.
maxfiles 256 unlimited
Change the maxfiles limit:
sudo launchctl limit maxfiles 65536 200000
Reboot computer

[brittneypostma]

Scratch that, its happening again.

[afternoon2]

Same for Vite when building my Storybook documentation, both locally on MacOS, and in GitLab CI.

vite v5.1.4 building for production...

./sb-common-assets/fonts.css doesn't exist at build time, it will remain unchanged to be resolved at runtime
[plugin:vite:resolve] Module "fs" has been externalized for browser compatibility, imported by "/Users/jakubantolak/Documents/GitLab/apps/node_modules/next/dist/compiled/gzip-size/index.js". See https://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.
[plugin:vite:resolve] Module "stream" has been externalized for browser compatibility, imported by "/Users/jakubantolak/Documents/GitLab/apps/node_modules/next/dist/compiled/gzip-size/index.js". See https://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.
[plugin:vite:resolve] Module "zlib" has been externalized for browser compatibility, imported by "/Users/jakubantolak/Documents/GitLab/apps/node_modules/next/dist/compiled/gzip-size/index.js". See https://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.
transforming (14496) ../../node_modules/next/dist/client/router.js

[Myphz]

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 👍

Thank you so much for this fix, works great.

I noticed that Vite started to hang indefinitely only if the page uses a {each} loop... If I remove the {each} loop, Vite works regularly.
This issue arises only if the page with the each loop is the first one to be rendered. After running npm run dev, loading /a-page-without-each-loop loads correctly, and from that I can go to /page-with-each-loop with no issues, until I make a change, that is...

[afternoon2]

Same for Vite when building my Storybook documentation, both locally on MacOS, and in GitLab CI.

vite v5.1.4 building for production...

./sb-common-assets/fonts.css doesn't exist at build time, it will remain unchanged to be resolved at runtime
[plugin:vite:resolve] Module "fs" has been externalized for browser compatibility, imported by "/Users/jakubantolak/Documents/GitLab/apps/node_modules/next/dist/compiled/gzip-size/index.js". See https://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.
[plugin:vite:resolve] Module "stream" has been externalized for browser compatibility, imported by "/Users/jakubantolak/Documents/GitLab/apps/node_modules/next/dist/compiled/gzip-size/index.js". See https://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.
[plugin:vite:resolve] Module "zlib" has been externalized for browser compatibility, imported by "/Users/jakubantolak/Documents/GitLab/apps/node_modules/next/dist/compiled/gzip-size/index.js". See https://vitejs.dev/guide/troubleshooting.html#module-externalized-for-browser-compatibility for more details.
transforming (14496) ../../node_modules/next/dist/client/router.js

OK, I don't know what has been fixed, but after bumping Vite to 5.1.6 the build went smoothly 😅

[quasarchimaere]

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

the update did not resolve this issue for me, but the disable ssr in dev workaround suffices (for now)

[knd775]

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

[BYK]

Can also confirm that dropping to 5.1.7 fixed my issue and I was having this with 5.2.2.

[rogerfar]

I have had success with this PR: https://github.com/shYkiSto/vite/tree/fix-ssr-deadlock

To get it running:

git clone https://github.com/shYkiSto/vite.git
cd vite
git checkout fix-ssr-deadlock
pnpm i
pnpm run build
cd packages\vite
npm link

Then in your project folder run:

npm link vite

It will now use the local package instead of the registry package.

[NotNullDev]

I had same issue with sveltekit, fortunately I do not use ssr features, so I disabled ssr and prerendering as mentioned above.
Intial loading time went from 90s+ to ~6s.

[patagoniapy]

Having the same issue with SvelteKit and dropping to 5.1.7 resolved it for me

[douglasware]

Seeing this issue suddenly on vite 5.2.10 hanging forever "transforming..."

[sharky98]

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.

[MattpaulKing]

I have had success with this PR: https://github.com/shYkiSto/vite/tree/fix-ssr-deadlock

To get it running:

git clone https://github.com/shYkiSto/vite.git
cd vite
git checkout fix-ssr-deadlock
pnpm i
pnpm run build
cd packages\vite
npm link

Then in your project folder run:

npm link vite

It will now use the local package instead of the registry package.

This also resolved my issue.

Node 20.11
Sveltekit
Chrome / Firefox both affected
Ubuntu 22.04

[brittneypostma]

Based on this comment - has anyone tried using an older version of node (16.15 instead 18.x) - this could be a possible solution for the infinite pending requests in the network tab:

If you are on Svelte 4, Node 18 is required and you get this when trying to run the dev server. ReferenceError: Request is not defined

I have been running into this issue more and more lately and it is currently blocking me from working.

[brittneypostma]

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 was hoping this would fix it, but it doesn't seem to have worked for me 😢

Update: I repackaged my monorepo dependencies and after restarting the server again, the server did run. I'm not 100% sure that this was the fix, but at least for me it seems to be a package issue with monorepos.

[ethanfox]

Seems like a weird memory issue. I ran pnpm build and forgot about it while looking into this issue. I then went into VS Code and saw the build process starting after like 20 minutes of idling.

[shiftlabs1]

done round about every thing suggested on this issue , still no joy . I hope this gets fixed once and for all.

[gyurielf]

We suffer from this at least more than a year. (OFC we tried every suggestion)
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.

[zFlxw]

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 👍

Unfortunately, this doesn't work for me. I disabled SSR for all protected pages in my app when I started the project, and I still encounter this issue.

Thank you so much for this fix, works great.

I noticed that Vite started to hang indefinitely only if the page uses a {each} loop... If I remove the {each} loop, Vite works regularly. This issue arises only if the page with the each loop is the first one to be rendered. After running npm run dev, loading /a-page-without-each-loop loads correctly, and from that I can go to /page-with-each-loop with no issues, until I make a change, that is...

This also doesn't seem to be the case for me. At first that seemed fitting because I did not get this infinite loading state when accessing the root page or login page (both not containing any loops) as first route after (re-)starting the server, so I removed all each blocks from my dashboard page (and all child components it uses), but the page still ended in an infinite loading state after accessing it as first page after a restart.

My current workaround is that when this deadlock happens, I navigate to my homepage (or the "/" route), kill the server, and then restart it. After accessing this page as the first one, everything works. Unfortunately, it only takes like 2-3 changes and I end up in this deadlock again.

[svelte-kit-so-good]

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 👍

Thanks man! This DEV hanging happened twice now with barrel exports ... I'm not even sure why it went away previously (months ago). For context this is my current svelte and vite package versions:

"@sveltejs/kit": "^2.5.7",
"svelte": "5.0.0-next.120",
"vite": "^5.2.11"

[gyenabubakar]

I have had success with this PR: https://github.com/shYkiSto/vite/tree/fix-ssr-deadlock

To get it running:

git clone https://github.com/shYkiSto/vite.git
cd vite
git checkout fix-ssr-deadlock
pnpm i
pnpm run build
cd packages\vite
npm link

Then in your project folder run:

npm link vite

It will now use the local package instead of the registry package.

@rogerfar how did you get past this error:

npm ERR! code EUNSUPPORTEDPROTOCOL
npm ERR! Unsupported URL Type "link:": link:./src/types

[dslatkin]

Just got bit hard by what I think is this bug which I think could be fixed by #15395. Thankfully git bisect and the practice of trying to use smaller commits made it much easier to isolate exactly which commit introduced what was a circular dependency.

I would like to make a repro in the next few weeks, but until then, I can share the general setup:

1. We have a PageHeader component
2. We have a Separator component (basically a fancy <hr>)

Separator can be used anywhere in the project. It behaves a bit differently when used in the PageHeader component, since at desktop width, the color changes. So:

1. PageHeader depends on Separator (as one component being used in another's template)
2. Separator depends on PageHeader (since it imports the key from PageHeader used to retrieve context)

Whenever we'd save PageHeader, the dev server would hang. Managed to fix the issue by not importing a context key, instead I just used another prop called invertDesktopColor. In the end, I think this is probably the better way to design the component, but it sure was hard to figure out.

[itayperry]

@dslatkin

Just got bit hard by what I think is this bug which I think could be fixed by #15395. Thankfully git bisect and the practice of trying to use smaller commits made it much easier to isolate exactly which commit introduced what was a circular dependency.

I would like to make a repro in the next few weeks, but until then, I can share the general setup:

1. We have a PageHeader component
2. We have a Separator component (basically a fancy <hr>)

Separator can be used anywhere in the project. It behaves a bit differently when used in the PageHeader component, since at desktop width, the color changes. So:

1. PageHeader depends on Separator (as one component being used in another's template)
2. Separator depends on PageHeader (since it imports the key from PageHeader used to retrieve context)

Whenever we'd save PageHeader, the dev server would hang. Managed to fix the issue by not importing a context key, instead I just used another prop called invertDesktopColor. In the end, I think this is probably the better way to design the component, but it sure was hard to figure out.

I think it is probably best if vite could notify the developer about a circular dependency

[dslatkin]

I think it is probably best if vite could notify the developer about a circular dependency

I think merging #15395 so circular dependencies are supported like they are in ESM would be best, so Vite does not always hang for its own reason when it finds a circular dependency.

If circular dependencies are officially not something Vite supports, then I think a minor version bump to add a warning when one is detected and a major version bump to throw an error when it detects one would be second best.

@itayperry