solid-js types: index.d.ts re-exports createErrorBoundary, createLoadingBoundary and createRevealOrder, which hydration.d.ts strips as @internal #3709

Version: solid-js 2.0.0-rc.9 through 2.0.0-rc.11 (published types). packages/solid/src/index.ts on next (0bf5758) is unchanged.

Summary

packages/solid/src/index.ts re-exports createErrorBoundary, createLoadingBoundary and createRevealOrder from ./client/hydration.js. In client/hydration.ts all three are tagged @internal, so the declaration build strips them from types/client/hydration.d.ts, while types/index.d.ts still names them:

// types/index.d.ts (rc.11), line 8
export { sharedConfig, enableHydration, createRoot, createErrorBoundary, createLoadingBoundary, createRevealOrder, createMemo, ... } from "./client/hydration.js";

types/client/hydration.d.ts declares none of the three. The runtime is fine: dist/solid.js exports all three.

Effect for a consumer

• skipLibCheck: false: the package's own index.d.ts fails with TS2305 ("./client/hydration.js" has no exported member createErrorBoundary, and the same for the other two).
• skipLibCheck: true (the common setting): import { createErrorBoundary } from "solid-js" resolves to any without a diagnostic. A fallback such as (error, reset) => ... loses its contextual types (TS7006 under noImplicitAny), and the boundary's return type is any. That is how we noticed: a renderer that type-checked against rc.8 started failing on rc.9 at the fallback's parameters.

Repro

curl -sL https://registry.npmjs.org/solid-js/-/solid-js-2.0.0-rc.11.tgz | tar xz
grep -c createErrorBoundary package/types/index.d.ts package/types/client/hydration.d.ts
# package/types/index.d.ts:1
# package/types/client/hydration.d.ts:0

(createLoadingBoundary and createRevealOrder give the same result.)

Suggested fix

index.ts already has the pattern for this, a few lines below the list:

/** @internal */
export { materializeContainerTrace } from "./client/hydration.js";

and materializeContainerTrace is correctly absent from the published index.d.ts. Moving the three names out of the public list into that block (or a sibling /** @internal */ export { ... }) strips them from index.d.ts too, which matches their @internal status, and keeps the runtime exports for the renderers and tests that use them. No typed consumer can depend on them from solid-js today, since they already fail or resolve to any.

If they are meant to stay public from solid-js instead, the alternative is dropping @internal from the three declarations in hydration.ts.

Our workaround in the meantime: import createErrorBoundary from @solidjs/signals, where it is public and typed.

Platform: any; it is in the published type declarations. Seen with TypeScript 7.0.2.