[vite] Internal server error: Maximum call stack size exceeded

[nathan-de-pachtere]

Vue version

3.4.28 and above

Link to minimal reproduction

https://play.vuejs.org/#eNq1U01v00AQ/SujVYUTKSQicEAmTVWgh3KACjiuRCxnnGzrrK3dcRuw/N+ZWSeuk34gDr3EmY+dffPe21qdl+X4tkIVq5lPnSkJPFJVQp7Y1alW5LWaa2s2ZeEIanCYjWCJmbF47n/b9FPBFYuWoIHMFRuIeFikrbZpYT2B1N/A6aNHBoMhnM6hnT2IxpPQLGii4fCDtrNJi4jv54BwU+YJIUcAs3auTTbIIF2R3iBpBWtjieO10WrCfbNJ75Aa8TIMKjOr8bUvLG9cyyitUp5lcnTfSjIMWqsYQkVqSZ4Xd19CjlyFo30+XWN680j+2m8lp9WVQ4/uFrXqapS4lcCU8sWPr7jl/11xUyyrnLufKX5HX+SVYGzbPlZ2ybB7fQHtZeDT2NVPf7EltH6/lACVzib0a8VEC41PrX4P9+34XTinbcMsdiqJZ3oEawqqTOWfpninjXy02uXYWpzi3/uM+SNd8glGk+TMl4md13WQE5qGfSCJfTEvaM4p+YRLg22mx3JzuPNzz8mtt/t+vnJF6Tvvtha8tIQuS1KM2IRd5z9Nz81910//x/XTe9dre2do/RmzpMrJD9oRAeasZeQsBk+O9eXbX7ULzAfDkQinSRpiYGOEY0tWWhMvHUOUJXnEYXP0snaCBgAPBTUQp3niPfO3OKl5EJwJhxDm+YjXT16f1KJxA1xnFblhEZISNAvpjJpFT9sH8pmXku4ZJo9YO2CIQ4Z+SOITrHXXjckzebgN0FiCNruDuL+iE06wkZB2kJBb+y3y1n7dopP3y8P5EY6n71XzF6Pj9hY=

Steps to reproduce

Trying to reproduce inside SFC playground but no error showing up ...

Anyway, I was migrating from 3.4.21 to latest release (3.4.32) and my project didn't work anymore, no change in the code just upgraded vue.js version.

So I went minor version by minor version and the last vue.js version working is the 3.4.27 and then with 3.4.28 I got the vite error message [vite] Internal server error: Maximum call stack size exceeded targeting the file on component (in my case : "File: /home/xxxx/projects/MyComponent.vue")

Something wrong with the Props definition from external files and using them in two components. The error go away if I change my defineProps lines in both components (see SFC playground for context). Then hit another similar issue with another component trickier, can't find a way to solve it ...

What is expected?

Expected to work like previous version

What is actually happening?

An error is thrown :

11:45:20 AM [vite] Internal server error: Maximum call stack size exceeded
  Plugin: vite:vue
  File: /home/xxxx/projects/MyComponent.vue
at visitDirectory (/home/xxxx/projects/node_modules/typescript/lib/typescript.js:22211:60)
at visitDirectory (/home/xxxx/projects/node_modules/typescript/lib/typescript.js:22212:9)
at matchFiles (/home/xxxx/projects/node_modules/typescript/lib/typescript.js:22180:5)
at Object.readDirectory (/home/xxxx/projects/node_modules/typescript/lib/typescript.js:8764:14)
at getFileNamesFromConfigSpecs (/home/xxxx/projects/node_modules/typescript/lib/typescript.js:42798:29)
at getFileNames (/home/xxxx/projects/node_modules/typescript/lib/typescript.js:42291:23)
at parseJsonConfigFileContentWorker (/home/xxxx/projects/node_modules/typescript/lib/typescript.js:42195:16)
at Object.parseJsonConfigFileContent (/home/xxxx/projects/node_modules/typescript/lib/typescript.js:42128:10)
at loadTSConfig (/home/xxxx/projects/node_modules/@vue/compiler-sfc/dist/compiler-sfc.cjs.js:18640:22)
at loadTSConfig (/home/xxxx/projects/node_modules/@vue/compiler-sfc/dist/compiler-sfc.cjs.js:18655:22)

System Info

System:
    OS: Linux 6.5 Ubuntu 22.04.4 LTS 22.04.4 LTS (Jammy Jellyfish)
    CPU: (8) x64 Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz
    Memory: 21.54 GB / 31.29 GB
    Container: Yes
    Shell: 5.8.1 - /usr/bin/zsh
  Binaries:
    Node: 20.8.0 - ~/.proto/shims/node
    Yarn: 3.6.4 - ~/.proto/shims/yarn
    npm: 9.7.1 - /usr/local/bin/npm
  Browsers:
    Chrome: 126.0.6478.126


Same on MacOS

Any additional comments?

Running into that error when updating vue.js package from 3.4.21 to 3.4.31

[yyx990803]

I downloaded the playground as a local Vite project and cannot reproduce the issue. Both dev and build are working as intended.

Could you please provide a repo that can actually show the error?

[nathan-de-pachtere]

@yyx990803 I can provide access to the repository, but not publicly as it's part of the company. However, I can invite you to it if that works for you.

[nathan-de-pachtere]

@yyx990803 Invitation sent through GitHub : repo named alpsify, it's a monorepo running with Moonrepo and Yarn workspace.

You have to change vue version for the entire project by searching for "vue": "3.4.27" and replacing by "vue": "3.4.28". Then launch the project in apps/alfred-app by running moon alfred-app:dev-spa. And you're going to have the error after a little freeze / slow loading of the app when accessing it in the browser.

You can also test with moon alfred-review-app:dev or moon alfred-sign-app:dev.

The error should appear linked to the AlfredIcon.vue or AlfredListResource.vue component

[nathan-de-pachtere]

@yyx990803 I guess this is linked to this modification bdeac37 in the 3.4.28 version

[yyx990803]

@nathan-de-pachtere I can't find the invitation in my emails. Can you just post the link to the private repo here?

[nathan-de-pachtere]

@yyx990803 Here it is : https://github.com/alpsify/alpsify

[nathan-de-pachtere]

Still an issue on 3.4.38. @yyx990803 Did you get access to the repo ?

[nathan-de-pachtere]

@yyx990803 I tried using version 3.4.38 and modified the code in the compiler-sfc.cjs.js file as follows:

• Removed the update made for this issue: tsconfig project reference didn't support folder #10907

function loadTSConfig(configPath, ts2, fs) {
  const parseConfigHost = ts2.sys;
  const config = ts2.parseJsonConfigFileContent(
    ts2.readConfigFile(configPath, fs.readFile).config,
    parseConfigHost,
    path$3.dirname(configPath),
    void 0,
    configPath
  );
  const res = [config];
  if (config.projectReferences) {
    for (const ref of config.projectReferences) {
      tsConfigRefMap.set(ref.path, configPath)
      res.unshift(...loadTSConfig(ref.path, ts, fs))
      /*const refPath = ts2.resolveProjectReferencePath(ref);
      if (!fs.fileExists(refPath)) {
        continue;
      }
      tsConfigRefMap.set(refPath, configPath);
      res.unshift(...loadTSConfig(refPath, ts2, fs));*/
    }
  }
  return res;
}

After confirming that everything works correctly with the changes, I started digging deeper into the reason behind this modification.

I also work in a monorepo with Yarn workspaces and Moonrepo. I maintain a single tsconfig.json file at the root of my monorepo for a consistent development experience and uniformity. And yes, I do have multiple tsconfig.json files in my packages referencing each other : this part is handled automatically by the Moonrepo CLI to ensure that every package is in sync. And also sync paths.

Maybe I'm missing something about how tsconfig.json files work, but the issue definitely lies within those lines of code.

Or maybe it's the way pnpm handles workspaces compared to yarn that causes everything to break with yarn... I’m not really sure why this issue came up.

I also tried cleaning up the tsconfig.json files to match the test case, but it’s still not working.

[nathan-de-pachtere]

@yyx990803 Looking at the reproducer in #10907, it appears that a code change was made in Vue.js to address a problem that actually stems from the project's specific structural choices.

Specifically:

• This is not a true monorepo example: the src/folder isn’t an independent package used by the main project, just a folder within the project.
• The project should be using Vite alias to match the TypeScript path resolve option like explained here https://stackoverflow.com/questions/77249074/how-do-i-use-typescript-path-aliases-in-vite
• The vite.config.js file is at the root of what's being called a monorepo but should be wrapped in a "project folder." Then, the resolve configuration should be used to match paths to the necessary libs/packages.
• A package named whatever should be created to store types or other pieces of code, which can then be used within other libs or apps projects.

Overall, it feels like the fix addresses an edge case that arises from specific, custom structural choices rather than following the "standard" approach.

Or maybe I'm missing something. If @cyrilluce from #10907 could join the discussion, that would be great.

[cyrilluce]

@nathan-de-pachtere
I'm guessing if there are circular reference in your tsconfig?

Try to modify code to verify

  if (config.projectReferences) {
    for (const ref of config.projectReferences) {
      const refPath = ts.resolveProjectReferencePath(ref)
      if (!fs.fileExists(refPath)) {
        continue
      }
      // ------ Add these code
      if(tsConfigRefMap.has(refPath)){
        continue
      }
      // --------
      tsConfigRefMap.set(refPath, configPath)
      res.unshift(...loadTSConfig(refPath, ts, fs))
    }
  }

[nathan-de-pachtere]

@cyrilluce First, thanks for joining the discussion.

The change you suggested makes it work:

if(tsConfigRefMap.has(refPath)){
        continue
      }

Could you explain how this change resolves the issue? Feels like I'm gonna learn something here. =D

We use multiple Python scripts to check for circular dependencies at multiple levels (package, tsconfig, import), and nothing shows up. Also, Madge and DepsCruiser. We have a monorepo with 6 projects and over 100 lib packages that reference each other and for sure used by projects, so we continuously monitor for circular dependencies to avoid issues. Additionally, our tsconfig.json files are entirely managed by Moonrepo, our solution for managing the monorepo. So we don’t manually change the references and paths in tsconfig.json for each library or project : precisely to avoid errors.

[cyrilluce]

@nathan-de-pachtere
For example, a/tsconfig.json ref b/tsconfig.json, and b ref a. loadTSConfig haven't handle these circular situation, will cause dead recurisive loop.

load(a)
  load(b)
    load(a)
      load(b)
        ...

I guess you are using folder path in your tsconfig reference, before my previous PR it will just get a empty config, and them ignore it.
Now reference with folder worked, that expose this bug.

Maybe I should make a pr to fix it

[nathan-de-pachtere]

@cyrilluce
We don't have cases of direct circular references between two packages as you describe. If it occurs, we split the code into three packages and reorganize it by creating a middle package that bridges what’s needed by both. This way, we generalize and keep our codebase clean and usable for new projects.

It would be amazing if you could create a PR for that.

[cyrilluce]

@nathan-de-pachtere Indirectly circular reference also dose, e.g. a -> b -> c -> a

[nathan-de-pachtere]

@cyrilluce Thanks for that quick PR