Proposal: [breaking-change] Default to h and Fragment for JSX

[kitsonk]

Currently, Deno CLI defaults to effectively the following compiler options for TypeScript:

{
  "compilerOptions": {
    "jsx": "react",
    "jsxFactory": "React.createElement",
    "jsxFragmentFactory": "React.Fragment",
  }
}

I believe it is far more common though in Deno to not use React specifically for server-side rendering, the most common use case for JSX/TSX in Deno. Instead I think modular libraries where you import h and Fragment are far more common (Like Preact or Nano-JSX).

I propose we default to the following settings:

{
  "compilerOptions": {
    "jsx": "react",
    "jsxFactory": "h",
    "jsxFragmentFactory": "Fragment",
  }
}

Currently, anyone using one of these "importable" libraries has to either use the --config option on the command line, or use the TypeScript JSX pragma in each file:

/** @jsx h */
/** @jsxFragment Fragment */

Considerations

• Deno Deploy uses h and Fragment and is only overridable via the pragmas.
• There are the "new" React transforms which we need to support (see: Support new JSX transforms #8440)
• Considering it is a breaking change, should we introduce a flag to restore the old behaviour, like --jsx-react or just people to use --config or the pragma? I am for documenting it and encouraging people to use --config or the pragma if they want the old behaviour.

[ry]

Ideally we could have a deno_lint rule that would appropriate warn people of this upcoming change.

Unfortunately it seems like deno_lint does not take into account tsconfig yet.

[bartlomieju]

Ideally we could have a deno_lint rule that would appropriate warn people of this upcoming change.

Unfortunately it seems like deno_lint does not take into account tsconfig yet.

It's a low hanging fruit to pass tsconfig options to deno_lint

[bartlomieju]

Opened an issue in deno_lint repo. To make it work, deno lint subcommand should accept --config flag as well.

[kitsonk]

One suggestion on this has been to "turn off" JSX by default and to encourage people to use the pragmas of @jsx, @jsxFrag and @jsxImportSource on a per file basis (or maybe even just @jsxImportSource). Some considerations on this would be:

• Does turning it off and "locking" people out increase or decrease portability of code?
• Does encouraging people to use the pragmas on a per file basis increase or decrease portability?
• The new transforms (Support new JSX transforms #8440) import an extension-less import, and everyone just seems fine with that. We can resolve that magic.
• Nano-JSX (a lightweight JSX library that targets Deno and NodeJS) doesn't currently support it (see: Consider supporting the React JSX transform API nanojsx/nano#20).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[marvinhagemeister]

@bartlomieju I think this can be closed. Pretty much everyone switched to the newer automatic runtime transform where you specify a single jsxImportSource value. One could argue that changing this default from react to something else could be done, but given that every other JSX transpiler defaults to react we shouldn't deviate from the ecosystem.

[bartlomieju]

@marvinhagemeister we discussed this yesterday and David wants to change it.

[marvinhagemeister]

Oh in that case I don't mind. Happy it assist in any way possible 👍

[bartlomieju]

Discussed with Luca and David and we feel it's not worth the effort to switch these as the most used way to configure JSX is jsxImportSource these days as pointed out by Marvin in (#11186 (comment)).

Closing without further action.