✅ Deploy Preview for vitest-dev ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	f40d32e
🔍 Latest deploy log	https://app.netlify.com/sites/vitest-dev/deploys/66fbc6190b095d0008161a0e
😎 Deploy Preview	https://deploy-preview-6600--vitest-dev.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

FYI I've just released a 0.2.8 hotfix 😅 you might want to update to that instead

@SuperchupuDev It looks like this exotic case #6274 (comment) came back as failing/timeout? I ran it locally on my Linux PC and this indeed gets stack.

pnpm -C test/reporters test custom-reporter -- -t 'load no base'

interesting, i'll take a look tomorrow. meanwhile, can you try to tell me the exact glob usage that makes it get stuck? basically a minimal repro

@SuperchupuDev I tried a repro but it looks quite puzzling. It's likely that this is related to the scenario like SuperchupuDev/tinyglobby#53, but behavior-wise, it's same as v0.2.6, so maybe something happened internally which is affecting performance of large node_modules crawling.

I can only reproduce the difference between v0.2.6 and v0.2.8 on Vitest repo's node_modules. I added test/reporters/repro.mjs, which should stuck only on v0.2.8. I hope it would help the investigation.

CI is passing for Mac and Windows, but this is because the test is skipped on CI, so I would assume the issue is same for non Linux too:

i think i know what's going on, node_modules are linked to each other when using pnpm, making fdir recursively crawl those. if two packages use each other it probably enters an infinite loop. i wonder how fast-glob handles that

@hi-ogawa can you tell me if it works using "tinyglobby": "https://pkg.pr.new/tinyglobby@1f1fa12" in the package.json? let me know if it does then i'll do a new release

@SuperchupuDev Thanks for quick follow up. I confirmed https://pkg.pr.new/tinyglobby@1f1fa12 is working locally. I'll push it here to check CI now.

i think i know what's going on, node_modules are linked to each other when using pnpm, making fdir recursively crawl those. if two packages use each other it probably enters an infinite loop. i wonder how fast-glob handles that

Good spot. That might be it since we have a cyclic workspace warning by pnpm like this:

$ pnpm i
Scope: all 47 workspace projects
 WARN  There are cyclic workspace dependencies: /home/hiroshi/code/others/vitest/packages/browser, /home/hiroshi/code/others/vitest/packages/vitest
...

great, glad that it works. i've just released 0.2.9 that reverts the symlinks resolution support

@hi-ogawa fyi i've just released 0.2.10 which adds back symlinks resolution, without a critical bug this time 😅

Closing as per #6688