I thought we were past hand-writing markup for simple content blocks. Then Astro 3.0 shipped and stripped out the built-in Astro Markdown component altogether. If you build content-heavy sites, it felt like a step backward.
Why removing native Markdown was a mistake
Frameworks protect core stability by pushing features out to the community, and developers are the ones left bridging the gap. With no built-in Astro Markdown component, your choices are heavy MDX files for tiny snippets or raw HTML tags like <p>, <strong> and <ul> sitting inside your components. Either way it interrupts the flow of building modular UI that somebody else has to edit later.
If MDX already runs your main pages, my guide on Astro MDX Integration covers that side of it. Inline content needs something lighter.
The community component that fills the gap
The official package is deprecated, as the Astro v3 migration docs spell out, so I moved to the Splendid Labz solution. It does the two things I care about: less markup to write, and typographic symbols fixed without me thinking about them.
---
import { Markdown } from '@splendidlabz/astro'
---
<div class="card">
<Markdown>
## Card Title
This is a paragraph with **strong** and *italic* text.
- List Item 1
- List Item 2
</Markdown>
</div>Handling indentation and whitespace
Whitespace is where custom components usually go wrong. Naive implementations wrap everything in <pre> tags because they cannot work out the indentation depth. This one reads the leading whitespace and trims it, so the HTML you get out stays semantic.
The Prettier race condition
A war story for you: I once spent two hours working out why a client’s blog was rendering broken Markdown. Prettier was “helping” by re-indenting the contents of the component. The fix is a prettier-ignore comment, or passing the content in as a prop.
<!-- The Props Approach (Safest for Prettier) -->
<Markdown content={`
This is a paragraph.
Another paragraph that won't get messed up by formatters.
`} />If Astro and frontend architecture work is eating your dev hours, hand it over. I have been wrestling with WordPress and modern JS frameworks since the early days, and I know how to build systems that survive an update.
Where that leaves a v3 migration
A shift in a framework roadmap is not a reason to accept bloated markup. A third-party Astro Markdown component keeps your logic clean and your content readable as Markdown. If you are moving from v2 to v3, do this refactor early instead of paying for it later across your UI components.
