Is the sub-plugin approach the right way to do it?

[flogy]

Currently, this plugin is meant to be used as a sub-plugin for gatsby-plugin-mdx.

The idea behind this decision was:

• As we look for the <SpeechOutput> component inside MDX files to then extract the enclosed content to tranform it into speech output files, the user of this library is forced to use MDX anyway. So it kinda makes sense to then define it as a sub-plugin.
• As we register this plugin inside the gatsbyRemarkPlugins array we will receive the mdxAST directly, being able to search it for the <SpeechOutput> components easily.

What I think speaks against this approach:

• It is a bit weird to generate new files here. As I understand this is usually done inside the gatsby-node.js file, e.g. in the onCreateNode step.
• Also, we can't add new nodes to Gatsby and thus make the speech output files queryable via GraphQL.
• I experienced some difficulties with having a default export in the index.js file of this plugin (which is required by gatsby-plugin-mdx) and exporting a React component as well. Maybe this problems would disappear when just using the same approach as e.g. gatsby-background-image.

Question to the experts: Are we on the right path with this approach? Or which approach would you suggest using? Maybe even a completely different one?

Thanks in advance.

[flogy]

I have now tried to get it running with the other approach using the onCreateNode method. I then discovered that the nodes created by gatsby-plugin-mdx do not contain the mdxAST. Therefore, I have created a PR to add that property to the nodes so we would be able to proceed with that approach if desired.

Link to the PR: https://github.com/gatsbyjs/gatsby/pull/21723

[flogy]

Unfortunately, the PR was rejected as the reason behind was not clear enough / the mdxAST can be accessed in other ways (e.g. how it is currently done in this plugin as well: by creating a sub-plugin for gatsby-plugin-mdx).

This means, we should probably stick to that approach and try getting it to work somehow. I will therefore close this issue.