Deno panic using JSX

[begoon]

Code to reproduce:

/** @jsx react-jsx */
/** @jsxImportSource https://esm.sh/preact */

import { render } from "https://esm.sh/preact-render-to-string@6.3.1";

const component = <h1>Hello World</h1>;

console.log(render(component));

execute: deno run main-deno.tsx

deno.json:

{
    "compilerOptions": {}
}

RUST_BACKTRACE=1 deno run main-deno.tsx    

============================================================
Deno has panicked. This is a bug in Deno. Please report this
at https://github.com/denoland/deno/issues/new.
If you can reliably reproduce this panic, include the
reproduction steps and re-run with the RUST_BACKTRACE=1 env
var set and include the backtrace in your report.

Platform: macos aarch64
Version: 1.39.3
Args: ["deno", "run", "main-deno.tsx"]

thread 'main' panicked at /Users/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/swc_ecma_transforms_typescript-0.186.14/src/typescript.rs:131:13:
failed to determine top-level Id for jsx expression
stack backtrace:
   0: _rust_begin_unwind
   1: core::panicking::panic_fmt
   2: swc_ecma_transforms_typescript::typescript::id_for_jsx
   3: <swc_ecma_ast::module::Program as swc_ecma_visit::FoldWith<V>>::fold_with
   4: deno_ast::transpiling::fold_program
   5: deno_ast::transpiling::<impl deno_ast::parsed_source::ParsedSource>::transpile
   6: deno::emit::Emitter::emit_parsed_source
   7: deno::module_loader::PreparedModuleLoader::load_prepared_module
   8: <deno::module_loader::CliModuleLoader as deno_core::modules::loaders::ModuleLoader>::load
   9: <deno_core::modules::recursive_load::RecursiveModuleLoad as futures_core::stream::Stream>::poll_next::{{closure}}
  10: <deno_core::modules::recursive_load::RecursiveModuleLoad as futures_core::stream::Stream>::poll_next
  11: <deno_core::modules::recursive_load::RecursiveModuleLoad as futures_core::stream::Stream>::poll_next
  12: deno::worker::CliMainWorker::execute_main_module_possibly_with_npm::{{closure}}
  13: deno::worker::CliMainWorker::run::{{closure}}
  14: deno::tools::run::run_script::{{closure}}
  15: deno::spawn_subcommand::{{closure}}
  16: <deno_unsync::task::MaskFutureAsSend<F> as core::future::future::Future>::poll
  17: tokio::runtime::task::raw::poll
  18: deno::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[begoon]

If I remove the first line /** @jsx react-jsx */, it does NOT crash anymore and prints:

<h1>Hello World</h1>

as expected.

[begoon]

In Deno v1.39.4 the issue still stands.

[begoon]

============================================================
Deno has panicked. This is a bug in Deno. Please report this
at https://github.com/denoland/deno/issues/new.
If you can reliably reproduce this panic, include the
reproduction steps and re-run with the RUST_BACKTRACE=1 env
var set and include the backtrace in your report.

Platform: macos aarch64
Version: 1.39.4
Args: ["deno", "run", "a.tsx"]

thread 'main' panicked at /Users/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/swc_ecma_transforms_typescript-0.186.14/src/typescript.rs:131:13:
failed to determine top-level Id for jsx expression
stack backtrace:
   0: _rust_begin_unwind
   1: core::panicking::panic_fmt
   2: swc_ecma_transforms_typescript::typescript::id_for_jsx
   3: <swc_ecma_ast::module::Program as swc_ecma_visit::FoldWith<V>>::fold_with
   4: deno_ast::transpiling::fold_program
   5: deno_ast::transpiling::<impl deno_ast::parsed_source::ParsedSource>::transpile
   6: deno::emit::Emitter::emit_parsed_source
   7: deno::module_loader::PreparedModuleLoader::load_prepared_module
   8: <deno::module_loader::CliModuleLoader as deno_core::modules::loaders::ModuleLoader>::load
   9: <deno_core::modules::recursive_load::RecursiveModuleLoad as futures_core::stream::Stream>::poll_next::{{closure}}
  10: <deno_core::modules::recursive_load::RecursiveModuleLoad as futures_core::stream::Stream>::poll_next
  11: <deno_core::modules::recursive_load::RecursiveModuleLoad as futures_core::stream::Stream>::poll_next
  12: deno::worker::CliMainWorker::execute_main_module_possibly_with_npm::{{closure}}
  13: deno::worker::CliMainWorker::run::{{closure}}
  14: deno::tools::run::run_script::{{closure}}
  15: deno::spawn_subcommand::{{closure}}
  16: <deno_unsync::task::MaskFutureAsSend<F> as core::future::future::Future>::poll
  17: tokio::runtime::task::raw::poll
  18: deno::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[bartlomieju]

@dsherret could you please take a look?

[magic-akari]

react-jsx will be parsed as react - jsx which is a subtraction binary expression and cannot be used as valid JSX.
A valid JSX can be h or preact.h.

For SWC, a user-friendly error is preferable to a panic.

[marvinhagemeister]

I think there is a bit of confusion as to what the @jsx comment does. It sets the pragma for the classic JSX transform. That value is expected to be something callable like React.createElement or h. It doesn't set the jsx transform mode which may seem like it does because TypeScript's jsx compiler option is named the same way.

That said Deno should not panic on this though.

[melbourne2991]

In the context of Deno I don't think it should error at all right? Given it's a runtime, not a compiler.

[marvinhagemeister]

Deno is kinda both. To support TypeScript the types need to be stripped somewhere since V8 only works with normal JavaScript. Same is true for JSX, so there are some light transpilation passes in Deno to make this work.

[melbourne2991]

Yeah that's true. I think in this case though, an invalid pragma is still valid javascript/typescript?

I did a quick test and it panics even if you have just the pragma without any JSX.