Support Astro

[seancdavis]

Add your vote for Astro support by clicking the 👍 emoji below.

[bholmesdev]

Worth mention that we do support type-safe markdown imports in Astro today! See the Astro.glob reference + the MarkdownInstance type. This is missing a few key pieces though:

• a shared schema for markdown frontmatter
• integration with headless CMSes for similar import-ability. This second piece would be huge for Astro's content story!

[bholmesdev]

Also worth mentioning: we use asynchronous imports of the markdown content rather than synchronous. This is vital for building landing pages, where users can bypass rendering the content itself and just iterate over frontmatter. I'd definitely recommend that Contentlayer do the same in Vite environments.

[kirso]

Is there any a progress or ranking of all integrations like Next in line? I believe the work has started on Vite but wonder what will follow (obviously with Astro in mind).

[seancdavis]

@sokirill We have a roadmap, which is meant to share what we have planned, though it may change.

We don't have many upcoming frameworks or content sources listed. We're working through the priorities and will be updating the roadmap over the next couple weeks.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[timfee]

Hi friends,

Reusing a decent amount of the next-contentlayer code, I was able to get files to be generated on change (in dev server mode) and in build. A lot of it was getting Vite to play nice.

Files are now generated, but I'm getting an error:

error   Missing "./generated" export in "contentlayer" package
  File:
    /Users/timfee/Sites/astro-contentlayer/src/pages/index.astro

If anyone wants to help tweak this, I can talk to the Astro folks to see what an alpha version could look like. (Though, NB I haven't really played around with any of the advanced mdx stuff Astro tries to build in, but this could be a workable interim solution for folks w/o complicated setups)

https://github.com/timfee/timfee-astro-contentlayer

[Frikadellios]

I want to try use with bun.sh and codegen, maybe this package contains something special 😂❤️

[zdunecki]

Hi folks,

Do you consider to support Astro in the next year?

In my company we're exploring Astro and we're very happy. Also we build something similar to contentlayer but it's not our goal it's only means to an end.

I didn't knew about contentlayer before but it looks like a cool project that can be a part of our internal tool but support for Astro and Markdoc would be approciated.

Best

[bholmesdev]

@zdunecki Content collections should be a good pick in the meantime! Curious if you've explore those yet or have any feedback for the team?

[zdunecki]

@bholmesdev Sure we used Collections.

We're exploring how we can use Astro and Markdoc together to achieve our main goal - managing content should be as easy as possible (for noncoders) and theme/content engine should be extendable by developers.

For example, we must render multiple sidebars based on context, have low-level API to build custom pages programmatically (e.g Docs API Reference), and another staff (routing, etc.) that can be rendered conditionally but still keep content far from code (like Markdoc does) - for instance, sidebar and header can be fully managed by content people and routing is based on filesystem.

Based on those conditions we had to create a little abstraction (something similar to contentlayer.config.ts) but with a worse API😄 (it's still experimental) that can match collections with folders (using filesystem routing). We use virtual modules for component extensions. There's still a lot of work to find a good interface and how it can be used by content people, developers, and theme users (probably also developers).

It's our side project but we make contributions to that project regularly.