📎 markdown support

Description

We need a specification/roadmap to enable contributors to come and contribute correctly.

Parser :

For the parser I don't think we need to reinvent the wheel, we can use wooorm/markdown-rs

Formating :

We should follow common mark spec to format correctly

@AugustinMauroy

@AugustinMauroy what's this task for? I don't really understand. Can you please put more description or context into the issue?

Unless you really want to work on integrating markdown in Biome, we don't usually create tasks unless someone is already interested or working on it.

Unless you really want to work on integrating markdown in Biome, we don't usually create tasks unless someone is already interested or working on it.

I'd like to try, but I'm no expert on rust, so that's why I'm asking for the spec/roadmap of markdown support.

We have a contribution guide that should give you the necessary information to start adding a parser inside Biome: https://github.com/biomejs/biome/blob/main/crates/biome_parser/CONTRIBUTING.md

Regarding the parsing, I believe we could use that crate, however we still need to map their AST to our CST because we need to own the grammar, and the internal APIs.

We've never done this before because all our parsers are built from scratch, so it's something you should explore alone.

use prettier until biome has markdown support

Recently I was digging into biome's architecture and thought I could support this

I think that in order to support markdown effectively, we will need to have #3334 for formatting code blocks, but I don't think that's necessarily a hard blocker. We could start with a naive parser and formatter that doesn't format code blocks. PRs are welcome, but I expect markdown support will have the same priority as yaml support.

hello ! i'm not an expert in rust etc ... But what's the next step for markdown support ?

The lexer and parser is still incomplete. You could take a look in biome_markdown_parser and see what needs doing.

Will the Biome markdown parser also parse any HTML within a markdown file?

That's the plan, but that depends on #3334

Is MDX included in the scope? Or would that be a completely separate topic?

Complete separate topic. MDX isn't a markup language, but a programming language which has its own quirks and rules that are different from markdown

@jfmcdowell

Hi @jfmcdowell . Given #8525 was merged (thanks!), do you have an idea what's left to claim markdown is supported?

I was thinking of implementing the parser but you beat me to it 😄 Let us know if you have further plans so that I don't step on your work.

(I'm subscribing to the issue meanwhile to be in the loop).

This might be a different issue entirely, but will we be able to associate other extensions with a markdown formatter? A static site generator uses .mdx for source material and, for the most part, they should be treated like regular markdown files.

IMHO full MDX support requires a dedicated MDX-aware parser (and corresponding formatter integration), not just Markdown parsing. It should be its own issue.

Add .editorconfig and update biome

@heaths

@heaths the answer to your question was already in the thread

#3718 (comment)

Sorry - I missed there was a collapsed section when I Cmd+F'd for "mdx". I appreciate it's not strictly markdown, but we really only want the formatting anyway. Perhaps #4754 would help, but only for formatting. I'll comment about that there.

@ematipico

@ematipico / @Netail is it worth opening an umbrella issue for tracking progress and discussion on markdown linting?

Mhm I don't think we really did for others (only tickets for a single rule, but that was more on request basis)

For a new language support ticket (like this one) we do usually have "adding at least 1 linting rule" in the checklist before the ticket can be marked as done

Sure, a new umbrella issue for lint rules would make sense. It would give us a space to determine what is/isn't in scope.

Hey, maybe one could also consider bruits/satteri for the markdown processor? It supports MDAST and HAST plugins and could very organically replace and expand upon the respective Remark and Rehype plugins of the unified markdown processor for formatting and linting, for instance, by substituting remarkjs/remark-lint. The added benefit might be that Satteri could be used as a standard processor, for example, within Astro, and formatting and linting would be performed with the same framework used to compile the webpages, which is useful for extensions that add new syntax, such as MDX or GFM.

For Markdown linting, you also might want to consider rumdl which is a superset of markdownlint, implemented in Rust, and ultra-fast.

we can use wooorm/markdown-rs

Hey, maybe one could also consider bruits/satteri for the markdown processor?

They don't support the CST output, which Biome requires.

Biome currently doesn't support any GFM syntax including tables.

However, using Prettier's unconditional column alignment across all lines creates several issues:

Including extremely long strings in some cells creates excessive whitespace in other rows.
CJK characters' width isn't always exactly twice that of Latin characters (when a CJK font and a Latin monospace font are combined), resulting in alignment issues in CJK languages. This problem may extend to other Asian scripts as well.
Modifying content in one row often propagates changes to other rows, increasing VCS changes and making conflicts more likely.

Navigation Menu

Repository navigation

📎 markdown support #3718

Description

Parser :

Formating :

22 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

📎 markdown support #3718

Description

Description

Parser :

Formating :

Activity

ematipico commented on Aug 28, 2024

AugustinMauroy commented on Aug 28, 2024

ematipico commented on Aug 28, 2024

xin2017338 commented on Sep 4, 2024

dyc3 commented on Sep 4, 2024

AugustinMauroy commented on Nov 4, 2024

dyc3 commented on Nov 4, 2024

trymeouteh commented on Jun 16, 2025

dyc3 commented on Jun 16, 2025

XiNiHa commented on Jun 17, 2025

ematipico commented on Jun 17, 2025

tidefield commented on Jan 27, 2026

22 remaining items

jfmcdowell commented on Feb 22, 2026

ematipico commented on Feb 22, 2026

heaths commented on Feb 24, 2026

jfmcdowell commented on May 6, 2026

Netail commented on May 6, 2026

dyc3 commented on May 6, 2026

igor-koop commented on Jul 3, 2026

guillp commented on Aug 3, 2026

tats-u commented on Aug 23, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions