Maximum call stack size exceeded

[ryanjwilke]

🔎 Search Terms

call stack exceeded

🕗 Version & Regression Information

• This changed between versions 5.8.3 and 5.9.2
• This changed in commit or PR _______
• This is the behavior in every version I tried, and I reviewed the FAQ for entries about _________
• I was unable to test this on prior versions because _______

⏯ Playground Link

No response

💻 Code

// Your code here

🙁 Actual behavior

We noticed that there's a potential regression between the versions 5.8.3 and 5.9.2.

When allowing Dependabot to bump from 5.8.3 to 5.9.2, we started seeing the yarn astro check command failing with the following output:

🤟 ~/Sites/[project] (dependabot/npm_and_yarn/dev/typescript-5.9.2): yarn astro check          
19:42:18 [content] Syncing content
19:42:18 [content] Synced content
19:42:18 [types] Generated 103ms
19:42:18 [check] Getting diagnostics for Astro files in project...
Maximum call stack size exceeded
  Location:
    [project]/node_modules/typescript/lib/typescript.js:3371:46
  Stack trace:
    at String.replace (<anonymous>)
    at getCanonicalFileName ([project]/node_modules/typescript/lib/typescript.js:129084:17)
    at toPath3 ([project]/node_modules/typescript/lib/typescript.js:127606:12)
    at findSourceFile ([project]/node_modules/typescript/lib/typescript.js:128749:20)
    at findSourceFile ([project]/node_modules/typescript/lib/typescript.js:128749:20)

🙂 Expected behavior

I would expect the yarn astro check command to succeed with hopefully no type issues since nothing else was changed in the PR other than the version being bumped.

Additional information about the issue

No response

[DanielRosenwasser]

Would you be able to use every-ts exec and every-ts bisect to figure out which commit started causing issues?

https://github.com/jakebailey/every-ts

[fkling]

We are seeing this too in LS logs. Looking at the commit history for the lines of code in question, it seems a likely candidate is 3dd0a35#diff-dbfa0e7f632eca196a5ee0e08e00743c46c03799e2704206cfccc065bb6f9e3aR3593

[jasonlyu123]

We have seen a report similar to this in sveltejs/language-tools#2819. The problem is that a non-TS/js file is included as a project file in both tsconfig.json and the project reference tsconfig.web.json.

The infinite recursive is related to useSourceOfProjectReferenceRedirect. The commit linked by @/fkling added a step to pre-calculate a map for mapping a .dts to its source file. However, because ".svelte" or ".astro" isn't a predefined file extension. The map ends up mapping the file to itself.

TypeScript/src/compiler/program.ts

Line 4091 in 7956c00

outputDts = getOutputDeclarationFileName(fileName, resolvedRef.commandLine, !host.useCaseSensitiveFileNames(), getCommonSourceDirectory);

The fix is probably to ignore the file when getOutputDeclarationFileName returns the same name as the input. I know languageServiceHost.useSourceOfProjectReferenceRedirect is an internal API and the cause is a weird config, so I think it's also okay not to fix it. Since "fixing" the config should fix the problem.