MDX authoring experience in Astro / Shortcomings
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!
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
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
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.
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.
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.
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.