Native Markdown / MDX parsing and processing #1343
Replies: 4 comments 13 replies
-
|
This is currently being tried on our docs: withastro/docs#13625 where it lowers the build time by more than a minute. This can be tried in your projects right now by installing the following packages: Note that it is still quite early, and bugs may be present. |
Beta Was this translation helpful? Give feedback.
-
|
How will one opt to use Remark instead? How do you flip between the implementations? |
Beta Was this translation helpful? Give feedback.
-
|
@withastro/tsc would like to reach conclusion on this. Note that Stage 1 discussion does not require exact details regarding the code or API, as such the question of "how will remark users migrate to this" / "how will users opt into remark after this" does not need to be answered as part of this. It is part of the RFC that there will be a way to use remark for users that prefers it. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you all, this proposal has now reached stage 2. #1363 |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Body
Summary
Replace Astro's default Markdown / MDX pipeline with a more performant and lightweight alternative, improving the state of things for the vast majority of users, without losing access to remark / rehype for users that still needs it
Background & Motivation
Bigger Astro websites with a lot of Markdown / MDX files tend to be on the slower side wrt build time, for instance the Astro docs or the Cloudflare docs take multiple minutes to build. The bottleneck is not solely just the Markdown / MDX processing of course, but it's a fair amount of it.
For the past few weeks, I've been working on Sätteri: https://github.com/bruits/satteri, a native Markdown pipeline for the JS ecosystem. The goal is to create a LightningMarkdown to unified's PostCSS. Zero runtime dependencies, extremely fast, low memory usage, but without losing on the ability to use JS plugins, and when using said plugins, have as low of a cost as possible.
I suggest that it could become the default Markdown / MDX pipeline in Astro. Users that do depend on the remark ecosystem / don't / can't port their plugins could still use remark if they prefer, but it would be opt-in.
Goals
Example
For Astro users, there are no changes to behavior by default, all of Astro's current features are supported. The same options are supported, althought some properties might have different names now. (ex: it's no longer
remarkPlugins).Authoring plugins
Sätteri uses a subscription-based visitor pattern for plugins. Instead of walking the entire tree in JavaScript, plugins declare which node types they care about, and only those nodes cross the native boundary. The shape of every node matches remark's mdast and rehype's hast respectively, making it easy to port plugins over (by hand or by AI)
MDAST Plugin (remark equivalent)
Before (remark):
After (Sätteri):
HAST Plugin (rehype equivalent)
Before (rehype):
After (Sätteri):
The
filter: ["pre"]means Rust efficiently skips every element that isn't a<pre>, no JS callback fires for other elements in the document. This is similar to the filter property in Rolldown plugins.Beta Was this translation helpful? Give feedback.
All reactions