Fix MDX integration error message not being compatible with docs (#5767)

* fix(errors): Fix MDX Integration missing error message so docs generation work properly

* docs(errors): Add more information regarding authoring error messages
This commit is contained in:
Erika 2023-01-05 16:46:30 +01:00 committed by GitHub
parent 17608762e1
commit f1da0da29f
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
3 changed files with 16 additions and 8 deletions

View file

@ -5,7 +5,7 @@
## Writing error messages for Astro
### Tips
**Error Format**
Name (key of the object definition):
@ -56,6 +56,17 @@ If you are unsure about which error code to choose, ask [Erika](https://github.c
- **Error codes and names are permanent**, and should never be changed, nor deleted. Users should always be able to find an error by searching, and this ensures a matching result. When an error is no longer relevant, it should be deprecated, not removed.
- Contextual information may be used to enhance the message or the hint. However, the code that caused the error or the position of the error should not be included in the message as they will already be shown as part of the error.
- Do not prefix `title`, `message` and `hint` with descriptive words such as "Error:" or "Hint:" as it may lead to duplicated labels in the UI / CLI.
- Dynamic error messages must use the following shape:
```js
message: (arguments) => `text ${substitute}`
```
Please avoid including too much logic inside the errors if you can. The last thing you want is for a bug to happen inside what's already an error!
If the different arguments needs processing before being shown (ex: `toString`, `JSON.stringify`), the processing should happen where the error is thrown and not inside the message itself.
Using light logic to add / remove different parts of the message is okay, however make sure to include a `@message` tag in the JSDoc comment for the auto-generated documentation. See below for more information.
### Documentation support through JSDoc
@ -89,7 +100,7 @@ The `@message` property is intended to provide slightly more context when it is
Error are a reactive strategy. They are the last line of defense against a mistake.
While adding a new error message, ask yourself, "Was there a way this situation could've been avoided in the first place?" (docs, editor tooling etc).
While adding a new error message, ask yourself, "Was there a way this situation could've been avoided in the first place?" (docs, editor tooling etc).
**If you can prevent the error, you don't need an error message!**

View file

@ -70,7 +70,7 @@ export function enhanceViteSSRError({
) {
safeError = new AstroError({
...AstroErrorData.MdxIntegrationMissingError,
message: AstroErrorData.MdxIntegrationMissingError.message(fileId),
message: AstroErrorData.MdxIntegrationMissingError.message(JSON.stringify(fileId)),
location: safeError.loc,
stack: safeError.stack,
}) as ErrorWithMetadata;

View file

@ -544,11 +544,8 @@ See https://docs.astro.build/en/guides/server-side-rendering/ for more informati
MdxIntegrationMissingError: {
title: 'MDX integration missing.',
code: 6004,
message: (id: string) => {
return `Unable to render ${JSON.stringify(
id
)}. Ensure that the \`@astrojs/mdx\` integration is installed.`;
},
message: (file: string) =>
`Unable to render ${file}. Ensure that the \`@astrojs/mdx\` integration is installed.`,
hint: 'See the MDX integration docs for installation and usage instructions: https://docs.astro.build/en/guides/integrations-guide/mdx/',
},
// Config Errors - 7xxx