Very slow Bun runtime startup with @ttsc/unplugin and Typia

[iHaiduk]

Environment

• Bun: 1.3.14
• ttsc: 0.20.0
• @ttsc/unplugin: 0.20.0
• Typia: 13.2.0
• OS: macOS arm64

Problem

Using @ttsc/unplugin/bun as a Bun runtime plugin causes a very slow initial startup.

The application is a regular TypeScript application using Typia-generated validators.

Example runtime registration:

import typiaPlugin from "@ttsc/unplugin/bun";
import { plugin } from "bun";

plugin(typiaPlugin());

The application is started directly from a TypeScript entrypoint:

bun ./src/main.ts

On a cold process start, the first application log line may appear only after 1–5 minutes.

The same application starts almost immediately when running a prebuilt JavaScript bundle.

Disabling the Typia transform also starts quickly, but the application then fails because Typia requires its compile-time transformation.

Expected behavior

The Bun runtime plugin should provide one of the following:

1. Transform only files required by the entrypoint.
2. Reuse persistent or incremental compiler state.
3. Provide a documented resident compiler or cache mode for development.

A normal development startup should complete within a few seconds without disabling Typia transformations.

Actual behavior

The first runtime import appears to trigger a project-wide TypeScript transformation.

The transformation is repeated after every process restart. The cache appears to be process-local, so it does not help when the development server is restarted.

Minimal reproduction

preload.ts:

import typiaPlugin from "@ttsc/unplugin/bun";
import { plugin } from "bun";

plugin(typiaPlugin());

bunfig.toml:

preload = ["./preload.ts"]

Start the application:

bun ./src/main.ts

Example Typia usage:

import typia from "typia";

export const validate = typia.createValidate<{ id: string }>();

Additional observations

• Native Bun TypeScript startup without the Typia transform is fast.
• A prebuilt bundle starts fast.
• The delay occurs before application bootstrap code executes.
• A resident TtscService was also tested, but it still compiled the full configured project.
• A narrow tsconfig did not clearly limit the resident compilation scope.

Questions

1. Is project-wide compilation expected for @ttsc/unplugin/bun in runtime mode?
2. Is there a supported way to use a persistent resident compiler for Bun runtime loading?
3. Can the runtime adapter use incremental per-file transformation instead of a full project transform?
4. Can the project input set be restricted reliably to the entrypoint dependency graph?
5. Is there a recommended development workflow for Bun and Typia that avoids multi-minute cold starts while preserving transformations?

Thank you.

[samchon]

Thanks for report. I will investigate it.

[samchon]

Thank you again for the precise report. I reproduced this with the reported package versions and then separated the startup into its two independent costs.

What is happening

Project-wide compilation is currently expected for checker-backed ttsc plugins. Typia validators can depend on types, declarations, configuration, and plugin state outside the one source file Bun is loading, so the adapter cannot safely replace that compile with a syntax-only per-file transform.

The multi-minute behavior is not all required work, though. There are two distinct stages:

1. A Go source plugin is compiled once into ttsc's persistent plugin cache. On an empty ttsc cache this can be expensive. With exact ttsc@0.20.0, @ttsc/unplugin@0.20.0, and typia@13.2.0, the first 100-module run exceeded 304 seconds before the first application log. The plugin binary appeared after roughly four minutes.
2. After that binary is warm, the Unplugin cache has a retained O(N²) validation defect. Every Bun module load walks the project tree, synchronously reads the files, and hashes the whole input set again before returning one already-compiled module.

The second stage is a ttsc defect, not required Typia work.

Exact-version measurements

I used the official Bun 1.3.14 Windows x64 archive with its release SHA-256 verified, the exact public 0.20.0 packages, Typia 13.2.0, isolated Bun/ttsc/Go caches, and generated projects with fixed configuration.

After the Typia plugin binary was already cached:

Modules	Graph	Time to first application log
100	chain	4.56 s
400	chain	31.73 s
800	chain	103.74 s

The 800-module warm run made 732,246 synchronous reads, read 568.3 MB, and spent 35.88 seconds inside synchronous reads. This reproduces a minute-scale startup without including the one-time source-plugin build.

I repeated the control with the first-party @ttsc/banner Go plugin instead of Typia:

Modules	Time	Synchronous reads
100	3.72 s	15,489
400	29.31 s	167,289

The same superlinear growth occurs without Typia. I also tested exact public 0.20.1 with Typia 13.2.0. A warm 400-module chain still took 36.20 seconds and made 208,245 synchronous reads. Upgrading from 0.20.0 to 0.20.1 alone does not fix this report.

Cold source-plugin build

With a warm Go build cache but an empty ttsc plugin cache, ttsc prepare on the exact 0.20.0 reproduction took 47.10 seconds. Starting the one-module Bun application with that prepared cache then took 1.37 seconds. The compiled plugin cache key and binary modification time remained stable across later process restarts.

That gives a useful immediate workflow:

ttsc prepare
bun ./src/main.ts

ttsc prepare moves the persistent source-plugin build out of application bootstrap. It does not fix the per-module project validation, so larger projects still need the code correction.

Answers to the questions

1. One project compile is expected today. Re-reading and hashing the whole project for every later module in the same generation is not.
2. TtscService is process-resident and still needs the first project compile. It does not help after a process restart and does not remove this adapter cache defect.
3. A general per-file Typia transform is not sound because the transform is checker-backed. The correct short-term invariant is one coherent project transform followed by constant-time first delivery of each cached module.
4. A narrower tsconfig excludes unrelated included files, but imports and project references correctly expand the Program again. It cannot force an entrypoint-only graph when the transform needs those types.
5. Until the fix is released, pre-run ttsc prepare, keep the transform tsconfig free of genuinely unrelated files, and avoid clearing the ttsc plugin cache between starts.

Ownership and follow-up

This reopens the uncompleted Bug A from #252. Its closing change fixed the separate cache-key mismatch, but the issue body also reported the full-project re-hash on every cache hit and that part remains in 0.20.1.

The broader audit also found three adjacent Unplugin defects:

• fix(unplugin): track compiler inputs reached through filesystem links #975 tracks graph inputs reached through symlinks or Windows junctions that currently escape both cache hash sets.
• fix(unplugin): preserve Bun loader composition and build cache boundaries #976 tracks Bun loader composition and Bun.build cache-boundary handling.
• fix(unplugin): preserve newer cache generations during stale validation #978 tracks a stale cache caller that can delete a newer generation.

I have not opened an issue against Typia. The first-party Banner control proves Typia is not required for the dominant warm-start failure, and I found no Typia-specific wrong output, unstable cache key, or repeated plugin-binary build. If implementation testing produces contrary evidence, I will isolate it and report it to Typia with its own reproduction.

I am keeping this issue open as the reporter-facing acceptance record while implementing the verified class in one campaign pull request.

[samchon]

Thank you again for the detailed report and for including the exact Bun, ttsc, Unplugin, and Typia versions. The correction has now been merged in #980 and published in ttsc@0.21.0 / @ttsc/unplugin@0.21.0.

Final root-cause determination

The reported delay contained two independent costs.

First, Typia is a checker-backed source plugin. Its transformations can depend on project-wide types and declarations, so one coherent project compilation is required; replacing that with isolated per-file syntax transforms would be unsound. On a completely empty ttsc plugin cache, ttsc must also build Typia's Go source plugin once.

Second, and more importantly for repeated warm starts, the Unplugin project cache was validating that already-compiled generation incorrectly. Before returning the first result for each sibling module, it walked and synchronously hashed the complete project again. A project with N modules therefore paid roughly N complete project validations after the single required compile.

The exact reported public versions reproduced both stages:

• ttsc@0.20.0
• @ttsc/unplugin@0.20.0
• typia@13.2.0
• Bun 1.3.14

With the Typia plugin binary already cached, the warm chain measurements were:

Modules	Before 0.21.0	Synchronous reads
100	4.56 s	—
400	31.73 s	208,646
800	103.74 s	732,246

The 800-module run synchronously read 568.3 MB and spent 35.88 seconds inside those reads. Replacing Typia with the first-party Banner plugin still took 29.31 seconds and 167,289 synchronous reads at 400 modules. That control is decisive: Typia was not necessary to reproduce the cache-complexity defect, so this is owned by ttsc/Unplugin rather than Typia.

I also checked public 0.20.1; a warm 400-module Typia control still took 36.20 seconds and made 208,245 synchronous reads. This was not already fixed by that release.

What changed

The cache now distinguishes a real per-build or per-runtime-session generation from a lifecycle-less persistent cache:

• one checker-backed project compile is still shared across all modules in the generation;
• the first delivery of each compiled module compares Bun's supplied source with that module's generation snapshot in constant time;
• repeated delivery performs complete validation so dependency-only edits remain detectable;
• hosts without a trustworthy build boundary retain full validation on every cache hit;
• Bun runtime setup defines one immutable module-loading session, while Bun.build forwards each available onStart boundary;
• stale, rejected, or mismatching generations can no longer delete a newer authoritative generation installed by another caller;
• linked graph inputs, including symlinks and Windows junctions, remain part of freshness validation; and
• excluded files, no-op transforms, virtual ids, and Bun in-memory files retain the correct loader owner.

The corrected warm Typia controls completed in 10.802 seconds at 400 modules and 33.892 seconds at 800 modules. The remaining growth is the real one-time checker-backed project compile and Bun module loading, not a complete project re-hash multiplied by every module.

Cold source-plugin preparation

The persistent Go plugin build is separate from the warm-cache defect. With exact 0.20.0, a warm Go build cache, and an empty ttsc plugin cache, an explicit preparation took 47.10 seconds; the subsequent one-module Bun start took 1.37 seconds and did not rebuild the plugin binary.

For development or deployment environments where startup latency matters, prepare source plugins before starting the application:

pnpm add -D ttsc@0.21.0 @ttsc/unplugin@0.21.0
pnpm exec ttsc prepare

The normal Bun runtime registration remains valid:

import typiaPlugin from "@ttsc/unplugin/bun";
import { plugin } from "bun";

plugin(typiaPlugin());

Verification and ownership

The complete Unplugin feature suite, exact Bun 1.3.14 loader/build controls, the Metro cache suite, repository typecheck, changed-file formatting, five full review rounds, and a renewed discovery pass were completed before merge. The 0.21.0 release then built every platform package, published to npm, and smoke-installed the released WASM and VS Code packages successfully.

No Typia issue has been filed because the evidence does not establish a Typia defect. Typia's transformed output, archive integrity, and persistent plugin cache all passed their controls, and the first-party Banner plugin reproduced the dominant warm behavior. Filing this against Typia would assign the defect to the wrong owner.

Release: https://github.com/samchon/ttsc/releases/tag/v0.21.0