Poor stack traces in SSR

[Josh-Cena]

Have you read the Contributing Guidelines on issues?

• [X] I have read the Contributing Guidelines on issues.

Motivation

Our SSR errors are undebuggable. For example, https://github.com/facebook/docusaurus/issues/7398, https://github.com/facebook/docusaurus/issues/4268.

If a piece of code accesses window, all we know is which path is currently being rendered, but if this code is a client module, then it throws on every single path. Beyond that, when you look into the stack, it, at most, shows something like

Hook useTabGroupChoice is called outside the <TabGroupChoiceProvider>.
ReactContextError
    at useTabGroupChoice (main:38645:1282)
    at ResponseCodeTabs (main:56136:584)
    at d (main:118177:498)
    at bb (main:118180:16)
    at a.b.render (main:118186:43)
    at a.b.read (main:118185:83)
    at Object.exports.renderToString (main:118196:138)
    at doRender (main:29440:417)
    at async serverEntry_render (main:29437:290)

Which isn't really telling us anything.

I don't really know what we need to do specifically to fix this: do we use source maps? Do we do SSR in development mode so that React can give us the component stack? Or do we simply wrap some imports in try/catch (I'm thinking specifically about the client modules)?

Self-service

• [ ] I'd be willing to do some initial work on this proposal myself.

[slorber]

yes, this is also annoying me a lot, not sure what's the best solution to have better SSR stack traces

Using try/catch, does it mean we have to emit those directly inside .docusaurus/clientModules.js or do you have any other idea in mind?

[Josh-Cena]

Yes, that's what I have in mind.

[wenerme]

ReactContextError, maybe something wrong with react-live(but works at https://docusaurus.io/docs/markdown-features/code-blocks#interactive-code-editor) , have no idea why.

https://github.com/wenerme/wener/actions/runs/3322949327/jobs/5492675080#step:8:295