That's orthogonal, and in fact you probably would use TypeScript to translate JSX to JS when using this library. What this does is (a) provide a Node.js module hook to call your transpile function when it encounters TSX/JSX files, and (b) provide a Node.js module that lets you remap imports, including "react/jsx-runtime" if you want a different JSX implementation.
import module from 'node:module'
const tree = new FileTree('site', import.meta.url)
module.registerHooks(hooks.useTree(tree))
import('site/myfile.js')
Here, site/myfile.js doesn't exist. It gets created as a reference by the FileTree library. Node thinks it is importing it. The import is also automatically reloaded, if the backend changes it. Caches are invalidated and objects replaced.
It's a highly optimized and extremely simple yet robust implementation of it, sure. Is that reason to dismiss it?
Consider Vite's node-side HMR implementation. It creates its own module system on top of Node's native module system, using `node:vm`. So its modules are really second class citizens that have to be glued to the native module system.
This library used to do that, but moved to using Node's native module hooks, so that there's nothing magical going on, and you can still use the `import` expression to import your HMR modules, they just auto-update when saving.
For this to be genuinely useful, I’d expect at least a few code examples—and ideally a link to a working repo to show it in action.