-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Allow remark/rehype plugins added after mdx to work #10877
Conversation
🦋 Changeset detectedLatest commit: 06c2cb9 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 |
This looks like a great improvement that will allow me to eliminate a bunch of code to check for integration ordering of EC vs MDX, and should also prevent the need for the |
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.
Thank you @bluwy! Agree with Hippo that this will be a nice user QoL thing to not need to worry about order any more.
// `mdxOptions` should be populated at this point, but `astro sync` doesn't call `astro:config:done` :( | ||
// Workaround this for now by skipping here. `astro sync` shouldn't call the `transform()` hook here anyways. |
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.
Interesting. @bholmesdev mentioned an issue with astro sync
and Astro DB the other day, which I wonder if it might be related — it also uses astro:config:done
in a similar pattern to this to assign settled integration state for use by plugins.
astro/packages/db/src/core/integration/index.ts
Lines 88 to 89 in 5bf5dd4
tables.get = () => dbConfig.tables; | |
seedFiles.get = () => integrationSeedPaths; |
Maybe something that will need fixing in sync
itself?
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.
Yeah I think it would be nice if the hook was called in Astro sync too. I initially did that, but walked back a bit because I'm unsure if this breaks the db integration.
I noticed the db integration is running the same startup code in both astro sync
and astro:config:done
, and I'm unsure what happens in astro sync
if it runs that code twice. It should be something we can look into fixing in the future though.
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!
* fix(mdx): convert remark-images-to-component plugin to a rehype plugin (#10697) * Remove fs read for MDX transform (#10866) * Tag MDX component for faster checks when rendering (#10864) * Use unified plugin only for MDX transform (#10869) * Only traverse children and handle mdxJsxTextElement when optimizing (#10885) * Rename to `optimize.ignoreComponentNames` in MDX (#10884) * Allow remark/rehype plugins added after mdx to work (#10877) * Improve MDX optimize with sibling nodes (#10887) * Improve types in rehype-optimize-static.ts * Rename `ignoreComponentNames` to `ignoreElementNames` I think this better reflects what it's actually doing * Simplify plain MDX nodes in optimize option (#10934) * Format code * Minimize diff changes * Update .changeset/slimy-cobras-end.md Co-authored-by: Sarah Rainsberger <[email protected]> --------- Co-authored-by: Armand Philippot <[email protected]> Co-authored-by: Sarah Rainsberger <[email protected]>
Changes
This PR moves the markdown options generation to the
astro:config:done
hook so that remark/rehype plugins added by integrations after@astrojs/mdx
duringastro:config:setup
hook works.This should unblock
astro-expressive-code
needing@astrojs/mdx
in a specific order to work, which should remove the hack in withastro/docs#7972cc @hippotastic does this work for you?
cc @delucis
NOTE: The implementation would be simpler if I added the Vite plugin in the
astro:config:done
, but other integrations also add Vite plugins inastro:config:setup
. I figured it's more predictable if we also do so.Testing
Added a new test.
Docs
I don't think this will affect many projects in practice, but I added a changeset explaining the migration path if so.