esbuild plugin: use esbuild "jsx" loader if output is JSX

[egnor]

Initial checklist

• I read the support docs
• I read the contributing guide
• I agree to follow the code of conduct
• I searched issues and discussions and couldn’t find anything or linked relevant results below
• I made sure the docs are up to date
• I included tests (or that’s not needed)

Description of changes

In the esbuild plugin, if the MDX pipeline is configured to output unprocessed JSX (via jsx: true in its options), have esbuild expect JSX (via loader: "jsx" instead of the default "js"). This allows users to freely choose whether the JSX-to-JS processing happens in the MDX pipeline or in esbuild (both are capable of doing it).

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
mdx	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Feb 24, 2025 11:03pm

[wooorm]

why do you want to use esbuild’s jsx loader?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (908ff45) to head (63dcce6).
Report is 83 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff            @@
##              main     #2593   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           23        21    -2     
  Lines         2693      2647   -46     
  Branches         2         2           
=========================================
- Hits          2693      2647   -46     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[egnor]

(updated with test & fix for undefined-options; linked #2594 with repro steps for properness)

why do you want to use esbuild’s jsx loader?

somehow I knew you'd ask!

pragmatically, this can be useful?

• keeping JSX-to-JS translation in one place is useful, the options can be a little subtle given the many flavors of JSX transform and various "automatic" transformers kicking around
• people may do subsequent / nonstandard things with JSX in their build system globally, that should apply to the JSX from MDX but also the JSX from (say) React components or whatnot
• in my particular specific case, I want my recma plugins to see untransformed JSX; that's a rather idiosyncratic case and perhaps best ignored, but jsx: true does exist and I felt like it ought to work

philosophically, this feels like a basic correctness fix?

• {jsx: true} is a valid documented reasonable option, why shouldn't it work?
• esbuild requires onLoad callbacks to specify the loader (effectively content type), "js" is just the default value. in this case we know whether the output is "js" or "jsx", both of which are natively supported by esbuild, so why not set it correctly?
• it's a super simple change, easily tested, correct by inspection, unlikely to add maintenance burden, and removes surprise

[wooorm]

It is probably good to add the same feature to other loaders. Though perhaps not in this PR.

I do think it’s better to not use this. That much of your troubles come from integrating so closely with JSX instead of the other ASTs.
But as you point out, this option exists.