feat: add markdown processor abstraction#16848
Conversation
🦋 Changeset detectedLatest commit: 62f090e The changes in this PR will be included in the next version bump. This PR includes changesets to release 418 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
| try { | ||
| const decodedImagePath = JSON.parse(imagePath.replaceAll('"', '"')); | ||
| const decodedImagePath = JSON.parse( | ||
| imagePath.replace(/&(?:#x22|quot);/g, '"').replace(/&(?:#x27|apos);/g, "'"), |
There was a problem hiding this comment.
Remark (somewhat unusually) uses numerical entities instead of named ones, other Markdown processors are more likely to use named entities.
| * falls back to its built-in handling for the known `unified` processor name. | ||
| * Third-party processors should provide this to enable MDX support. | ||
| */ | ||
| createMdxRenderer?( |
There was a problem hiding this comment.
MDX code in core, looks weird, but it's more likely than you think. Ever since we added MDX Astro has had some sort of MDX-specific layer somewhere. At this point, I find it doubtful we'd ever be dropping MDX support and so I figured this was the best API
(and down the line I'd like for the first party processors to also use that API, but it's a bigger conversation of making MDX fully built-in, ha)
ArmandPhilippot
left a comment
There was a problem hiding this comment.
I left a few nits for the configuration reference, and I think the changeset should be a bit more verbose both to hype the feature and to show that Sätteri is also available! If we don't tell users Sätteri exists, they will not try it. 😅
…or<T> Replace `MarkdownProcessorEntry` + `UnifiedProcessorDescriptor` with a single generic `MarkdownProcessor<TOptions>` interface, and rename the renderer to `MarkdownRenderer` so the two concepts have separate nouns. Move the MDX renderer types (`MdxRenderer`, `MdxRendererOptions`, `MdxRenderResult`) into `@astrojs/internal-helpers/markdown` so they can be referenced by processor packages without astro re-entering the dep graph. Also relaxes the over-narrow `AstroMetadata` shape (`scripts: never[]`, `propagation: 'none'`, …) so the unified MDX pipeline's compiler-produced metadata fits the same type the satteri pipeline produces.
Co-authored-by: Armand Philippot <git@armand.philippot.eu>
Co-authored-by: Armand Philippot <git@armand.philippot.eu>
Co-authored-by: Armand Philippot <git@armand.philippot.eu>
Co-authored-by: Erika <3019731+Princesseuh@users.noreply.github.com>
Co-authored-by: Armand Philippot <git@armand.philippot.eu>
|
| 📦 Package | 📏 Size |
|---|---|
| @napi-rs/wasm-runtime@1.1.4 | 6.3 MB |
| @bruits/satteri-linux-x64-gnu@0.6.3 | 3.1 MB |
| @emnapi/core@1.9.1 | 1.9 MB |
| @emnapi/runtime@1.9.1 | 424.1 kB |
| @emnapi/wasi-threads@1.2.0 | 227.6 kB |
| satteri@0.6.3 | 218.5 kB |
Total size change: 12.1 MB
Changes
The
markdown.processorpart of withastro/roadmap#1364, please see the RFC for details.Testing
Updated tests that relied on specific remark plugins and what not. Added tests using a custom processor to make sure it works from e2e
Docs
withastro/docs#13919