fix(ssr): possible infinite recursion in SSR exports

[space-nuko]

Description

I have a project that imports several packages from a monorepo with linked workspaces, they all depend internally on each other. Then I started getting errors like these when importing a module inside one of the libraries (depended on by the main app, and itself depends on another of the monorepo's packages)

3:20:31 AM [vite] Error when evaluating SSR module /litegraph/packages/nodes-basic/src/ConstantNumber.ts:
3:20:31 AM [vite] Error when evaluating SSR module /litegraph/packages/nodes-basic/src/index.ts:
3:20:31 AM [vite] Error when evaluating SSR module /src/lib/components/ComfyApp.ts:
3:20:31 AM [vite] Error when evaluating SSR module /src/lib/components/ComfyUIPane.svelte:
3:20:31 AM [vite] Error when evaluating SSR module /src/lib/components/ComfyApp.svelte:
3:20:31 AM [vite] Error when evaluating SSR module /src/routes/+page.svelte:

Internal server error: Maximum call stack size exceeded
      at Module.get [as LGraphNode] (file:///E:/build/ComfyUI/web2/node_modules/.pnpm/vite@4.2.1/node_modules/vite/dist/node/chunks/dep-79892de8.js:53991:25)
      at Module.get [as LGraphNode] (file:///E:/build/ComfyUI/web2/node_modules/.pnpm/vite@4.2.1/node_modules/vite/dist/node/chunks/dep-79892de8.js:53991:44)
      at Module.get [as LGraphNode] (file:///E:/build/ComfyUI/web2/node_modules/.pnpm/vite@4.2.1/node_modules/vite/dist/node/chunks/dep-79892de8.js:53991:44)
<...>

I was stumped as to how to reproduce this issue minimally, but it seems like the error is that sourceModule and ssrModule can overlap inside the ssrExportAll function, such that the generated Module.get properties point at each other cyclically. After I made the change in this PR the problem went away

Additional context

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines and follow the PR Title Convention.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

[stackblitz]

Run & review this pull request in StackBlitz Codeflow.

[bluwy]

I think this should be fixed by #12530. Can you try the Vite beta if it works?

What that PR changed is that re-exports are transformed to be hoisted to the top, so there wouldn't be any conflict with the ssrModule. If the ssrModule has the same named export, it'll override the re-export's. (same as nodejs behaviour)

---

Separate issue:

What this PR might affect though is that if they are two re-exports of the same named export name, since both can be hoisted to the top. Stackblitz example.

Running the stackblitz example shows that the first re-exports value wins, but running locally it shows that node bails and remove the named export altogether. I think this is indeed a bug we could fix separately.

[space-nuko]

Latest vite did not fix the issue (4.3.1)

[bluwy]

Given the "separate issue" noted above, I'm still not sure if this is the right fix. It would be good to have a repro or tests to show your issue too.

[space-nuko]

The problem is I don't actually understand what the issue is, all I know is my project was completely broken until I applied the patch internally to vite, so there wasn't another way forward for me.

The project repro in question is this, installed with pnpm

https://github.com/space-nuko/ComfyBox