upgrading from 0.19 to 0.20 build never completes

[khera]

I upgraded typia from 13.1.1 to 13.2.0, ttsc and @ttsc/unplugin from 0.19.2 to 0.20.0. The build step never completes (it has been running 30 minutes and I finally killed it). Node version v26.5.0.

I tried upgrading just typia or just ttsc suite independently. They both result in the forever build. For now I'm sticking with the 0.19 unplugin, and the 13.1.1 typia.

npm install ttsc@latest @ttsc/unplugin@latest @ttsc/graph@latest typia@latest
 [ .. output skipped ]

[lappy]% npm run typecheck
npm notice run makemedia-app@1.8.24 typecheck
npm notice run react-router typegen && ttsc --noEmit
ttsc: building source plugin "typia" from /Users/vivek/Work/makemedia/makemedia-app/node_modules/typia/native/cmd/ttsc-typia (this runs once per cache key and can take several minutes on a cold Go cache) See https://ttsc.dev/docs/ttsc/compile#plugin-cache to persist it across builds.
[lappy]% npm run typecheck
npm notice run makemedia-app@1.8.24 typecheck
npm notice run react-router typegen && ttsc --noEmit
[lappy]% npm run build
npm notice run makemedia-app@1.8.24 build
npm notice run react-router build
Using Vite Environment API
vite v8.1.5 building client environment for production...
load: 5.31  cmd: node 20489 running 1.13u 1.25s
load: 5.44  cmd: node 20489 running 100.66u 377.74s
load: 6.03  cmd: node 20489 running 128.87u 484.31s
load: 5.39  cmd: node 20489 running 166.09u 619.48s
load: 4.55  cmd: node 20489 running 185.90u 689.69s
load: 5.99  cmd: node 20489 running 237.74u 882.93s
load: 4.75  cmd: node 20489 running 253.44u 942.37s
load: 6.93  cmd: node 20489 running 307.98u 1141.14s
load: 7.06  cmd: node 20489 running 349.43u 1295.37s
load: 5.95  cmd: node 20489 running 406.98u 1515.07s
^Cload: 4.48  cmd: node 20489 running 437.71u 1632.87s
load: 5.53  cmd: node 20489 running 501.91u 1869.50s
^\zsh: quit       npm run build
[lappy]%

the "load" lines are from the "status" signal sent from the shell via CTRL-T on macOS. The "s" number is system CPU seconds consumed, not total time but in this case they are basically equal. Note that sending a regular kill CTRL-C did not stop it, I had to hard kill it with a quit signal.

As you can see, the first run of the type check ran the build on typia. The second run completed almost instantly, and shows that the cache was used. When the build step runs it doesn't seem like it will ever finish. I'm on a MacBook Air M2.

I also deleted node_modules and ran it again. It looks like it is stuck the same way again.

[khera]

Apologies, it seems upgrading the ttsc suite was silently upgrading typia also. Manually rolling back typia to 13.1.1 builds fine with ttsc 0.20.0. Curiously, using Typia 13.1.19 also never completes.

[samchon]

Thanks for report. I will investigate it.

[samchon]

Thank you for the detailed report, especially the correction about Typia 13.1.1 versus 13.1.19 and the macOS CTRL-T samples. I reproduced the affected production-build path and traced the version boundary. This is fixed in ttsc@0.21.0 and @ttsc/unplugin@0.21.0; no further code change is required for this issue.

The fast second ttsc --noEmit run proved that the compiled Typia source-plugin binary was cached. It did not exercise the same work as Vite's source-transform path, so it could not rule out a warm Unplugin problem.

The Typia observation was also real. The only public npm releases in the relevant 13.1 range are 13.1.0, 13.1.1, and 13.1.19. Typia 13.1.19 was therefore the first public release after 13.1.1 to include the consulted-declaration dependency producer from samchon/typia#2100. That change reports the files whose type declarations were used to generate each validator, fixing stale validators in persistent bundler caches. It is required for correctness.

The defect was in the Unplugin cache validation around that legitimate dependency graph. A Vite production build asks the plugin for many modules. The 0.20 cache compiled the project once, but then rescanned and rehashed the complete project and external input set before returning each module from that already-computed generation. For M delivered modules and P project inputs, the warm path performed approximately M × P filesystem work. The synchronous filesystem operations also explain why the process accumulated system CPU time and did not react promptly to CTRL-C.

The fix in #980 gives a real bundler build one transform generation. Each module's first delivery compares its supplied source with the generation snapshot in constant time. Repeated delivery and hosts without a reliable build boundary still receive complete validation, so the performance correction does not weaken cache freshness.

I tested the exact public vite@8.1.5, typescript@7.0.2, Typia 13.1.1/13.1.19/13.2.0, and ttsc/Unplugin 0.20.0/0.21.0 packages. I also downloaded the official Node v26.5.0 Windows distribution and verified its archive against Node's published SHA-256 before using it.

On a fixed 120-module project with 30 Typia validators, warm Node v26.5.0 Vite builds took a median 9.98 seconds with ttsc/Unplugin 0.20.0 and 3.86 seconds with 0.21.0. The generated bundles were identical after normalizing pnpm's versioned source-path comments, contained all generated validators, and contained no remaining typia.createValidate call.

I then used a dependency-rich control with 120 application modules, 50 chained type-declaration files, and 30 validators. Typia 13.1.19 correctly reported 1,590 dependency edges, with 53 dependencies for each validator-bearing file. Direct project transformation remained bounded in the same range as 13.1.1, about 2.1 to 3.7 seconds. The Vite medians were:

Typia	ttsc/Unplugin 0.20.0	ttsc/Unplugin 0.21.0
13.1.1	4.43 s	2.05 s
13.1.19	6.65 s	2.60 s

This reproduces both parts of the report: 13.1.19 makes the previously missing dependency surface visible, and 0.20 amplifies that larger correct surface during per-module cache reuse. A CPU profile of the 0.20 Vite path placed synchronous file open/read/close/stat operations and collectProjectInputHashes at the top; the 0.21 profile removed that repeated project-hash path.

I also tested ttsc/Unplugin 0.19.2 with Typia 13.1.19. It retained the older complete-validation cost and took about 7 to 9 seconds on the same controls. The problem was therefore not a new Typia infinite loop introduced by 0.20. It was a latent Unplugin cache-scaling defect that became severe enough to surface when Typia began reporting the dependency information required for correct bundler invalidation.

Please upgrade the installed ttsc packages together and prepare the source-plugin cache once:

npm install -D ttsc@0.21.0 @ttsc/unplugin@0.21.0 @ttsc/graph@0.21.0
npx ttsc prepare

Typia 13.1.19 and 13.2.0 are both valid with this fix. I am not opening a Typia issue because the isolated Typia transform completed normally, its dependency output was correct, and a plugin-independent control already reproduced the dominant Unplugin cache defect in #980. If the private application still fails to complete after upgrading both ttsc packages to 0.21.0, please comment with npm ls ttsc @ttsc/unplugin @ttsc/graph typia vite typescript; I will treat that as a separate remaining reproduction rather than assuming it has the same cause.

[khera]

Thank you so much for looking into this.

I upgraded the ttsc modules to 0.21.0 as directed, and was able to build my app. I then upgraded Typia to 13.2.0 and the build stalled again. I let it run for ~5 minutes before killing it:

[lappy]% npm run build
npm notice run makemedia-app@1.8.25 build
npm notice run react-router build
Using Vite Environment API
vite v8.1.5 building client environment for production...
load: 30.45  cmd: node 7602 running 11.50u 21.45s
load: 29.94  cmd: node 7602 running 17.68u 32.91s
load: 27.85  cmd: node 7602 running 49.47u 92.33s
load: 26.64  cmd: node 7602 running 62.82u 118.09s
load: 20.68  cmd: node 7602 running 73.05u 137.22s
^C^\zsh: quit       npm run build
[lappy]% kill -9 7602

Restoring Typia 13.1.1 lets the build complete in about 30 seconds.

[lappy]% npm ls ttsc @ttsc/unplugin @ttsc/graph typia vite typescript
makemedia-app@1.8.25 /Users/vivek/Work/makemedia/makemedia-app
├─┬ @mdxeditor/editor@4.1.0
│ ├─┬ @lexical/clipboard@0.48.0
│ │ ├─┬ @lexical/html@0.48.0
│ │ │ └── typescript@7.0.2 deduped
│ │ ├─┬ @lexical/internal@0.48.0
│ │ │ └── typescript@7.0.2 deduped
│ │ └── typescript@7.0.2 deduped
│ ├─┬ @lexical/extension@0.48.0
│ │ └── typescript@7.0.2 deduped
│ ├─┬ @lexical/history@0.48.0
│ │ └── typescript@7.0.2 deduped
│ ├─┬ @lexical/link@0.48.0
│ │ └── typescript@7.0.2 deduped
│ ├─┬ @lexical/list@0.48.0
│ │ └── typescript@7.0.2 deduped
│ ├─┬ @lexical/markdown@0.48.0
│ │ ├─┬ @lexical/code-core@0.48.0
│ │ │ └── typescript@7.0.2 deduped
│ │ ├─┬ @lexical/text@0.48.0
│ │ │ └── typescript@7.0.2 deduped
│ │ └── typescript@7.0.2 deduped
│ ├─┬ @lexical/plain-text@0.48.0
│ │ ├─┬ @lexical/dragon@0.48.0
│ │ │ └── typescript@7.0.2 deduped
│ │ └── typescript@7.0.2 deduped
│ ├─┬ @lexical/react@0.48.0
│ │ ├─┬ @lexical/a11y@0.48.0
│ │ │ └── typescript@7.0.2 deduped
│ │ ├─┬ @lexical/devtools-core@0.48.0
│ │ │ └── typescript@7.0.2 deduped
│ │ ├─┬ @lexical/hashtag@0.48.0
│ │ │ └── typescript@7.0.2 deduped
│ │ ├─┬ @lexical/mark@0.48.0
│ │ │ └── typescript@7.0.2 deduped
│ │ ├─┬ @lexical/overflow@0.48.0
│ │ │ └── typescript@7.0.2 deduped
│ │ ├─┬ @lexical/table@0.48.0
│ │ │ └── typescript@7.0.2 deduped
│ │ ├─┬ @lexical/yjs@0.48.0
│ │ │ └── typescript@7.0.2 deduped
│ │ └── typescript@7.0.2 deduped
│ ├─┬ @lexical/rich-text@0.48.0
│ │ └── typescript@7.0.2 deduped
│ ├─┬ @lexical/selection@0.48.0
│ │ └── typescript@7.0.2 deduped
│ ├─┬ @lexical/utils@0.48.0
│ │ └── typescript@7.0.2 deduped
│ └─┬ lexical@0.48.0
│   └── typescript@7.0.2 deduped
├─┬ @react-router/dev@8.3.0
│ ├── typescript@7.0.2 deduped
│ ├─┬ valibot@1.4.2
│ │ └── typescript@7.0.2 deduped
│ └── vite@8.1.5 deduped
├─┬ @react-router/node@8.3.0
│ └── typescript@7.0.2 deduped
├─┬ @react-router/remix-routes-option-adapter@8.3.0
│ └── typescript@7.0.2 deduped
├─┬ @react-router/serve@8.3.0
│ └─┬ @react-router/express@8.3.0
│   └── typescript@7.0.2 deduped
├─┬ @ttsc/graph@0.21.0
│ ├── ttsc@0.21.0 deduped
│ └── typia@13.2.0 deduped
├─┬ @ttsc/unplugin@0.21.0
│ └── ttsc@0.21.0 deduped
├─┬ inngest@4.13.0
│ ├─┬ @inngest/ai@0.1.7
│ │ └── typescript@7.0.2 deduped
│ └── typescript@7.0.2 deduped
├── ttsc@0.21.0
├── typescript@7.0.2
├─┬ typia@13.2.0
│ └── ttsc@0.21.0 deduped
├─┬ vite-plugin-svgr@5.2.0
│ ├─┬ @svgr/core@8.1.0
│ │ └─┬ cosmiconfig@8.3.6
│ │   └── typescript@7.0.2 deduped
│ └── vite@8.1.5 deduped
├── vite@8.1.5
└─┬ vitest@4.1.10
  ├─┬ @vitest/mocker@4.1.10
  │ └── vite@8.1.5 deduped
  └── vite@8.1.5 deduped

[samchon]

Confirmed the remaining reproduction — thank you for re-testing, @khera. The 13.1.1-vs-13.2.0 boundary you measured is the envelope shape, not a typia regression: typia >= 13.1.19 stamps a reference graph into the transform envelope, and @ttsc/unplugin re-walks that whole graph on every cached module delivery to derive watch inputs (O(modules x edges), plus two real syscalls per path on macOS, which matches your CTRL-T samples showing system CPU ~2x user CPU). #980 removed the per-module project revalidation but not this per-delivery derivation, which is why 0.21.0 fixed the synthetic fixtures yet your real app still stalls.

Root cause and reproduction are published as #1007; a fix is in progress there.

[samchon]

Follow-up after the residual reproduction reported here: the remaining hang has now been traced, fixed, regression-tested, and merged in #1009 (05b7e251280d45ab31e4e4b90d6ff61af9263a09).

The earlier fixes addressed distinct watch/cache failure modes, but a graph-bearing typia result still caused @ttsc/unplugin to derive watch inputs separately for every transformed module by rescanning and canonicalizing the complete reference graph. On macOS this repeatedly invoked existsSync/realpathSync.native, so the work scaled as O(module deliveries × graph edges) and could look as though the build would never complete.

The merged fix stores lazy derivation indexes and path-identity memos per result envelope, then derives only the watch inputs relevant to the delivered file. It preserves ordering, deduplication, cycle handling, fallbacks, temporary-tsconfig exclusion, and the existing freshness contract; the envelope-keyed WeakMap also avoids process-global retention.

The regression fixture reproduces the graph-envelope path under simulated Darwin probe accounting. Before the fix, 99 deliveries required roughly 6.7k/12k/22.8k filesystem probes per module as graph size increased and took about 76–95 seconds. After the fix, the same path remains approximately flat at 19 probes per module and about 100 ms. The full PR completed 64/64 GitHub checks, including macOS watch and the Nestia integration, on the final reviewed head.

For clarity, the apparently stalled pnpm release run investigated at the same time was not another manifestation of this bug: run 30161890750 completed successfully in about 35 minutes. Its separate operational weakness—unbounded publish steps/jobs—was fixed as #1008 in the same PR with explicit fail-fast timeouts.

If a current release containing merge commit 05b7e2512 still reproduces the build stall, please provide the exact ttsc/typia versions, platform, invocation, and the smallest available project shape; that would now indicate a separate path rather than the verified full-graph derivation defect.