-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: New Markdoc render
API
#7468
Conversation
🦋 Changeset detectedLatest commit: 460104a 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 |
!preview markdoc-component-config |
259f953
to
42e027b
Compare
Setting a very high bar for PR vids here 😲 The changes looks good to me, but I'm curious if we're fine with losing autocompletion for the component imports. I'm leaning towards being fine here as it's lesser bundling and magic. Also, are we able to remove the esbuild bundling entirely now? Side note: I noticed a pattern where external components tend to make rendering slower. MDX has a new option similar to markdoc now likely for the same reason. |
We still need it to process
I was working on a code-gen solution to glob any
This is interesting... but I'm not sure it applies to Markdoc? Markdoc doesn't "compile" components at all. We instead ship a tree of nodes to the runtime, and recurse through to find and render any components found. I'd assume this works the same regardless or where the component came from 🤷 |
I forgot about that! Let's keep it then to not make too many changes.
That's also an interesting approach. Have a small concern if it would scan to many files initially since Astro components can be anywhere, but I'm good if there's plan to tackle this in the future.
Not familiar with the entire markdoc pipeline so I might be wrong, but I assume mixing Astro component rendering inside Markdoc rendering would slow it down, because instead of But anyways I don't want to get side-tracked with this PR 😬 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Also curious to see if others have thoughts on this change
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great, @bholmesdev! Just a tiny nit and maybe a more explicit migration instruction to consider!
!preview markdoc-config-changes |
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Docs LGTM!
This reverts commit 9354b3c.
2479d7d
to
58845ae
Compare
Changes
markdoc-config-changes.mp4
Introduce a new API (yes, another one) for adding components to your Markdoc config. Instead of importing components directly, you can use the
component()
utility to reference components by pathname:Why the change?
.astro
component imports. This should unlock Markdoc's language server as well.npm
packages andindex
files. We used a naive assumption before to stub.astro
imports by file extension. Without this requirement, you can now use Astro components from anywhere!.mdoc
module itself, instead of using a propagated assets flag, which removes Markdoc-specific content collection bugs. This removes our complexresolveId()
code and leans on the same propagated assets logic as Markdown and MDX.Testing
Docs