Split runtime helpers out of compiler packages

[aleclarson]

Summary

TSRX compiler packages currently include runtime helper code that component libraries may need at runtime. This means libraries authored with TSRX can end up depending on relatively large compiler packages even when consumers only need a small renderer-specific helper layer.

I’d like to propose splitting those runtime helpers into dedicated runtime packages.

Motivation

Component libraries using TSRX can currently pull in compiler package dependencies for runtime helper imports. That considerably increases install size for downstream users.

For example, @tsrx/react currently has an install size of about 3.2 MB. Around 97% of that comes from @tsrx/core, which accounts for about 3.1 MB of the install size. @tsrx/core should not be bundled into applications when it is not imported by runtime code, so this is not primarily a bundle-size concern. However, it still has to be downloaded, linked, and stored on disk when it is pulled in as a production dependency of a TSRX-authored component library.

Since @tsrx/core is not needed by the runtime helpers themselves, that install cost does not buy much for application consumers. It slows down installs and increases disk usage without providing runtime value.

Proposal

Create renderer-specific runtime helper packages, for example:

@tsrx/react-lib

The name is inspired by tslib: a compact runtime helper package used by compiled output, distinct from the compiler itself.

Other renderers could follow the same convention:

@tsrx/solid-lib
@tsrx/preact-lib
@tsrx/ripple-lib

The compiler packages would emit imports from these helper packages where appropriate, while keeping the compiler implementation and transforms in the existing compiler packages.

Compiler packages may also want to re-export their corresponding runtime helper package through subpath exports. This keeps application installs simple: an app that already depends on @tsrx/react for compilation should not also need to install @tsrx/react-lib just because compiled output imports runtime helpers.

Libraries could then opt into direct runtime-helper imports with a compiler flag. When enabled, compiled output would import helpers directly from the *-lib packages, such as @tsrx/react-lib, instead of importing them through compiler package subpaths. This would let published component libraries avoid a production dependency on the heavier compiler package while applications can continue using the compiler package alone.

Benefits

• Smaller production installs for apps that consume TSRX-authored component libraries
• Published libraries can depend on @tsrx/react-lib instead of the heavier @tsrx/react package
• Apps that compile TSRX can keep installing just @tsrx/react, with helper imports handled through subpath re-exports
• The split between compiler code and runtime helper code becomes easier to understand
• Renderer helper package names follow a familiar tslib-style convention

[leonidaz]

this shouldn't happen for runtime as we only pull in very specific namespaces for runtime, e.g. @tsrx/react/runtime/iterable or @tsrx/react/error-boundary

Do you see @tsrx/core compiler stuff in production builds?

[aleclarson]

Since @tsrx/core is not needed by the runtime helpers themselves, that install cost does not buy much for application consumers. It slows down installs and increases disk usage without providing runtime value.

@leonidaz This is the issue. The same reason tslib exists.

[leonidaz]

ah, i see, the installation, yeah everything would have to be installed.

I suppose we should. I suggest we name them with a -runtime suffix, e.g. @tsrx/react-runtime for clarity.