[Markdoc] New config format with runtime variable support!

[bholmesdev]

Changes

Markdoc.BIG.IMPROVEMENTS.mp4

• Move Markdoc configuration options from your astro.config.mjs to a new markdoc.config.mjs
• Remove the components property from the <Content /> component. Components can now be imported from the markdoc.config.mjs and applied to the render property directly. No need for magic string mapping anymore 👏
• Add deps to @astrojs/markdoc: esbuild for processing the markdoc.config, kleur for formatted logging
• Support passing variables to your Markdoc files from the Content component. These variables can be passed as props:

---
import { getEntryBySlug } from 'astro:content';

const entry = await getEntryBySlug('docs', 'why-markdoc');
const { Content } = await entry.render();
---

<Content name={Astro.params.username} />

This example name variable is available as $name:

Hey {% $name %}! Let's learn about Markdoc.

Testing

• Update tests to use new Markdoc config
• Variable passing test

Docs

• Update core and example READMEs

[changeset-bot]

🦋 Changeset detected

Latest commit: b51d9a6

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[bholmesdev]

Bye bye wacky error handling 👋

[bholmesdev]

Render tests and fixtures moved to a separate render.test.js

[sarah11918]

Uh, I had only one review comment... and it's praise! 🎉

(Am I slipping....?) Great job with the docs, Ben! 🟣

[sarah11918]

You caught Sarah in the right mood. Flair approved! 💅

[bholmesdev]

Thought I could get away with some flair in the example code 😉

[bluwy]

Looks good 👍

[yanthomasdev]

Nice @bholmesdev 💜, docs LGTM!

[FredKSchott]

I really love this new API. Sorry I couldn't give feedback earlier, but just wanted to confirm:

• Is markdoc.config.js used by anyone else? Is the hope that this is a general format/concept that other projects could use as well and eventually could become a standard, or is it really something that will only ever make sense in this form in an Astro project? I have some thoughts on this.
• Are there any bundling concerns with multiple asides all included in the same global config file? Ex: Say I have 3 tags: A.astro (with scoped styles), B.jsx (or more likely B.astro containing a JSX client:load or client:only island), and C.astro (contains a hoisted script). Are we building Astro projects properly so that the assets only show up for each component on the pages where that component/tag is used?

[bholmesdev]

Thanks @FredKSchott! Discussed offline, but I'll summarize here:

1. Yes, the markdoc.config.js is modeled on the simplest case for NextJS' integration (they offer multiple config options). Feeling pretty comfortable following their lead.
2. The renderer is built to only hoist scripts and styles for components actually used on the page. So there should be no danger of global config meaning global hoisting anywhere you render content. I'll make a PR with a test case to confirm!