Multiple JSX Runtimes

[viridia]

I have a large game engine project that uses multiple JSX runtimes. The "editor" component uses React, while the "game" component uses a custom JSX factory that creates a tree of game objects. (The game itself, without the editor, doesn't depend on React but it does use JSX.)

Currently the way I am handling this is:

• Building the editor and the game as separate compilations, each with their own tsconfig.json that has the "jsx" options set.
• Using the old, deprecated vite-react-jsx plugin which supports these tsconfig options. (This also means I am stuck on Vite 2.9).

This strategy doesn't work with the new plugin. I've tried playing with both tsconfig and the @jsx pragma, and it appears to always use the React "automatic" runtime no matter what I do.

However, what I'd really like is to be able to compile everything in a single Vite build - this would mean either having to put jsx pragmas in every file, or (better) being able to set the runtime on a per-directory basis, using include/exclude patterns in vite.config.js. (Note that, according to the docs, the "include" option on the jsx plugin only controls which modules are hot reloaded, not which modules are transformed.)

I can "kind of" make things work by precompiling the game using tsc, but this means I lose all hot reloading and other nice DX of Vite.

[ArnaudBarre]

I think this use case never come up before but it should be possible to handle it in the future for TS now that jsx transformation is done via esbuild because the esbuild plugin correctly resolve options for nested tsconfig. The issue is that the options for jsx runtime is overridden for all files here: https://github.com/vitejs/vite-plugin-react/blob/main/packages/plugin-react/src/index.ts#L136-L156

You can try to patch it and remove these lines. I will see if I can simplify this in the next major version

[viridia]

Thanks! That will be a big help. I can get by using the older plugin until the next version or two. And yes, I realize my use case is rather esoteric :)

Another approach I tried, which I couldn't get to work, is using file-specific babel configs. I thought that this might work because:

1. The plugin has a "babel/configFile" option to tell it to read babel configs.
2. Babel allows per-file and per-directory configuration overrides.

I even tried putting in garbage in the babel conf to see if it was even being parsed; as far as I could determine, it wasn't.

[ArnaudBarre]

I don't know how Babel handle directory specific configurations.
But I just saw that you can use a callback for babel options, so that you can put your logic into it. But since in v3 jsx is not done by this plugin this is not useful but could allow you to use Vite 3 & the version 2 of this plugin

[viridia]

Here's what the Babel website says about "file-relative configuration":

https://babeljs.io/docs/en/config-files

Babel loads .babelrc.json files, or an equivalent one using the supported extensions, by searching up the directory structure starting from the "filename" being compiled (limited by the caveats below).

In other words, you can drop a babel config file in the same directory as the source file being compiled. This behavior has to be specifically enabled at the project root (otherwise it would be hideously expensive I imagine.) You can enable the searching behavior for individual subpackages by modifying the "babelrcRoots" configuration in the root babel config.

For my use case, I'd only enable this for the subpackage that contains the game logic, and disable it for all others.

However, from what you are saying it sounds like the plugin overrides the configuration, so this path won't work. That means I'd have to fall back to using nested tsconfigs (which is what I am doing now, using the old deprecated reactJsx plugin.)

I'd like to understand better what you mean by "in v3 jsx is not done by this plugin". I'm not very familiar with the inner workings of Vite.

[ArnaudBarre]

Oh ok so this is because of https://github.com/vitejs/vite-plugin-react/blob/main/packages/plugin-react/src/index.ts#L443

But this still not solved your problem because since v3 we tell Babel to output jsx and let esbuild to jsx -> js: vitejs/vite#9590

[viridia]

Ah got it. Now I understand. I imagine that the jsx-solid plugin has similar issues.

[viridia]

Hey, just wanted to let you know that I've decided to try a different approach, which means that this issue is no longer a priority for me. I've shifted away from using JSX syntax and am now using explicit constructor functions for my tree.

I had thought, at one point, that the idea of using JSX to build reactive trees of NPC behavior - that is, hierarchies of goals which would recalculate in response to changes in the game world - was a clever idea. I guess perhaps it was a bit too clever :)

Anyway, here's a sample of what the code looks like now:

    return [
      G(Converse, {
        when: () => self.isTargetedByPlayer,
        dialogues: ['regional/tambry:Ivy.Dialogue'],
        priority: GoalPriority.SOCIAL,
      }),
      G(Sequence, { loop: true }, [
        G(Random, { norepeat: true }, [
          G(UseCookPot, { fixture: 'inn.cookpot', mark: 'use', distance: 0.4 }),
          G(KitchenWork, { fixture: 'inn.worktable.0', mark: 'use', distance: 0.7 }),
          G(KitchenWork, { fixture: 'inn.worktable.1', mark: 'use', distance: 0.7 }),
          G(UseLocalFixture, {
            fixture: 'ivy.bed',
            mark: 'sleep',
            distance: 0.8,
            weight: 0.2,
            children: (position: Vector3) =>
              G(Contingent, {}, [
                G(LookAt, { target: position, relativeAngle: Math.PI }),
                G(Pose, {
                  delay: 4,
                  animation: {
                    type: 'stand',
                    clipNames: ['Sit'],
                    holdAtEnd: true,
                  },
                }),
              ]),
          }),
        ]),
        G(Wait, { delay: 2 }),
      ]),
    ];