André Torgal: #content-management Feed

MDX authoring experience in Astro / Shortcomings

2023-01-26T00:00:00Z

Since I am migrating this site to Astro - which I am convinced is the best SSG out there right now - I was expecting to have the same advanced MDX authoring experience as in my previous website. Better even, maybe the challenges I was not able to solve before were meanwhile solved by the awesome folks out there.

But I know well, there will be 🐉 🐉 🐉 dragons!

⚠️ You are looking at an outdated post.

I meanwhile upgraded Astro from 1.9 to 5. Some of the limitations are gone. You can now store images anywhere you like, including side by side with the content 🥳.

As I wrote before, I have a long list of requirements for the experience I want to have when authoring and managing content on my website.

Most of these features were working quite well in the previous version of this website. And they weren't that hard to accomplish! I rolled my own remark, rehype pipeline, so I was free to make any choices I pleased about where the files should live, frontmatter manipulations, image optimisations, the works.

Computer says no

Unfortunately, Astro built-in features are not that flexible. 😓 On the contrary, they are by design very opinionated about some things.

Relevant to my interests is the strong preference of @astrojs/image to have all media stored in the public/ folder. And the pages? Well those, go in src/pages 😢.

Like 5 of my requirements became a bit more difficult in one go... Oh my! this is going to be a wild ride through a few rabbit 🐰 🕳️ holes.

Can't believe I actually contemplated using ugly ../../public/... paths for a bit. Then I tried writing a simple remark plugin. Nah, things started breaking 😱 ... Whatever I tried, I was either breaking the dev server or the static build.

What about Astro collections? It would allow me to cleanup the frontmatter and not repeat layout: ... everywhere. But could I have two items of different collections in the same folder? Oh noooooo! 😲 Astro's MD/X features are again "file system first":

A content collection is any directory inside the reserved src/content ...

After tinkering with all possible configuration options, searching in hundreds of Astro built websites, and reading through some disappointing conversations in Github issues ... 😫 ... I decided to use less built-in features and search for community plugins instead.

Third-party package: `astro-m2dx`

Honestly, Astro's community is big and growing, but the only thing out there that stood out was the astro-m2dx project which immediately resonated, a lot, with what I was looking for:

• Define default frontmatter properties for all files in a directory, e.g. the layout

• Map HTML elements to JSX components on a per-directory basis

• Auto-import known JSX components on a per-directory basis

• Scan the document for Title or Abstract

Unfortunately, the image implementation depends on using import - as suggested by the Astros's documentation.

But if the reference to the image is no longer a string with a resolvable path/to/image.jpg then I can't reuse it easily - or can't use it at all - in other places such as the og:image tag, or in good old thumbnails in lists.

I still considered dealing with that later, and focus on the other astro-m2dx features. But the first time I deployed it, the auto imports feature was simply not working.

In conclusion, astro-m2dx has some really cool features, some very smart tricks inside, and depends on some super useful utils published independently as the m2dx-utils package.

But the author is focused on other (much more important) things right now, and won't be able to help me with the really strange and opaque ❌ CI issue that I ran into.

Conclusion

Time to take this into my own hands ✊ and have a go at putting together an "integration", using bits and pieces from all the things I saw in the last 2 weeks, and deliver that superior MDX authoring experience with Astro.

Advanced MDX authoring experience / Requirements

2023-01-25T00:00:00Z

Once I got my new website's information architecture up and running, and migrated most of the old content, I want to make the authoring experience as awesome as possible. 🤩 At least as good as it was on my previous sites.

Backstory

I don't publish that much on the web these days. Not compared to the old times. But I have a long story, and a quite personal relationship, with content management.

Between early 2000s and 2008 I had a "tireless", and experimental presence on the web, some times running on my own code, some times running on things like Wordpress. some times a combination of both.

During my career so far, I also created from scratch several bespoke CMSs. And in the past few years, I am using MDX daily, building documentation for component libraries and design systems.

So, when it comes to migrating my site to a new framework, and looking at what features are available out of the box - and which ones I will have to rollout myself - I have a huge shopping list, a big appetite to invest, and I am going all in.

Shopping list

Seamless preview as I type.
Along with auto-complete for links and images.
Sensible defaults for page metadata.
Extract title, description, og:image, and more from the content.
Decorate external links.
Automatically import "react" components referenced in the MDX content.

For images alone, I will settle with nothing short of:

Optimise images for responsive sizes.
Using both modern and fallback formats.
Semantic <figure><picture><img><figcaption> pattern.
With easy way to show a caption and an attribution link.
Generate as little as possible in dev mode to speed up preview experience.
And minimised CLS by reserving vertical space for all images.

Here's a more detailed look at some of these items, why they are so important to me, and how they combine to provide an awesome 🤩 experience.

Seamless preview

Number one item: keeping the markdown source code as natural as possible.

I want to type all the links as absolute paths from the root of the site /posts/1998-03/post.mdx, including the .mdx extension and allow VSCode to navigate from link to link on the MDX preview just as it does with your good old README.md 😉.

Also, keeping the image tags relative to the file that I am editing allows VSCode to just preview them as I type. And yes! 👇 I want the images right next to this file.

Auto complete

The above strategy for links and images also provides the indispensable auto complete. When I am typing links or image paths in MDX files, I just want it to drop down and help me out!

The same goes for links.

Most pages of this website exist in the filesystem, so it would be a shame to mess with VSCode's ability to auto-complete as I type.

Image optimisations

I want my SSG to detect all images and extract, beyond the alt and title, also an attribution text and a link.

![alt](./file.jpg 'Title // Attribution http://source...')

I also want it to render responsive images, with different resolutions for different screen sizes. And generate modern avif files as well as a legacy fallback formats. If you're curious, I wrote about why avif instead of webp.

<picture>
  <source
    type="image/avif"
    srcset="image-700px.avif 700w, image-1400px.avif 1400w"
    sizes="(max-width: 650px) 86vw, (max-width: 1200px) 650px, 1400px"
  />
  <img src="image-700.avif" alt="Photo of ..." loading="lazy" decoding="async" />
</picture>

Finally, I want dev mode to use as little resources as possible to speed up the dev experience. It should only generate images for the page I am previewing, generating on demand whatever is requested by the browser, and should use something like 50% quality jpg only.

On the other hand, in static build time, it should optimise for production, using settings for better quality, and generate all the formats for all the files.

Auto detection of metadata

This is a no-brainer. I don't want to type things in frontmatter if they can be authored in - and then extracted from - the document.

---
title: Improving the (MDX) authoring experience in Astro
description: 'Once I got .... dragons'
ogImage: ./_media/dragons.jpg
published: 2023 Jan 26
---

I want to have the full markdown experience. I want my "abstract" to have links, italics, and emojis 🍺 damn it! And I want to render it wherever I want in this page, on another page that lists posts. And I want it to be markdown everywhere. Again: links, italics, emojis.

But at the same time I also want to render <meta name="description"> and og:description tags. Of course, in this case, I want to strip out all the funny stuff from the original content.

<Abstract>

Once I got my new website's [information architecture](/meta/docs/information-architecture) up and
running, and migrated most of the old content, I wanted to make the authoring experience as
awesome as possible. :star-struck: But I should know ... There might be dragons :dragon: :dragon:
:dragon:

</Abstract>

Finally, og:image should default to the first image, unless specified otherwise in the metadata. And the <h1>H1 Title</h1>, also rendered as og:title and <title>title</title> should, by this logic, be the

# Title

There are 2 principles at work here:

DRY: don't repeat yourself!
The document is the source of truth, the metadata just just be a crutch.

Frontmatter defaults per type of content

It's a pain to have to type in all my blog posts that they are type: post or that they use layout: ~/templates/BlogPost.astro. 🤢 Lame, time waster, error prone.

I want all blog posts to be type:post and tags to be type:tag (maybe more in the future 😉) and I want the generator to provide defaults for the repetitive stuff.

External links

Show an arrow 👈 decoration on external links must to help users know if they're leaving my site... Oh no! don't leave! Come back!

Also, all external links must carry the rel="noopener" attribute for security and performance reasons.

Auto-imports

I also don't want to have to import components that I use often in my pages. I want to be focused on the content and have <Hero>, <Abstract>, <Video>, that type of stuff, always in scope.

Why stop here?

The moment I have all of these features working, I will want more for sure!!! I will want VSCode to preview my 🍺 and auto complete my emojis as well... 🥺 pretty please?

I might have to dig into VSCode extensions as well.

There's also plenty of content related challenges in my website's backlog such as a link roll worthy of the 20s. We're in the future, I want to embrace it. 🚀

Meanwhile

I still have to make all of the above happen first. Out of the box, Astro provides none of it.

This narrative continues with a look at Astro's built-in features and their opinionated patterns and limitations, along with an evaluation of the existing community driven projects.

Will I be able to build it?

🥁 🥁 🥁

My website: Information architecture

2023-01-20T00:00:00Z

abstract

Unified.js is going to be around for a long time

2023-01-14T00:00:00Z

This library is now powering ESLint, prettier, this website, ... and pretty much anything using MD(X). Which is a lot and is only going to grow in the future. I say: it's here to stay! ✊ And coming for your fridge.

Context

I stumbled upon this project some 4 years ago. I believe because Storybook, then Gatsby were already using it.

What is it?

From their beautiful site:

We compile content to syntax trees and syntax trees to content.

An example of this is reading a Markdown file into a JS variable that you can modify and then output as HTML.

We also provide hundreds of packages to work on the trees in between.

Yes, hundreds of little transformations, such as add target and rel attributes to all external links, or more complex ones, such as generate a table of contents..

You can use them analyse the content, for instance for linting purposes. Strip content, re-arrange, re-format it.

You can build on the unified collective to make all kinds of interesting things.

How do you use it?

You create a pipeline, by composing a series of simple functions, and you can then you can use it to parse, transform, and render as many inputs as you want.

The markdownToHtml() function, accepts a markdown string and renders it to HTML.

import html from 'rehype-stringify';
import markdown from 'remark-parse';
import remark2rehype from 'remark-rehype';
import unified from 'unified';

cosnt processor = unified()
  .use(markdown)
  .use(remark2rehype)
  .use(html);

async function markdownToHtml(input) {
  return process.processString(input).toString();
}

Notice that the async function. The pipelines are asynchronous and always return a promise.

An example using community plugins

Since this website is built with Astro, and because Astro uses the Unified.js ecosystem for all things Markdown and MDX, I added remark-emoji to the configuration.

And the build now replaces :muscle: by 💪!

Or even better, by adding remark-a11y-emoji, it replaces :muscle: by

<span role="img" aria-label="flexed biceps">💪</span>

To plug these two transformations to the above example, all you have to do is:

import a11yEmoji from '@fec/remark-a11y-emoji';
import emoji from 'remark-emoji';

cosnt processor = remark() // <-- you can also start with remark
  .use(remarkEmoji) // <-- transform :beer: to emoji
  .use(remarkA11yEmoji) // <--  transform to `<span...>`
  .use(remark2rehype)
  .use(html);

The kudos 💯

The clever functional design, the rigor in principles, and patterns. 🤩

You could tell, even 4 years ago, that this was going to be around for a while.

Not only that, the super professional management of the project(s) and community, has been allowing it to grow this fast and conquer such an important space in the industry.

I also have the feeling that this project, that claims to be ...

a collective

... has a certain human substance, strong ethical vibes, a certain ❤️ I am not really sure, but you know what I mean.

The unified collective is a federated system of organizations, consisting in turn of projects, governed by the team members steering them.

Titus

The biggest kudos to Titus who I believe is the origin of all this.

Their website now reads:

I work most-time on open source maintaining 550+ projects that are downloaded 22B+ times a year.

Are you mind blown 🤯, yet?

At the moment, Prettier, ESLint, MDX, and probably millions of websites and services out there - arguably ALL modern documentation websites - contain some Unified.js code.

How I use Unified.js

Before discovering Unified.js I used many libraries to parse (and generate) Markdown documents. I remember marked but in an even older version of this website I found markdown-js (now 13 years old 😂 and unmaintained).

Since discovering the Unified.js ecosystem of highly pluggable micro libraries, I never used anything else. I reach for it all the time now, especially at work, usually to patch up deficiencies in tools such as Webpack or Rollup.js.

Fix builds, automate boring tasks, lint code, prevent errors, ...

Quite a 🔨 tool to carry in your tool belt.

Show me some code!

Sure! I used it extensively to build this website. So you'll find some examples of manipulation in this part of the repository.

I created the remark/ plugins to manipulate the markdown tree:

autoAbstract() extracts abstract from the document and stores in a metadata object.
autoImages() replace image relative paths with absolute ones and.
customComponents() makes sure that instead of rendering <img> tags we render a custom component.
and autoImports() injects import statements in the MDX context so that I don't have to manually import commonly used components.

The rehype/ plugins manipulate the HTML, also in abstract tree format, just before it is rendered. I only needed one - externalLinks() - to add rel="noopener" to all the external links.

If you wanna follow the narrative, check out the origin story or jump straight to my efforts to provide an advanced MDX authoring experience with Astro.

Saying goodbye to my React Static website

2023-01-12T00:00:00Z

I am relaunching my website with Astro. Writing down a word or two about the previous version, React Static, and the original "MDX" experience.

Backstory

My previous version of this website, back from 2019, was built with a static site generator (SSG). This was the first requirement for me in 2019 when selecting the language and framework to bring my site back to life.

React Static is now in maintenance mode and I need to replace it with something more modern.

Maybe you want to skip ahead, and read about how I am building it again with Astro.

Or stay, and walk with me as I revisit the decisions records of 2019, and ask:

what still stands?
what goes away?
what else is needed?

SSG! Of course

SSG has been around since the early days and I believe it's the best tool for many types of websites, definitely for content first use cases, such as search engine optimised content, media distribution, documentation, personal websites, ... many more.

👍 I was obviously going to stick to SSG in 2019 and there is no reason to change this now.

React Static was good, at the time

Even if I entertained the idea, and played around with some classics like Hugo and Jekyll, Typescript will always be home to me. And a personal website should feel like home.

Between the modern options, React Static seemed to be one of the simple ones, inline with Eleventy, and as opposed to Gatsby, an eventual serious contender, that I found about to be a bit too complicated and rigid for my liking.

On the other hand, React Static was less opinionated about how content should be structured, modeled, stored, loaded, or represented. And while it was simpler, it still allowed me to customise pretty much everything I ever thought of tweaking. For instance, I was able to rollout a custom frontmatter approach with custom rules and defaults, according to my ideal information architecture.

Nevertheless. The project went down. A shame especially because it seems to have been a victim of disruption by covid.

🚫 React Static. I am now using Astro + preact to rebuild my website.

Markdown love

I had been entertaining the idea of basing my website out of simple text files for a looooong time. Maybe because I've been a fan of plain text since the early days of wiki on a stick. It actually hits me now that I might have originally ported my website to Markdown back in 2016? Maybe? 😁

Conclusion? Still the best support for documentation and personal publishing, and probably for many other use cases.

Personally, my favorite medium to think and express myself, directly in the IDE in plain text. No database, no API, no CMS. Everything stored in Github right next to the code.

👍 No brainer. Did not change 4 year later.

Going the distance with MD(X) or...

Since I am some times craving for some exciting half-broken experience, at the time I also decided to use MDX, another content format, a mutation of Markdown if you will, that allows you to also drop React components in the middle of plain text.

But since at the time, literally around mdx@1.0, there were some serious limitation, I took the opportunity to explore how the whole thing works, and tried my hand at wiring up some transformations myself, using some of the code of the Markdown/MDX ecosystem.

Turned out to be a really fun experience!

Ended up using a few libraries from the unified-js ecosystem. Actually, looking at the direct dependencies on my package.json, looks like I was able to put to good use a bunch of these beautiful micro packages.

rehype-autolink-headings
rehype-highlight
rehype-parse
rehype-raw
rehype-react
rehype-slug
remark
remark-emoji
remark-html
remark-parse
remark-rehype
remark-strip-html
remark-toc
remark-unlink
unified
unist-util-filter
unist-util-visit

Did you read that :-D ?

🤯 4 years later, MDX and unified-js ecosystem have come a long way. No more wiring up things manually. I am migrating the website to Astro, which already provides a great MDX integration, anyways.

Operations, performance, costs

The build time with React Static never went over 1 minute. No complains, ever.

I never actually automated this in the cloud, and it was always running in my computer.

💡 Speaking of which. I might change hosting from AWS to Netlify. This site has been hosted on S3/Cloudfront for almost 4 years, at around $2.50/month, but the Netlify is so much better than the AWS monster.

What's next?

Continue reading about how I am rebuilding the website with Astro.

Static site generators: brief history, as I recall it

2019-06-02T00:00:00Z

Hype keeps building up around static site generators. But this technique has been around for much longer than most people think. Our industry's collective memory 🧠 is very short, and it some times needs a little help.

In the beginning the whole web was static. Then there was CGI. Webmasters could now stitch together some dynamic rendering, as well as respond to forms posted by users.

In less than 3 years, CGI evolved into a panoply of glue languages developed exclusively for this purpose - e.g.: ColdFusion, PHP, Ruby, ASP, JSP - or quickly adapted to it - e.g.: Perl, Python.

The golden age of MVC

With the rise of these scripting languages, application servers, and the free relational databases - free as in free beer! - dynamic server-side rendering went from being the next big thing to completely taking over the landscape, all in a couple of years.

At some point, MVC was everywhere, and OO was the craft. And with them, a hundred frameworks written in ColdFusion, PHP, Ruby, Python, Java, and .Net. Soon enough, the scene matured into CMSs of all sizes and flavors. Here's an article from 2007 about the history of the dynamic web for a bit of perspective, from deep within the bubble.

Actually, the dark age of MVC

When I joined SAPO in 2008 I had totally jumped on the MVC framework bandwagon and I didn't really know better. A single code base, a monolith application for several interfaces - public website, rss, atom, back office. We had reached peak design patterns, maximum reusability, and couldn't even sense the smell.

Unfortunately, yet not surprisingly, these database driven websites were not scaling that well. Don't get me wrong, they were dealing with complexity pretty fine, consuming and producing a variety of services, plugged into offline distributed processes, brokers, full-on SOA, the works.

Run-time, though, writes and reads were competing for stretched out DB servers, and in order to keep the latency at acceptable levels, and to serve the apps with decent availability the operational costs were spiking. Blinded by the automagical lights, we were categorizing all the challenges under optimise this later. Caching partials and responses, abusing cache farms, replicating the DB, micro optimising code, ... Plenty of technical solutions evolving, but at what cost?

Rendering like rebels

Meanwhile, back to SAPO, the older crew there, thought differently.

These were a bunch of very talented engineers, and a handful of legend level Perl and C developers, that had built a network of hundreds of large scale, high traffic, high availability websites, among so many other things, like dozens of mobile apps and even sending tech to space just for fun.

So how did they think differently from the predominant MVC doctrine? Quite simple. First: pre-rendering all the static content, and serving pure html+css. Second: a layer of client-side progressive enhancement, rendering the user aware content, such as comments, ratings, favorites, directly in the browser. Sounds familiar?

Whenever an editor published something on their CMS, entire websites or sections, were re-generated. After all, these back offices had like 2 journalists and an intern doing most of the writes. While the actual websites had millions of users doing all the reads and, only occasionally, an interaction.

What was going on here? How could a bunch of disconnected perl scripts be better, faster, and cheaper than the elegant, modular, extensible approach? Turns out pre-rendering, or pre-burning, "queimar" in Portuguese, materializing the end user state as soon as the source data was updated, wasn't even news in 2008. If you read the first section above, it was the actual origin story of the dynamic web. It had already been around for 10 years.

The plot twist we deserved

Meanwhile, the web-standards movement was striking win after win. With Firefox and Chrome, the browser was becoming a viable application platform, and client-side rendering, beyond the initial AJAX hacks, was becoming a believable idea.

Suddenly, the paradigm was shifting. Along came NodeJS, the NoSQL movement, and a massive simplification of the application server approach. Ditch relational and transactional where you actually don't needed it. Embrace REST, eventual consistency, schemaless, streams, client-side rendering, and much more long awaited techniques. Looked like we now had more options and combining the best of both (all) worlds would be the sensible thing to do.

But it is not surprising that the new bandwagon and its rising tide of followers was riding fast and furious as far away as possible from its starting point. The past is wrong and all prior art needs to be forgotten! Rewrite all the things! Let's now over engineer all things front-end because we can!

Fast forward to 2013: we now have ES6, javascript build tools, Webpack, the NPM ecosystem and a new framework war fueled by Google and Facebook. Suddenly every project must be built as a front-end rendered single page application. Every startup is now hiring the new breed: the full stack developer, a.k.a. let's just use Javascript everywhere for everything. So, what's next? Javascript fatigue, Javascript framework fatigue, and more Javascript fatigue.

The new problem to solve? Overcoming javascript framework fatigue. How did this happen? Did we stop to consider the implications? Were we leveraging all the options? Combining the best of each technology to solve the different problems with the right tools?

When everything you ~~have~~ WANT TO USE is a hammer, everything looks like a nail. Landing page? SPA! personal website? SPA! newspaper? SPA! e-commerce? SPA! dating app for lonely pets? SPA! SPA! SPA! SPA! is the new hammer and it makes the most lovely sound.

History repeats itself

Long story long, welcome to 2019. People are writing posts explaining SSG maybe ignoring that so much of the original web was built exactly that way. Somewhere else, someone is making the case for static site generation every single day.

Gatsby, React Static, Next.js are all the rage. But to be fair to prior art, in the early 2010s, projects like Jekyll then Hugo were already getting a lot of traction in some circles and paved the way for so many SSG options we have now. They are unfortunately not written in everyone's love/hate scripting language, but in Ruby and Go, respectively.

Jekyll is a simple, blog-aware, static site generator perfect for personal, project, or organisation sites. Think of it like a file-based CMS, without all the complexity.

Circling back to the whole point of this post. If you do a quick search for "static site generation" pre 2000s you can find gems like this paper on Tools and Approaches for Developing Data-Intensive Web Applications: a Survey, all the way back in 1998.

An orthogonal architectural issue concerns the time of binding between the content of the information base and the application pages delivered to the client, which can be static when pages are computed at application definition time and are immutable during application usage; or dynamic, when pages are created just-in-time from fresh content.

Do we already know better than letting the bandwagon mentality shoot us again with the new silver bullet? Are we going to make everything static site generated like we did with SPAs? Probably not. But if we don't stop obsessing (and click-baiting) about whether or not SSG is paradigm of the year we will do a lot of damage to projects, businesses, and users.

We have to be a bit less excited about the present and contemplate prior art as well. Better decisions are taken when considering all the options. And the next next big thing will always be a smart mashup of a few old things.

Conclusion

There has never been a more exciting time to develop for the web. We have the codebase, the tools, and the infrastructure to design, develop, and deploy faster, better than ever. And also options: modern SPAs, dynamic SSR, isomorphic rendering, serverless architectures, and more recently (joking! 😅) SSG.

And it's never been easier to mix and match all these ingredients in secure, reliable, and cost-effective ways. Technologically, the entire web landscape has changed 5 times over and we are being gifted with all this potential under open source licenses for our fun and profit.

We all - developers, teams, companies - just need to take a step back some times, and appreciate the options. Learn a bit about the techniques we understand the least and remember that the best solutions are almost always the result of combining different tools.

Content: Markdown with Unified.js + Remark + Rehype

2019-05-16T00:00:00Z

I have been using Markdown to store my websites content for a while. Actually, I have been using forever to organise my life, especially work. Can I keep using it now with React Static?

Status ❌ Replaced

Replaced by Astro which pre-packages Markdown and MDX capabilities.

Note: 4 years later I eventually wrote a blog post to celebrate how big and relevant Unified.js has become

Why

modular library, many plugins
transforms to React
works in both directions
complete working implementation

Trade-offs

not written in typescript and no typings supplied for many plugins
incomplete/inconsistent docs
many repos, different authors

André Torgal: #content-management Feed

MDX authoring experience in Astro / Shortcomings

⚠️ You are looking at an outdated post.

Computer says no

Third-party package: astro-m2dx

Conclusion

Advanced MDX authoring experience / Requirements

Backstory

Shopping list

Seamless preview

Auto complete

Image optimisations

Auto detection of metadata

Frontmatter defaults per type of content

External links

Auto-imports

Why stop here?

Meanwhile

My website: Information architecture

Unified.js is going to be around for a long time

Context

What is it?

How do you use it?

An example using community plugins

The kudos 💯

Titus

How I use Unified.js

Show me some code!

Saying goodbye to my React Static website

Backstory

SSG! Of course

React Static was good, at the time

Markdown love

Going the distance with MD(X) or...

Turned out to be a really fun experience!

Operations, performance, costs

What's next?

Static site generators: brief history, as I recall it

The golden age of MVC

Actually, the dark age of MVC

Rendering like rebels

The plot twist we deserved

History repeats itself

Conclusion

Content: Markdown with Unified.js + Remark + Rehype

Status ❌ Replaced

Why

Trade-offs

Third-party package: `astro-m2dx`