Option to just compile JSX to object literal

[thesoftwarephilosopher]

Hey everyone, great project. It's part of the basis of my custom runtime for my ssg.

One issue I have right now is that I can't use jsxRuntime: "automatic" and control the import it generates. Because my runtime is also intended be compatible with how JS modules work in the browser, I have to manually replace .jsx with .js in the code you generate. Obviously not ideal.

Technically I could just request an option to customize what the auto-import path is. But that's still not ideal, because all I'm doing with the JSX you output is just creating object literals at runtime anyway,

Ideally I'd prefer to have an option where JSX is transformed into:

interface JSX {
  _isJsx: true,
  tag: string,
  attrs: Record<string, any> | null,
  children: any[],
}

Can we please have this as an option so I don't have to do weird buildtime/runtime hacks to essentially get this behavior anyway?

[thesoftwarephilosopher]

As an example, given:

const comp = <>
  <div>
    <Foo bar={qux}/>
  </div>
</>;

it would become:

const comp = {
  _isJsx: true,
  tag: '',
  attrs: null,
  children: [
    {
      _isJsx: true,
      tag: 'div',
      attrs: null,
      children: [
        {
          _isJsx: true,
          tag: Foo,
          attrs: { qux },
          children: []
        }
      ]
    }
  ]
}

[alangpierce]

Hey @sdegutis , sorry for the delay. Unfortunately I think I'll need to call this request out of scope for Sucrase, at least for now. The goal of Sucrase is to take the most common and well-established transforms and re-implement them in a way that's lighter-weight and more specialized. Part of what makes that reasonable to maintain is to focus on a small number of options rather than allowing lots of configuration in how the transform behaves. I personally would really love it if the community standardized on a new JSX strategy that simply converted it to an object literal, but the current auto-imported function call is what we have today, and it's not the place of the Sucrase project to define a new standard. Of course, if other transpilers started implementing a transform like this, then Sucrase would as well.

I realize I'm responding a bit late, but I read about your specific issues and a few thoughts that came to mind that might be helpful:

• Supposedly the standard way to make import {jsx as _jsx} from "core/jsx-runtime"; (with no file extension) work in the browser is to use import maps. I haven't played around with it myself, but it might be something to explore if you haven't.
• Another thought about the auto-import is that you could just use the classic runtime, which doesn't auto-generate any imports. You could set jsxPragma to some function that you define inline in the transformed code, for example. The automatic runtime is actually harder to work with when you're building tooling since it falls back to createElement (the classic runtime) in some cases (see link in the next bullet), so it basically has all the complexity of createElement plus more complexity.
• As mentioned in this comment, the long-term goal of the automatic runtime is actually to act as a transition period toward a transform that just creates a plain object literal (or at least calls a function that returns an object literal). To my knowledge, there hasn't really been any additional progress there, but I'm hoping for things to become simpler in the long term.
• Regarding replacing .jsx with .js, the convention I'm aware of at least for TypeScript is to have imports reference the compiled filename (or, if you're using compile-on-the-fly or a bundler, the hypothetical compiled equivalent of the file), so basically always .js. Consistent with TypeScript's stance to not rewrite import statements, Sucrase doesn't rewrite import statements. Of course, that requires tooling (like IDE autocomplete and navigation) to cooperate.

Hope that's useful. I'll close this issue for now since I think the main request is out of scope for Sucrase.