Expose @astrojs/markdown-remark as a public API

[gingerchew]

Summary

By making @astrojs/markdown-remark, the internal package responsible for Astro's markdown renderer, a public API, it will allow integrations/loaders to better deal with markdown content in a unified/"astro-ified" way.

Background & Motivation

The discussion started in the docs.

By having a "sanctioned" way to process markdown in Astro, developers won't need to bring in their own solutions. It will make it easier to generate markdown and the result will always be what is expected based on the Astro.markdown config.

Goals

A concise, bulleted-list outlining the intended goals of this RFC.

• Give developers of integrations and loaders a built in way to render markdown
  • This simplifies generation of the dataStore.rendered.metadata object for Content Layer
• One way of doing things will make things faster for everyone and reduce overhead.
• No more needing to download an extra markdown processor to load content.

Example

import type { LoaderContext, Loader } from 'astro/content';
/**
 * This is the result of
 * import { createMarkdownProcessor } from '@astrojs/markdown-remark';
 * const markdown = createMarkdownProcessor(AstroConfig.markdown)
 * export { markdown };
 */;
import { markdown } from 'astro:maybe-virtual-module-namespace?'; 

function myLoader(ctx: LoaderContext):Loader {
	return {
		// fetch content
		for (const [id, text] of Object.entries(fetchedContent)) {
			ctx.store.set({
				id,
				body: text,
				// Returning the RenderedContent object would be the best imo
				rendered: markdown(text)
			})
		}
	}
}

I haven't made any real integrations that weren't just "Make this a virtual module", so I'd be interested to see if any real integ-heads had thoughts as well.

[dallyh]

As seen in the docs discussion, this use case will be used extensively in my opinion. The "internal side of Astro's markdown renderer" in this case is @astrojs/markdown-remark.

[gingerchew]

Good point, adding a link would be helpful for people who don't already know about it's existence :)

[altsalt]

Thank you for continuing the discussion, this would be incredibly valuable for me.

By providing an official way to hook-in, projects which define additional plugins in their config could have those plugins impact the 3rd-party loader.