How to detect if ESAST originated from MD or MDX in a Recma plugin

[talatkuyuk]

I'm developing a new recma plugin that analyzes the ESAST to apply certain transformations. However, I need to determine whether the ESAST was generated from "md" or "mdx" content, because the plugin should only apply changes if the original content was MDX.

How can I detect or differentiate whether the ESAST comes from "md" or "mdx"?

[remcohaszing]

If it has positional info, it came from original source code.

[remcohaszing]

Ok great! That use case adds a lot of context to the conversation.

I think this plugin would work better as a remark plugin. Then you can replace markdown image nodes with an mdxJsxFlowElement or mdxJsxTextElement node. I imagine something like this:

import { propertiesToMdxJsxAttributes } from 'hast-util-properties-to-mdx-jsx-attributes'
import { Root } from 'mdast'
import { Plugin } from 'unified'

const remarkPlugin: Plugin<[], Root> = () => {
  return (ast) => {
    visit(ast, 'image', (image, index, parent) => {
      if (index == null) {
        return
      }

      if (parent == null) {
        return
      }

      if (!hasExpression(image.alt) && !hasExpression(image.title) && !hasExpression(image.url)) {
        return
      }

      parent.children[index] = {
        type: 'mdxJsxFlowElement',
        name: 'img',
        attributes: [
          toAttribute(image.alt, 'alt'),
          toAttribute(image.title, 'title'),
          toAttribute(image.url, 'url'),
          ...propertiesToMdxJsxAttributes(image.data.hProperties)
        ],
        position: image.position,
        children: []
      }
    })
  }
}

In this case I don’t believe it’s really that important to differentiate between MDX and markdown. rehype-mdx-code-props does something similar, and it also works for markdown files.

[talatkuyuk]

Thank you @remcohaszing for taking your time.

I don't want to convert "image" nodes into MdxJsx element type. This may prevent other plugins in chain don't work on that nodes. The use case quite easy via a recma plugin, it is just a matter of changing Literals to Identifiers if the value is curly braced. I am confident for that.

Since {name} like content is related convention of mdx expressions in MDX; I wanted the recma plugin only works with MDX originated ESAST, not markdown. This was my intention to know the ESAST is mdx originated or md originated. Any way, if not feasible to add a sign into vFile.data in somewhere in the code in @mdx-js/mdx, there is nothing to do apart from asking for the format ("md" or "mdx") from the users.

[remcohaszing]

If you want rehype plugins to run on the img elements first, you can also make it a rehype plugin that handles <img> elements. That might be even better, largely indeed because the user can order it wherever they want in respect to other rehype plugins.

If you use recma, you need to handle all JSX variants. I’m probably forgetting some more cases.

• JSX: <img />
• JSX: <_components.img />
• Compiled JSX automatic runtime: _jsx('img', {})
• Compiled JSX automatic runtime: _jsx(_components.img, {})
• Compiled JSX automatic runtime static: _jsxs('img', {})
• Compiled JSX automatic runtime static: _jsxs(_components.img, {})
• Compiled JSX automatic runtime development: _jsxDEV('img', {})
• Compiled JSX automatic runtime development: _jsxDEV(_components.img, {})
• Compiled JSX classic runtime: React.createElement('img', {})
• Compiled JSX classic runtime: React.createElement(_components.img, {})
• Compiled JSX classic runtime without props: React.createElement('img', null)
• Compiled JSX classic runtime without props: React.createElement(_components.img, null)
• Compiled JSX classic runtime custom pragma: h('img', {})
• Compiled JSX classic runtime custom pragma: h(_components.img, {})

I really don’t see the problem of running this plugin on markdown content. I think the odds of users writing ![{props.alt}]({props.src}) inside a markdown document with the intention of rendering the HTML <img alt="{props.alt}" src="{props.src}"> are practically zero. Curly braces typically don’t occur in human facing text or URLs.

Also, if you consider adding an option to enable or disable this plugin based on some condition, the user could also choose to not pass this plugin into their plugin array.

[talatkuyuk]

Thank you @remcohaszing, It was very helpful for me you listed of all JSX variants. I am planning to cover JSX and automatic runtime variants, excluding classic runtime for now. Why I chose the recma this is because I like recma considering it is super powerful, and wanted to make changes directly on compiled source. I feel more confident as well.

I really don’t see the problem of running this plugin on markdown content.

Agree. The plugin will support markdown format as you mentioned.

Also, if you consider adding an option to enable or disable this plugin based on some condition, the user could also choose to not pass this plugin into their plugin array.

Agree. I will add an option to disable the plugin. (instead of asking for the format)

Thanks @remcohaszing, your comments are always very helpful to me.

[talatkuyuk]

The recma plugin aforementioned, called recma-mdx-interpolate, has dropped to npm, waiting to hear your opinions. https://github.com/ipikuka/recma-mdx-interpolate