Esm: recommended way to use this while compiling jsx on the server ?

[misterfresh]

There are various issues on this subject already which I have read.

What is the current recommended way to use esm while compiling files that contain jsx ?

[jdalton]

Hi @misterfresh!

Ideally you'd do what you do today. If that means preprocessing files from a src to lib folder that's fine as long as the lib/index.js (or whatever your main file is) loads @std/esm and creates the loader. If you're using babel-register though I need to patch it first.

[misterfresh]

As I understand it, esm is aimed for development use ?
I would use it for development in which case I like to compile on the fly and yes I use precisely babel register.
In latest node version, the only things that really need compiling is the modules ( common js to es) and jsx. I know it its probably outside scope but adding built in jsx support could get you instant large usage from the react community and might be easier than patching babel.
Is there a performance advantage to use esm vs latest node + Babel with only react preset and es modules plugin?

[jdalton]

As I understand it, esm is aimed for development use ?

Nope, it can be used in production. Lodash v5 will depend on it.

Is there a performance advantage to use esm vs latest node + Babel with only react preset and es modules plugin?

Yes @std/esm will be faster but it also simulates native ESM in Node better (see Node rules).

[mindplay-dk]

From a quick first experiment with esm in a test...

I have a really simple test, like this:

import { test } from "zora"

test("all that jazz", is => {
  is.equal(1, 1);
  is.equal(1, 2);
})

And now I run the test:

node -r @babel/register test/hello.test.js           <- painfully slow
node -r esm test/hello.test.js                       <- blazing fast
node -r @babel/register -r esm test/hello.test.js    <- blazing fast 👀
node -r esm -r @babel/register test/hello.test.js    <- blazing fast 👀

It doesn't seem to matter if I load @babel/register or esm first - the import statement in the test works fine, and the script is insanely fast compared to just loading @babel/register. How is that possible??

Now throw a bit of jsx in the mix:

/** @jsx h */

import { test } from "zora"

const h = (type, props, ...children) => ({ type, props, children })

test("all that jazz", is => {
  console.log(<div>foo</div>)
  is.equal(1, 1);
  is.equal(1, 2);
})

And now the import statement stops working:

$ node -r esm test/hello.test.js
/mnt/c/workspace/fre/test/hello.test.js:3
import { test } from "zora"

SyntaxError: Unexpected token {
    at Object.compileFunction (vm.js:406:10)
    at Generator.next (<anonymous>)

WAT?

Running it with node -r @babel/register works fine, but is slow. (as usual.)

Running it with node -r esm -r @babel/register also works, but is almost twice as slow. 🤨

Running it with node -r @babel/register -r esm, same deal.

(Does the order matter at all?)

So, back to OP's question:

What is the current recommended way to use esm while compiling files that contain jsx ?

And to your reply:

Ideally you'd do what you do today.

Sorry, but I'm a bit lost here. 😶

If I have to add Babel to get JSX, and if Babel already handles both JSX and ES modules, what do I get by adding esm? For the moment, all I can see is this makes things almost twice as slow. (which is baffling, considering how much faster it works on a file with no JSX expressions in it.)

I was really hoping to get the "simple, babel-less, bundle-less" experience (if only for my test-suite) but that doesn't really seem possible if you need JSX at the moment?

What am I missing here? 🤔