[PoC] Rewrite nested JSX component paths to direct hoisted exports

[fhammerschmidt]

ReScript currently lowers nested JSX component paths like <Sidebar.Provider> to cross-module member access in generated JS, for example Sidebar.Provider.make. That works in many cases, but it breaks in environments like Next.js Server Components, where nested component member access can end up as undefined at runtime even though direct top-level component bindings work.

This PR changes JSX v4 lowering so nested component modules also emit a hidden direct export for their underlying component function, and transformed JSX runtime calls use that direct export instead of .make member access when available. That keeps existing source syntax and normal exports intact while producing a safer JS shape for server-
component toolchains.

Example before:

JsxRuntime.jsx(Sidebar$Foo.Provider.make, ...)

Example after:

JsxRuntime.jsx(Sidebar$Foo.Sidebar$Foo$Provider, ...)

Justification

The change crosses several compiler layers because the information needed for the rewrite starts in the JSX transform but
is only actionable during JS lowering.

<Sidebar.Provider> is initially just JSX syntax. To compile it to a direct export safely, the compiler needs to:

• recognize that the tag came from a JSX component path, not ordinary value access,
• preserve that distinction while translating the path into lambda,
• emit hidden direct exports for nested component modules,
• and finally rewrite transformed JSX runtime calls to use those exports.

That is why the PR touches:

• JSX transform files, to mark nested JSX component paths and emit hoisted direct exports,
• lambda translation files, to preserve enough path information through lowering,
• and JS compilation files, to rewrite only transformed JSX callsites without affecting ordinary .make access.

So the surface behavior change is small, but the data needed to do it correctly spans multiple stages of the compiler pipeline.

Either way I marked it as a PoC since it might not be the best way to do it.

[pkg-pr-new]

Open in StackBlitz

rescript

npm i https://pkg.pr.new/rescript@8293

@rescript/darwin-arm64

npm i https://pkg.pr.new/@rescript/darwin-arm64@8293

@rescript/darwin-x64

npm i https://pkg.pr.new/@rescript/darwin-x64@8293

@rescript/linux-arm64

npm i https://pkg.pr.new/@rescript/linux-arm64@8293

@rescript/linux-x64

npm i https://pkg.pr.new/@rescript/linux-x64@8293

@rescript/runtime

npm i https://pkg.pr.new/@rescript/runtime@8293

@rescript/win32-x64

npm i https://pkg.pr.new/@rescript/win32-x64@8293

commit: 104c7ff

[tsnobip]

unfortunately I can't test this PR yet because it messes up imports, let's say I use .res.mjs as output suffix, it should generate import like this:

import * as Button$RescriptShadcn from "../registry/base/ui/Button.res.mjs";
import * as Stdlib_JsExn from "@rescript/runtime/lib/es6/Stdlib_JsExn.js";

but instead, it doesn't use .js for runtime but .mjs:

import * as Stdlib_JsExn from "@rescript/runtime/lib/es6/Stdlib_JsExn.js";
import * as Stdlib_JsExn from "@rescript/runtime/lib/es6/Stdlib_JsExn.mjs";

weird that it doesn't get detected by some tests btw!

[tsnobip]

I found another bug around namespace.
If namespace is disabled, it will generate the following correct code:

JsxRuntime.jsx(Sidebar.Sidebar$Provider, ...)

but if I enable namespace, it generates this:

JsxRuntime.jsx(Sidebar$RescriptShadcn.Sidebar$RescriptShadcn$Provider, ...)

while it should be:

JsxRuntime.jsx(Sidebar$RescriptShadcn.Sidebar$Provider, ...)

the sub component should not be namespaced.