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.