Call stack errors when Astro component props are changed repeatedly in MDX files

[brycewray]

What version of astro are you using?

1.1.1

Are you using an SSR adapter? If so, which one?

None

What package manager are you using?

npm

What operating system are you using?

macOS 12.5.1

Describe the Bug

Repeatedly editing the props supplied to an Astro (.astro) component imported into an MDX file causes a “maximum call stack size exceeded” error, often regarding String.replace. For example:

RangeError: Maximum call stack size exceeded
    at String.replace (<anonymous>)

Although I first thought it was because I was accessing a Twitter API in some erroneous manner, @jasikpark helped me see that, even with the component reduced to only returning results from Math.random() (and, thus, the props are meaningless), the problem persists.

Note that I cannot reproduce the example on Stackblitz, so instead I will link to my own repo with a sample component and file...
Test component = https://github.com/brycewray/astro-site/blob/main/src/components/STweet.astro
Test MDX file = https://github.com/brycewray/astro-site/blob/main/src/pages/posts/2022/08/tweet-test.mdx

Link to Minimal Reproducible Example

[See above for info]

Participation

• I am willing to submit a pull request for this issue.

[jasikpark]

I'll test out https://stackblitz.com/github/brycewray/astro-site/

[jasikpark]

Not able to see a reproduction of the bug in https://stackblitz.com/github/brycewray/astro-site/?file=README.md

[jasikpark]

Seeing if https://codesandbox.io/s/github/brycewray/astro-site is different

[jasikpark]

repro screenshot:

open the tweet-test.mdx post and trigger HMR at least 9-10 times by editing the STweet props and saving until you see the String.replace or module resolve stack overflow

[brycewray]

This appears to be because, in a Post.astro layout, I was using await Astro.glob() to provide “previous page”/“next page” data to each post. With that glob reference removed from the layout, this issue doesn’t occur. This therefore doesn’t appear to be, legitimately, an Astro issue, so I am closing it.

At the suggestion of @jasikpark, this is now in the hands of the Vite Discord:
https://discord.com/channels/804011606160703521/814182556068085760/1013812534819692656

[jasikpark]

well, it's still a direct astro feature, right? so it deserves issues for both projects 🤷

[brycewray]

Thought about what @jasikpark said above and decided he was right. Whether this is an edge case or something broader, it probably does need somebody to look at it when time allows.

[jasikpark]

Is there a vite repo issue to track w/ it?

[brycewray]

@jasikpark No. Actually didn’t think about that, especially after it never got any traction in the Vite Discord.

Edit: Wonder if this is related at all to vitejs/vite#9713 ...?

[jasikpark]

This could be Astro specific as well, since the ability to import MD / MDX is an Astro-built Vite plugin, right?

[brycewray]

This could be Astro specific as well, since the ability to import MD / MDX is an Astro-built Vite plugin, right?

Hope so. I’d be more optimistic about a fix in that case, although I gather at this point mine is an edge case since I don’t see reports of others having similar issues with Astro.glob() and the like.

[RobertAKARobin]

Possibly related: #4894

[brycewray]

Possibly related: #4894

@RobertAKARobin Interesting and somewhat similar, although different from my issue since this happened for me without any other errors appearing prior to the call stack error.

[RobertAKARobin]

No other errors occur for me either.

[bluwy]

Looks like https://github.com/brycewray/astro-site/blob/main/src/pages/posts/2022/08/tweet-test.mdx is missing and the repo is archived now, but I'm hitting a different issue with the repo that I'm getting JS heap errors on startup.

I generated a 1GB heap snapshot, but Chrome isn't loading it after 10mins. Marking this as blocked for now.

Is there a smaller repro too?

[bluwy]

Ah alright I figured out where the cause is thanks to this screenshot. It's because of Vite hooking into Node's internal resolve, and it running in parallel causes the hook to be recursive. There was also prior discussion with a solution at https://discord.com/channels/804011606160703521/930868117234647092/930868121118584913. Making a fix on Vite's side.

[brycewray]

Looks like https://github.com/brycewray/astro-site/blob/main/src/pages/posts/2022/08/tweet-test.mdx is missing and the repo is archived now, but I'm hitting a different issue with the repo that I'm getting JS heap errors on startup.

I generated a 1GB heap snapshot, but Chrome isn't loading it after 10mins. Marking this as blocked for now.

Is there a smaller repro too?

@bluwy I can both un-archive the repo and restore the missing file if that would help. Let me know.

[bluwy]

No problem, I've made a fix at vitejs/vite#10401 👍

[brycewray]

No problem, I've made a fix at vitejs/vite#10401 👍

@bluwy Outstanding! Thank you. 👏 👏 👏 👏 🎉 🎉 🎉 🎉

@jasikpark Realistically speaking: once this fix goes through on Vite’s site, how long would it take before this is reflected in Astro? Is there coding on that project’s side which will be necessary to implement a Vite-side fix like this? (I’ll also be curious as to whether this might fix the slow-as-molasses experience I’ve had with editing MDX files, since they all were wrapped in layouts using Astro.glob().)

[bluwy]

@brycewray the Vite fix will be going into Vite 3.2 which will take a week or so before reaching stable, which Astro would then bump the version to support it. Once the fix is published in [email protected] you can also start using it with npm overrides. There shouldn't be any change needed in Astro.

[brycewray]

@bluwy Thanks for that info, and thanks again for the fix!

cc: @jasikpark