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