Skip to content

Native Markdown / MDX parsing and processing #1363

@Princesseuh

Description

@Princesseuh

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 need it.

Background & Motivation

Bigger Astro websites with a lot of Markdown / MDX files tend to take a long time to build, for instance the Astro docs or the Cloudflare docs take multiple minutes. The bottleneck is not solely the Markdown / MDX processing of course, but it's a fair amount of it.

Remark and the greater unified ecosystem are great, however:

  • Remark is unfortunately on the slower side of things
  • The unified ecosystem pulls in 100+ dependencies in Astro

For the past few months, I've been working on Sätteri, a native Markdown pipeline for the JS ecosystem. The goal is to be a LightningMarkdown to unified's PostCSS: zero runtime dependencies, extremely fast, low memory usage, but without losing the ability to use JS plugins, and when using said plugins, have as low of a cost as possible (subscription-based plugins, where a plugin declares which node types it cares about and skips the rest).

It also includes built-in support for features that people previously used remark / rehype plugins for, such as directives or smart punctuations, which will hopefully reduce the need for plugins to exist for a consequential percentage of users in the first place.

I suggest it becomes the default Markdown / MDX pipeline in Astro. Users that do depend on the remark ecosystem, or don't / can't port their plugins, can still use remark if they prefer, but it becomes opt-in via a new config that would work similarly to how image services work right now in Astro.

Goals

  • Cut Markdown and MDX build times on content-heavy sites like the Astro docs or Cloudflare docs
  • Drop the remark / rehype stack from the default install, reducing Astro's dependencies by 100~
  • Keep a supported path for projects that depend on remark or rehype plugins.
  • Make the Markdown engine an extension point. Third-party processors (not only Sätteri and unified) should be able to plug in, similar to image services.
  • Don't break existing sites: projects without any remark / rehype plugins should see no difference in rendered output after upgrading.

Non-Goals

  • Native syntax highlighting; we'll keep using Shiki.
  • Mixing multiple Markdown processors in the same project.
  • Prism support under the new pipeline, at least at first.
  • Built-in support for MDX or any other formats

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    Status
    Stage 2: Accepted Proposals, No RFC

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions