feat(gatsby,gatsby-cli): Slice HTML rendering error handling #36822
Conversation
tyhopp
added
the
topic: core
gatsbot
bot
added
the
status: triage needed
tyhopp
removed
the
status: triage needed
| `Slice props: ${JSON.stringify(context?.sliceProps || {}, null, 2)}`, | ||
| ] | ||
| .filter(Boolean) | ||
| .join(`\n\n`), |
There was a problem hiding this comment.
Did this instead of stripIndents because stripIndents destroys the format of the stringified JSON
| `"${context.ref}" is not available during Server-Side Rendering. Enable "DEV_SSR" to debug this during "gatsby develop".`, | ||
| `"${context.undefinedGlobal}" is not available during server-side rendering. Enable "DEV_SSR" to debug this during "gatsby develop".`, |
There was a problem hiding this comment.
just heads up on changes like that:
We have error map in gatsby-cli, and gatsby core has that as dependency with ^ selector, which means that older gatsby versions (ones that would create errors with .ref context variable) if they don't have lock file or package manager decide to update gatsby-cli - there might be "incompatibility" between those.
In our case it's not critical because we are in @next / beta phase, so at most previously released alpha/beta versions would be impacted, but change like that is not safe in general.
We should either keep the context variables named as they were (and be annoyed that the name is non-descriptive) or we rename, but the error renderer should be able to fallback to previous name of variable - i.e. "${context.undefinedGlobal ?? context.ref}" ...
Description
Handle slice HTML rendering errors.
Documentation
N/A
Related Issues
[sc-56605]