jsx: true output does not handle custom elements correctly

[bholmesdev]

Initial checklist

• I read the support docs
• I read the contributing guide
• I agree to follow the code of conduct
• I searched issues and couldn’t find anything (or linked relevant results below)

Affected packages and versions

^2.1.2"

Link to runnable example

https://stackblitz.com/github/bholmesdev/mdx-shiki-compilation?file=test.mjs

Steps to reproduce

1. Run the MDX compiler with the rehypeRaw plugin applied + some other plugin that inserts a custom element (Shiki twoslash in this case).
2. Set jsx: true in the compiler config
3. Note the value contains <_components.custom-element-name> in the output, but dashes (-) are not valid JSX!

Expected behavior

Ideally, the _components statement would serialize dashes to camelCase or some other JSX-compliant string like so:

const _components = Object.assign({
    ...
    "customElementName": "custom-element-name"
  }, props.components);

Actual behavior

Instead, _components uses the element name untouched:

const _components = Object.assign({
   ...
    "custom-element-name": "custom-element-name"
  }, props.components);

Runtime

Node v16

Package manager

pnpm

OS

macOS

Build and bundle tools

Other (please specify in steps to reproduce)

[bholmesdev]

This is related to a new issue in Astro's MDX integration: withastro/astro#4258

[wooorm]

Could you get away with ditching the JSX language? Compiled away JSX can express this.

Otherwise, I'm not sure what MDX could do about it. Turning dashes into camel seems like something other people would disagree with.
We could turn off looking them up into "components" when JSX is turned on?
Or, maybe as a plugin or an option?

[bholmesdev]

@wooorm See my PR above! Unfortunately, Astro relies on our own JSX transformation process, so we cannot abandon this JSX output. I also discovered a unit test in the repo that asserts MDX outputs invalid JSX for custom elements. Regardless, I think a fix is warranted.

I also agree that camel case isn't the best approach. I've opted for replacing invalid identifier characters with underscores _ instead! See PR for more.

[wooorm]

One more alt: what if we turn invalid IDS into valid, different IDS, that still get them from components?

With a:

const _component1 = _components["a-b"]

...

<_component1>...

[bholmesdev]

@wooorm That could work too! So create variables below the _components declaration with an incrementing counter?

[wooorm]

Yeah, create throwaway variables.
Only create them if JSX is on (or always if it doesn't hurt, I don't think it typically does)
Counters are easiest, alternative and more readable is a camel case variant, with a tiny chance of conflicting.
If we only do it for invalid IDs I don't think it can ever conflict?

I like that much better than changing what we get from components, and hence that users have to change what they pass too?

[bholmesdev]

@wooorm Addressed in the latest! Should be good for review. #2101