@ttsc/unplugin 0.28.3 → 0.28.5

package/README.md

@@ -118,11 +118,13 @@ const nextConfig = {
 export default withTtsc(nextConfig);
 ```
 
-`withTtsc` covers Next.js builds that go through webpack. When Next.js runs on Turbopack (`next dev --turbopack`), wire the Turbopack loader rules below instead.
+`withTtsc` covers both of Next.js's bundlers. It injects the webpack plugin and wires the Turbopack loader rules, with the options you pass reaching both, so the same config works whether Next runs on Turbopack (the default in current majors) or on webpack. Your own `webpack` hook and `turbopack` block are preserved: unrelated rules and settings survive, and a rule you already wired for this loader by hand is left alone rather than registered twice.
+
+That last part is decided by exact spelling. `withTtsc` declines to add its own rule when your glob is one it has measured against a real Turbopack build as naming every file with the extension — `*.ts`, `**/*.ts`, `{**/,}*.ts`, `*.tsx`, `**/*.tsx`, `*.{ts,tsx}`, `{*.ts,*.tsx}`, `**/*.{ts,tsx}`, `**/{*.ts,*.tsx}`, `**/**/*.{ts,tsx}`. Any other spelling keeps your rule and gains ours beside it, so a module may be transformed twice rather than not at all. The list is exact on purpose: treating an unmeasured glob as project-wide once left every module in a project with no `ttsc` rule at all, and a build that transforms twice is recoverable in a way a build that never transforms is not.
 
 ### Turbopack
 
-Turbopack has no JS plugin API, but it runs webpack loaders through `turbopack.rules`, and a ttsc transform is exactly loader-shaped (TypeScript source in, transformed source out). `@ttsc/unplugin/turbopack` is that standalone loader:
+Turbopack has no JS plugin API, but it runs webpack loaders through `turbopack.rules`, and a ttsc transform is exactly loader-shaped (TypeScript source in, transformed source out). `@ttsc/unplugin/turbopack` is that standalone loader. In a Next.js project `withTtsc` wires it for you; wire it directly when Turbopack runs outside Next, or when you want the rules under your own control:
 
 ```js
 // next.config.mjs
@@ -138,7 +140,7 @@ const nextConfig = {
 export default nextConfig;
 ```
 
-Pass options through the rule's `options` object: `{ loader: "@ttsc/unplugin/turbopack", options: { project: "tsconfig.build.json" } }`. The loader keeps a per-worker compiler cache (Turbopack runs loaders in a worker pool) and returns the source unchanged for declaration files, `node_modules` paths, and transforms that produce no change.
+Pass options through the rule's `options` object: `{ loader: "@ttsc/unplugin/turbopack", options: { project: "tsconfig.build.json" } }`. The loader keeps a per-worker compiler cache (Turbopack runs loaders in a worker pool) and returns the source unchanged for everything the adapters' shared filter excludes (declaration files, `node_modules` paths, non-TypeScript sources, and virtual ids) and for transforms that produce no change.
 
 ### Farm
 
@@ -165,6 +167,22 @@ await Bun.build({
 });
 ```
 
+For `bun run` and `bun test`, where there is no bundling step, register the same transform on Bun's module loader through `@ttsc/unplugin/bun-register`. Preload it once in `bunfig.toml`:
+
+```toml
+preload = ["@ttsc/unplugin/bun-register"]
+```
+
+Or register it imperatively, optionally with options:
+
+```ts
+import register from "@ttsc/unplugin/bun-register";
+
+register({ project: "tsconfig.build.json" });
+```
+
+Importing the module registers it, so a bare `import "@ttsc/unplugin/bun-register"` is enough when the defaults are right. Registration is idempotent: a later explicit call updates the options rather than installing a second loader, because Bun uses the first matching `onLoad` hook and never falls through to an overlapping one.
+
 Under `Bun.build`, the adapter yields to the next loader for declarations, `node_modules`, source that `ttsc` leaves unchanged, and entries supplied through `Bun.build({ files })`. In-memory entries remain with Bun because ttsc transforms filesystem-backed project inputs. Bun's runtime `onLoad` contract does not accept an undefined result, so `Bun.plugin()` explicitly passes excluded and unchanged filesystem files through with their original source. `Bun.build` clears the project generation through its `onStart` lifecycle on every build. The runtime API has no corresponding hook, so one setup is treated as one immutable module-loading session: restart the Bun process after changing source, tsconfig, or plugin inputs.
 
 ## Configuration
@@ -283,9 +301,15 @@ Supported entrypoints are:
 - `@ttsc/unplugin/farm`
 - `@ttsc/unplugin/next`
 - `@ttsc/unplugin/bun`
+- `@ttsc/unplugin/bun-register`
+- `@ttsc/unplugin/api`
 
 Each entrypoint supports ESM import and CJS require. In CommonJS configs, read the default export from `require("@ttsc/unplugin/vite").default`. `@ttsc/unplugin/turbopack` is not an unplugin factory but a standalone webpack loader; reference it by module name inside `turbopack.rules` instead of calling it.
 
+`@ttsc/unplugin/bun-register` is the Bun **runtime** entry rather than a bundler adapter, covered under [Bun](#bun) above. `@ttsc/unplugin/api` exposes the transform core itself (`transformTtsc`, `resolveOptions`, the cache lifecycle) for hosts that are not unplugin-shaped; `@ttsc/metro` is built on it.
+
+That entry point also exposes the project-membership rule — `readProjectMembershipPolicy`, `mergeMembershipPolicyOverlay`, `ITtscProjectMembershipPolicy`, `isProjectWalkPath` and the input-hash collectors — which decides which files can enter the compiled program and therefore which changes invalidate a cached compile. These exist so a host that keeps its own cache asks that question exactly the way the transform core asks it: `@ttsc/metro` folds them into Metro's static transformer key, and the two halves disagreeing about one project is the bug class they exist to prevent. They are shaped for that use rather than as a general-purpose configuration reader, and they move with the core rather than under a stability guarantee of their own. Build a host on them if you need it; pin your `@ttsc/unplugin` version if you do.
+
 ### Options
 
 ```ts
@@ -304,17 +328,55 @@ const options: TtscUnpluginOptions = {
 - `compilerOptions`: temporary override layered on the selected project config.
 - `plugins`: direct `ttsc` plugin list override, or `false` to disable plugins.
 
+#### Path Aliases
+
+Under Vite, the adapter reads the resolved `resolve.alias` and layers it onto the generated config, so an alias declared only in `vite.config.ts` still resolves during the compile. No other host's alias configuration is read: under Rollup, Rolldown, webpack, Rspack, esbuild, Farm, Turbopack and Bun, the compile resolves through the tsconfig's own `paths` alone. Declare an alias in `paths` when a module has to resolve for the compiler as well as for the bundler, which is what those hosts need anyway for `tsc` to type-check the same imports.
+
+Not every Vite alias form can be forwarded, because a tsconfig `paths` map cannot express all of them:
+
+| `resolve.alias` form | Forwarded |
+| --- | --- |
+| `{ "@": "/src" }`, or the array form with a string `find` | yes |
+| array form with a `RegExp` `find`, such as `{ find: /^~/ }` | no — `paths` has no regular-expression form |
+| a string `find` containing `*` | no — a `paths` key already reads `*` as its own wildcard |
+
+In both unforwarded cases the compile resolves that specifier through the tsconfig's `paths` alone, so declare it there if `ttsc` must resolve through it — a prefix `RegExp` such as `/^~/` is written as a `"~/*"` entry. Reducing simple prefix patterns automatically is deliberately not attempted: distinguishing `/^~/` from `/^@app/`, which also matches `@apple`, needs enough of a regular-expression engine that a wrong reduction becomes likely, and a mistranslated alias resolves imports to the wrong file without saying so.
+
+A `find` containing `*` is also reported once on stderr, naming the alias and the reason. A `RegExp` `find` is not, and the asymmetry is deliberate: Vite merges two `RegExp` aliases of its own into every resolved config, for `@vite/env` and `@vite/client`, so a report on that form would fire in every build of every project and name aliases you never wrote.
+
 ### Cache and Watch Invalidation
 
-The transform graph also records module-resolution candidates that would outrank a selected target, plus the selected lexical spelling when the compiler reports its physical symlink or junction target. The adapter registers candidates for importers in the transformed file's reachability closure, so creating or changing a higher-priority probe or retargeting the selected alias invalidates watch and persistent caches without an importer or tsconfig edit.
+Editing a type that only a generated validator depends on invalidates the module, in watch mode, in webpack's filesystem cache and in Turbopack's `fileDependencies`, even though the bundler erased the type-only import from its own graph. The adapter registers each transformed file's reference closure, the global-scope files, the configs and the resolution candidates with the bundler, plus whatever the plugins themselves report. The [setup guide](https://ttsc.dev/docs/setup/unplugin) describes how that set is derived and proven.
+
+One whole-project compile already contains every module's output, so the adapter compiles the project once and serves every module from that one result. Everything below is about when it may keep doing that.
+
+#### When the generation is reused
+
+A host with a build boundary opens a delivery pass there. The pass's first delivery proves the whole generation against the current filesystem once, and after that each module's first delivery in the pass is settled by the supplied source alone. `buildStart` repeats per rebuild under webpack, Rspack, Rollup, Rolldown, esbuild and `vite build --watch`, so a pass boundary means "each module is requested at most once from here", not "the compiled program is stale".
+
+Hosts with no build boundary (Metro workers, the Turbopack loader, and a watching Vite dev server, whose one `buildStart` spans later HMR edits) validate each generation hit against the inputs that can affect the module being asked for: its reference closure, the global-scope files, the configs, the resolution candidates, and the plugin dependencies. Sibling modules share one proof of the closure rather than repeating it per module.
+
+Project membership comes from the resolved configuration rather than from a list of directory names. `allowJs` and `resolveJsonModule` decide which file extensions can enter the program, so a bundle emitted beside your sources is not a membership change for a project that compiles no JavaScript. `outDir`, `declarationDir` and the plain entries of `exclude` name the directories the program does not contain, and those are not walked at all. Everywhere else, a directory takes part in membership only while it can hold a program input, so an output directory no configuration names still costs nothing as long as what it holds is not admissible, and the first source appearing in it is detected because the directory is walked and watched throughout. A project that does admit JavaScript should name its bundler's output directory in `exclude`, since otherwise an emitted `.js` there is a program input like any other. Emptying and recreating a directory the configuration names, which `emptyOutDir` and `output.clean` do on every build, costs nothing either.
+
+#### When it is discarded
+
+An input change or an explicit cache lifecycle reset permits a new generation. Opening a pass is not such a reset.
+
+A compile that failed outright is retained for the rest of that pass, so its remaining modules replay the verdict instead of repeating an identical failing compile once per module, and the next pass attempts it again. A host with no pass boundary keeps evicting a failed compile on every delivery, so a transient toolchain failure never becomes permanent for a long-lived worker.
+
+#### What this changes for you
+
+A module the compiled program does not contain is left untransformed and reported once per pass, naming the file and the tsconfig it is missing from. This is not a build error: the file is simply not this project's to transform, and the usual cause is a bundle graph that reaches further than the tsconfig's `include`. Add it there if ttsc plugins should apply to it.
+
+A file whose transform no plugin can contribute to is validated against the universal inputs and itself rather than its whole reference closure. Its diagnostics narrow with it, so a type error introduced in such a file surfaces at the next compile the build runs for another reason rather than at the edit. Run the compiler's own check beside the bundler when you want type errors at the edit.
 
-The transform host reports the program's reference graph (the transform envelope's `graph` section: per-file direct resolved references with type-only edges included, global-scope files, and the tsconfig `extends` chain — see the [plugin protocol](https://ttsc.dev/docs/development/concepts/protocol#transform)). Per transformed file, the adapter registers the graph's reachability closure, the globals, and the configs with the bundler via `addWatchFile`, so editing a type that only a generated validator depends on invalidates the module — in watch mode, in webpack's filesystem cache, and in Turbopack's `fileDependencies` — even though the bundler erased the type-only import from its own graph.
+A Bun runtime plugin registration is one process-scoped module-loading session, so restart the Bun process after changing source, tsconfig, or plugin inputs.
 
-Transform plugins may additionally report, per file, the source files they consulted (the envelope's `dependencies` field); the adapter registers those as watch files too, union semantics. A plugin that declares such a list [complete](https://ttsc.dev/docs/development/concepts/protocol#dependency-completeness) for a file narrows the registration instead: only its own list plus the tsconfig chain, so files the transform never consulted stop invalidating it. The JavaScript host also reports the descriptor's loaded CommonJS graph, every package manifest inspected by auto-discovery, and plugin-declared `hostInputs`. First-party plugins use that last field for implicit config discovery and evaluated config dependencies. These remain universal without turning arbitrary project assets into configuration. Files a plugin declares `volatile` (output depending on non-file inputs such as environment or time) bypass the adapter's transform cache and are marked uncacheable where the bundler exposes that control.
+A dev server started without a watcher (`server.watch: null`, which is what `vitest --run` configures) takes the pass lifecycle instead of per-delivery validation. Nothing can deliver a change event to such a session, so per-delivery validation there buys incoherence rather than freshness: modules delivered before an edit and after it would come from two different compilations of one program.
 
-The transform cache snapshots every regular file reached by the non-following project walk plus graph-reported inputs outside that walk (`node_modules` declarations, monorepo sibling sources, files reached through symlinks or Windows junctions, and out-of-root `extends` ancestry). One whole-project compile already contains every module's output. Adapters with a guaranteed build boundary clear the previous generation there, then check only the supplied source on each module's first delivery from a complete generation in that build. An incomplete generation never takes that shortcut. Later deliveries of a graph-bearing generation validate that file's reference closure, globals, configs, resolution candidates, plugin dependencies, and exact host inputs. Every input a generation has already proven carries the nanosecond metadata signature captured around the read that proved it, so a later delivery that finds the signature unchanged reuses that proof instead of re-reading the bytes; any signature change falls back to the full content comparison. A signature is recorded only for a read nothing raced, only for an input whose recorded state came from bytes that were read, since the metadata of a path nothing could read holds still while the bytes behind it appear, and only once the observed filesystem's own clock has provably left the tick that minted the input's modification stamp. A filesystem stamps writes once per clock tick, so a same-length rewrite landing inside the recorded stamp's tick would leave the signature unchanged; until some stamp the same filesystem minted later separates that tick, the content comparison keeps running, and the signature is re-earned the moment it can be. The reference instants come from the filesystem itself, never from the process clock: every stamp the adapter observes raises a floor kept per reporting device, and the adapter also stamps a probe in its own scratch directory (the way git separates racily-clean index entries with the index file's own timestamp) to cover a tree whose files were all written inside one tick. The probe counts only when the scratch volume is the inputs' volume, so on a split-volume layout the observed stamps carry the rule alone; an input they cannot separate is re-read rather than trusted. Both sides of every comparison are therefore stamps of equal granularity minted by one clock, so a filesystem clock running behind the host changes nothing. The floor is a maximum over stamps it merely observed, so what defeats it is a stamp that was set into the future rather than minted, such as a stamp-preserving extraction or copy from a machine whose clock ran ahead. A restored past stamp is harmless, since it never raises the floor. A clock that jumps backwards strands the floor above the present the same way, which is a different hazard from a clock running at a constant offset: an offset moves both stamps being compared and changes nothing, while a jump moves only the present. No stamp-based freshness proof survives either one. Sibling modules therefore share one proof of the closure and the globals rather than repeating it per module. Generation-scoped directory notifications detect new, removed, or renamed project inputs without repeating a directory-stat pass per module; Windows isolates those notifications so deletion of a watched temporary tree cannot crash the host. An absent resolution candidate is the one input a metadata signature cannot stand for, since a path that is not there has no metadata to compare. The generation therefore registers those names with a watcher of their own, along with the directory components of the spelling that lead to them, down to the project's own root, and a delivery reads the notification instead of re-probing each candidate. That makes the notification the sole positive evidence for this one input class, which is why the registration reaches past the candidate itself: a watcher opened on a path that traverses a link follows it, so retargeting the link would otherwise move the answer without disturbing what is watched, and a package link inside `node_modules` is exactly that. It stops at the project root, and a candidate whose spelling leaves the project subtree before reaching it is not claimed at all: above that line the components are the machine's own layout rather than the project's, which nobody retargets and which changes for reasons no generation should hear about. It listens for renames alone, since every event that can change a candidate's answer is one — the file appearing, a component being created, replaced or retargeted — while the directories carrying them have their attributes moved by anything written below. A candidate whose watch could not be opened, whose watcher has since failed, or that belongs to a set spanning more directories than the generation will watch, is probed exactly as before: a host that runs out of watch descriptors would fail the tracker outright, which costs every delivery a whole-project comparison rather than one probe. What none of that covers is a filesystem that accepts a watch and then reports nothing, which some network mounts do; that is the same assumption the project-membership proof beside it already rests on, though a wider one here: the project walk skips `node_modules`, so a candidate under it was never covered by that proof and kept a notification-independent probe until now. A project on such a mount should be treated as one where notifications do not work rather than one where they merely have not fired. The barrier that lets a synchronous edit reach those watchers before a delivery reads their verdict is the watcher's own acknowledgement rather than a fixed wait: an in-process watcher answers on the next turn of the loop its callbacks are queued on, and the Windows broker answers by an ordered round-trip, so a delivery waits for the crossing instead of guessing at it. The project is snapshotted before and after compilation, while every graph member carries the compiler filesystem's content and physical-identity proof; only a complete generation that still matches both may authorize narrow reuse. This also rejects an in-project or external A→B→A change whose restored post-compile bytes would otherwise hide the transient state used by the compiler. `dependenciesComplete` narrows file inputs by the same contract as watch registration, and a project reaches it without a type-driven plugin: ttsc's own transform lanes print syntactically, so the host declares every file complete when no plugin can contribute to it, and the first-party `@ttsc/banner` and `@ttsc/strip` declare their own contribution the same way. Such a delivery validates the universal inputs and the file itself instead of its reference closure. A narrowed file's diagnostics narrow with it: an edit to a file the declaration dropped no longer re-runs the compile, so a type error introduced there surfaces at the next compile the build runs for another reason rather than at the edit. Run the compiler's own check beside the bundler when you want it at the edit. Envelopes without a graph, and generations whose watchers could not be opened or have since failed, retain complete-snapshot validation: losing a notification is the absence of a membership proof rather than evidence of a change, so such a generation keeps validating against its own recorded state (the directory snapshot, the input hashes, and the universal descriptor inputs whose every rejection is evidence of a change rather than an inability to prove one) instead of being discarded. A reported membership event is evidence, and still replaces the generation. For a caching host, an unstable or incomplete attempt is never published: all waiters share one bounded stabilization retry inside the same generation. A stable retry alone resolves and is reused; a second unprovable attempt rejects the shared generation with bounded path-and-proof witnesses. That terminal verdict stays cached while its project, external, and host-input fingerprints remain unchanged, so later request waves pay only the confirmation probes and the compile count is independent of module count. An input change or an explicit cache lifecycle reset permits a new generation. One-shot calls without a cache retain their single compile. Bun runtime setup defines one process-scoped loading session. A dev server started without a watcher takes the build-scoped lifecycle instead of persistent validation. `server.watch: null` leaves the session no channel through which a file change could ever reach it, so what per-delivery validation buys there is incoherence rather than freshness: modules delivered before an edit and after it would come from two different compilations of one program. Each module's first delivery in such a session is therefore settled against the generation the session started from, exactly as under a build, while a module the session already delivered keeps revalidating on its next request. Long-lived hosts without either boundary (Metro workers, the Turbopack loader, and a watching Vite development server, whose initial `buildStart` spans later HMR edits) apply the file-specific validation on every generation hit.
+Freshness proofs rest on filesystem timestamps, so two environments need care. A project on a network mount that accepts a watch and then reports nothing should be treated as one where notifications do not work. And a clock that jumps backwards, or a tree restored with stamps set into the future, defeats any stamp-based proof; a clock running at a constant offset does not, since it moves both sides of every comparison.
 
-Transform source outputs outside the project walk are kept in that external snapshot too. A non-declaration output is reusable only when the graph carries its compiler-time content and physical-identity proof; a post-compile disk read cannot prove which bytes produced the output. Its source hash then lets sibling module requests validate the same generation without adding arbitrary output keys to the project-file universe.
+The [setup guide](https://ttsc.dev/docs/setup/unplugin) describes how these proofs are built.
 
 ## Sponsors
 

package/lib/api.js

@@ -2,6 +2,7 @@
 
 var index = require('./core/index.js');
 var transform = require('./core/transform.js');
+var tsconfigPaths = require('./core/tsconfigPaths.js');
 var options = require('./core/options.js');
 
 
@@ -16,5 +17,7 @@ exports.createTtscTransformCache = transform.createTtscTransformCache;
 exports.isProjectWalkPath = transform.isProjectWalkPath;
 exports.resetTtscTransformCache = transform.resetTtscTransformCache;
 exports.transformTtsc = transform.transformTtsc;
+exports.mergeMembershipPolicyOverlay = tsconfigPaths.mergeMembershipPolicyOverlay;
+exports.readProjectMembershipPolicy = tsconfigPaths.readProjectMembershipPolicy;
 exports.resolveOptions = options.resolveOptions;
 //# sourceMappingURL=api.js.map

package/lib/api.js.map

@@ -1 +1 @@
-{"version":3,"file":"api.js","sources":[],"sourcesContent":[],"names":[],"mappings":";;;;;;;;;;;;;;;;;;"}
+{"version":3,"file":"api.js","sources":[],"sourcesContent":[],"names":[],"mappings":";;;;;;;;;;;;;;;;;;;;;"}

package/lib/api.mjs

@@ -1,4 +1,5 @@
 export { isTransformTarget, sourceFilePattern, default as unplugin } from './core/index.mjs';
 export { beginTtscTransformBuild, collectExternalInputHashes, collectProjectInputHashes, createTtscTransformCache, isProjectWalkPath, resetTtscTransformCache, transformTtsc } from './core/transform.mjs';
+export { mergeMembershipPolicyOverlay, readProjectMembershipPolicy } from './core/tsconfigPaths.mjs';
 export { resolveOptions } from './core/options.mjs';
 //# sourceMappingURL=api.mjs.map

package/lib/api.mjs.map

@@ -1 +1 @@
-{"version":3,"file":"api.mjs","sources":[],"sourcesContent":[],"names":[],"mappings":";;"}
+{"version":3,"file":"api.mjs","sources":[],"sourcesContent":[],"names":[],"mappings":";;;"}

package/lib/core/index.d.cts

@@ -3,21 +3,32 @@ import type { TtscUnpluginOptions } from "./options.cjs";
 import { resolveOptions } from "./options.cjs";
 import { beginTtscTransformBuild, collectExternalInputHashes, collectProjectInputHashes, createTtscTransformCache, isProjectWalkPath, resetTtscTransformCache, transformTtsc } from "./transform.cjs";
 /**
- * Matches any TypeScript or JavaScript source extension (.ts, .tsx, .mts, .cts,
- * etc.). Shared with the Bun adapter (`bun.ts`) so the filter is defined once
- * and both adapters stay in sync.
+ * Matches the TypeScript source extensions the ttsc transform handles: `.ts`,
+ * `.tsx`, `.mts`, `.cts` and their `x` forms. JavaScript is deliberately not
+ * among them, so a `.js` module reaches no adapter's transform.
+ *
+ * Shared with the Bun adapter (`bun.ts`) and the standalone Turbopack loader
+ * (`turbopack.ts`) through {@link isTransformTarget}, so the filter is defined
+ * once and every adapter answers the same way.
  */
 export declare const sourceFilePattern: RegExp;
 declare const unplugin: UnpluginInstance<TtscUnpluginOptions | undefined, false>;
 export type { TtscUnpluginCompilerOptionsJson, TtscUnpluginOptions, } from "./options.cjs";
 export type { TtscTransformFilesystemOperations, TtscTransformHooks, TtscWatchInputEvidence, } from "./transform.cjs";
+export type { ITtscProjectMembershipPolicy } from "./tsconfigPaths.cjs";
+export { mergeMembershipPolicyOverlay, readProjectMembershipPolicy, } from "./tsconfigPaths.cjs";
 export { beginTtscTransformBuild, collectExternalInputHashes, collectProjectInputHashes, createTtscTransformCache, isProjectWalkPath, resetTtscTransformCache, resolveOptions, transformTtsc, unplugin, };
 export default unplugin;
 /**
- * Returns `true` when the module id refers to a real TypeScript/JavaScript
- * source file that should be processed by the ttsc transform.
+ * Returns `true` when the module id refers to a real TypeScript source file
+ * that should be processed by the ttsc transform.
+ *
+ * TypeScript only. {@link sourceFilePattern} deliberately excludes JavaScript,
+ * so a `.js` module reaches no adapter's transform, and this docstring used to
+ * say otherwise while the pattern it is built from said the truth
+ * (samchon/ttsc#1309).
  *
- * Excluded ids: virtual modules (NUL prefix), `.d.ts` declaration files, and
+ * Also excluded: virtual modules (NUL prefix), `.d.ts` declaration files, and
  * anything inside `node_modules`.
  */
 export declare function isTransformTarget(id: string): boolean;

package/lib/core/index.d.mts

@@ -3,21 +3,32 @@ import type { TtscUnpluginOptions } from "./options.mjs";
 import { resolveOptions } from "./options.mjs";
 import { beginTtscTransformBuild, collectExternalInputHashes, collectProjectInputHashes, createTtscTransformCache, isProjectWalkPath, resetTtscTransformCache, transformTtsc } from "./transform.mjs";
 /**
- * Matches any TypeScript or JavaScript source extension (.ts, .tsx, .mts, .cts,
- * etc.). Shared with the Bun adapter (`bun.ts`) so the filter is defined once
- * and both adapters stay in sync.
+ * Matches the TypeScript source extensions the ttsc transform handles: `.ts`,
+ * `.tsx`, `.mts`, `.cts` and their `x` forms. JavaScript is deliberately not
+ * among them, so a `.js` module reaches no adapter's transform.
+ *
+ * Shared with the Bun adapter (`bun.ts`) and the standalone Turbopack loader
+ * (`turbopack.ts`) through {@link isTransformTarget}, so the filter is defined
+ * once and every adapter answers the same way.
  */
 export declare const sourceFilePattern: RegExp;
 declare const unplugin: UnpluginInstance<TtscUnpluginOptions | undefined, false>;
 export type { TtscUnpluginCompilerOptionsJson, TtscUnpluginOptions, } from "./options.mjs";
 export type { TtscTransformFilesystemOperations, TtscTransformHooks, TtscWatchInputEvidence, } from "./transform.mjs";
+export type { ITtscProjectMembershipPolicy } from "./tsconfigPaths.mjs";
+export { mergeMembershipPolicyOverlay, readProjectMembershipPolicy, } from "./tsconfigPaths.mjs";
 export { beginTtscTransformBuild, collectExternalInputHashes, collectProjectInputHashes, createTtscTransformCache, isProjectWalkPath, resetTtscTransformCache, resolveOptions, transformTtsc, unplugin, };
 export default unplugin;
 /**
- * Returns `true` when the module id refers to a real TypeScript/JavaScript
- * source file that should be processed by the ttsc transform.
+ * Returns `true` when the module id refers to a real TypeScript source file
+ * that should be processed by the ttsc transform.
+ *
+ * TypeScript only. {@link sourceFilePattern} deliberately excludes JavaScript,
+ * so a `.js` module reaches no adapter's transform, and this docstring used to
+ * say otherwise while the pattern it is built from said the truth
+ * (samchon/ttsc#1309).
  *
- * Excluded ids: virtual modules (NUL prefix), `.d.ts` declaration files, and
+ * Also excluded: virtual modules (NUL prefix), `.d.ts` declaration files, and
  * anything inside `node_modules`.
  */
 export declare function isTransformTarget(id: string): boolean;

package/lib/core/index.d.ts

@@ -3,21 +3,32 @@ import type { TtscUnpluginOptions } from "./options";
 import { resolveOptions } from "./options";
 import { beginTtscTransformBuild, collectExternalInputHashes, collectProjectInputHashes, createTtscTransformCache, isProjectWalkPath, resetTtscTransformCache, transformTtsc } from "./transform";
 /**
- * Matches any TypeScript or JavaScript source extension (.ts, .tsx, .mts, .cts,
- * etc.). Shared with the Bun adapter (`bun.ts`) so the filter is defined once
- * and both adapters stay in sync.
+ * Matches the TypeScript source extensions the ttsc transform handles: `.ts`,
+ * `.tsx`, `.mts`, `.cts` and their `x` forms. JavaScript is deliberately not
+ * among them, so a `.js` module reaches no adapter's transform.
+ *
+ * Shared with the Bun adapter (`bun.ts`) and the standalone Turbopack loader
+ * (`turbopack.ts`) through {@link isTransformTarget}, so the filter is defined
+ * once and every adapter answers the same way.
  */
 export declare const sourceFilePattern: RegExp;
 declare const unplugin: UnpluginInstance<TtscUnpluginOptions | undefined, false>;
 export type { TtscUnpluginCompilerOptionsJson, TtscUnpluginOptions, } from "./options";
 export type { TtscTransformFilesystemOperations, TtscTransformHooks, TtscWatchInputEvidence, } from "./transform";
+export type { ITtscProjectMembershipPolicy } from "./tsconfigPaths";
+export { mergeMembershipPolicyOverlay, readProjectMembershipPolicy, } from "./tsconfigPaths";
 export { beginTtscTransformBuild, collectExternalInputHashes, collectProjectInputHashes, createTtscTransformCache, isProjectWalkPath, resetTtscTransformCache, resolveOptions, transformTtsc, unplugin, };
 export default unplugin;
 /**
- * Returns `true` when the module id refers to a real TypeScript/JavaScript
- * source file that should be processed by the ttsc transform.
+ * Returns `true` when the module id refers to a real TypeScript source file
+ * that should be processed by the ttsc transform.
+ *
+ * TypeScript only. {@link sourceFilePattern} deliberately excludes JavaScript,
+ * so a `.js` module reaches no adapter's transform, and this docstring used to
+ * say otherwise while the pattern it is built from said the truth
+ * (samchon/ttsc#1309).
  *
- * Excluded ids: virtual modules (NUL prefix), `.d.ts` declaration files, and
+ * Also excluded: virtual modules (NUL prefix), `.d.ts` declaration files, and
  * anything inside `node_modules`.
  */
 export declare function isTransformTarget(id: string): boolean;

package/lib/core/index.js

@@ -8,12 +8,17 @@ var unplugin$1 = require('unplugin');
 var options = require('./options.js');
 var transform = require('./transform.js');
 var viteServe = require('./viteServe.js');
+var tsconfigPaths = require('./tsconfigPaths.js');
 
 const name = "ttsc-unplugin";
 /**
- * Matches any TypeScript or JavaScript source extension (.ts, .tsx, .mts, .cts,
- * etc.). Shared with the Bun adapter (`bun.ts`) so the filter is defined once
- * and both adapters stay in sync.
+ * Matches the TypeScript source extensions the ttsc transform handles: `.ts`,
+ * `.tsx`, `.mts`, `.cts` and their `x` forms. JavaScript is deliberately not
+ * among them, so a `.js` module reaches no adapter's transform.
+ *
+ * Shared with the Bun adapter (`bun.ts`) and the standalone Turbopack loader
+ * (`turbopack.ts`) through {@link isTransformTarget}, so the filter is defined
+ * once and every adapter answers the same way.
  */
 const sourceFilePattern = /\.[cm]?tsx?$/;
 /** Matches any path segment that is a `node_modules` directory (cross-platform). */
@@ -27,13 +32,15 @@ const virtualModulePattern = /\0/;
  * Unplugin factory that wires the ttsc transform pipeline into any supported
  * bundler (Vite, Rollup, Rolldown, webpack, Rspack, esbuild, Farm).
  *
- * The factory resolves raw options once, creates a per-build transform cache,
- * and captures Vite alias configuration via the `vite.configResolved` hook so
- * that path aliases are forwarded to the generated tsconfig overlay. Real build
- * lifecycles use a per-build cache; a watching Vite development server keeps
- * persistent validation because its one `buildStart` spans later HMR edits,
- * while a dev server configured without a watcher takes the build-scoped path
- * with them, having declared it will observe no edit at all.
+ * The factory resolves raw options once, creates one transform cache for the
+ * whole plugin instance, and captures Vite alias configuration via the
+ * `vite.configResolved` hook so that path aliases are forwarded to the
+ * generated tsconfig overlay. A host with a real `buildStart` opens a delivery
+ * pass there and keeps its generation across passes; a watching Vite
+ * development server keeps persistent validation instead, because its one
+ * `buildStart` spans later HMR edits and so cannot mark a pass, while a dev
+ * server configured without a watcher takes the pass lifecycle with them,
+ * having declared it will observe no edit at all.
  */
 const unpluginFactory = (rawOptions = {}) => {
     const options$1 = options.resolveOptions(rawOptions);
@@ -42,11 +49,16 @@ const unpluginFactory = (rawOptions = {}) => {
     let aliases;
     let viteCommand;
     let viteWatching = true;
+    // Whether a build-mode session is driven by Rollup's watcher. `build.watch`
+    // is `null` for an ordinary build and an object under `--watch`, which is the
+    // axis the disposal boundary actually turns on: only a watching build repeats
+    // its build phase, and only a watching build ends at `closeWatcher`.
+    let viteBuildWatching = false;
     // A restart can start the replacement plugin container before closing the
     // old one, and Vite calls buildEnd even for a container that never started.
     // Track the stable per-container PluginContext identity so that unstarted
     // old containers cannot dispose a replacement's freshly initialized cache.
-    const viteBuildOwners = new WeakSet();
+    let viteBuildOwners = new WeakSet();
     let viteBuildLifecycles = 0;
     return {
         name,
@@ -69,6 +81,13 @@ const unpluginFactory = (rawOptions = {}) => {
                 // (samchon/ttsc#1246).
                 viteWatching =
                     config.server?.watch !== null;
+                // Read on the same principle as the line above, from the half of the
+                // config that governs a build rather than a server. The comparison is
+                // loose where the server's is strict because the two defaults differ:
+                // `server.watch` is an object unless explicitly `null`, while
+                // `build.watch` is absent or `null` unless `--watch` supplies one.
+                viteBuildWatching =
+                    config.build?.watch != null;
             },
             // Vite serve funnels every transform-context `addWatchFile()` into the
             // module's added-import graph (`_addedImports`), which import-analysis
@@ -79,18 +98,84 @@ const unpluginFactory = (rawOptions = {}) => {
             configureServer(server) {
                 missingInputs.attach(server);
             },
-            // Vite calls buildEnd when the dev server (or build) closes; drop every
-            // poller and, once the last overlapping container has closed, every
-            // generation-owned filesystem tracker as well.
+            // Vite calls buildEnd when the dev server closes, and Rollup calls it at
+            // the end of every build phase; drop every poller and, once the last
+            // overlapping container has closed, every generation-owned filesystem
+            // tracker as well.
+            //
+            // Disposing here is right wherever the end of a build phase is also the
+            // end of the session: a dev server, and an ordinary one-shot build. It is
+            // wrong for a watching build, whose watcher repeats build phases, so it
+            // means "this pass ended" there — measured as
+            // `buildStart -> buildEnd -> ... -> buildStart -> buildEnd` across
+            // `vite build --watch` rebuilds. Disposing on that repeat discarded the
+            // generation once per rebuild independently of the `buildStart` clear, so
+            // fixing one of the two sites alone left this host recompiling the whole
+            // project per edit (samchon/ttsc#1301). The watching build hands its
+            // teardown to `closeWatcher` below instead.
             buildEnd() {
                 missingInputs.dispose();
                 if (viteBuildOwners.delete(this)) {
                     viteBuildLifecycles -= 1;
                 }
-                if (viteBuildLifecycles === 0) {
+                if (viteBuildLifecycles === 0 &&
+                    (viteCommand === "serve" || !viteBuildWatching)) {
+                    transform.resetTtscTransformCache(transformCache);
+                }
+            },
+            // The watching build's real teardown, and the only hook in a
+            // `vite build --watch` trace that fires exactly once: buildEnd,
+            // writeBundle and closeBundle all repeat per rebuild there. A generation
+            // retained across passes owns directory watchers, so this is where they
+            // are released. Vite's dev server drives no Rollup watcher and an
+            // ordinary build closes its bundle instead, so neither reaches here;
+            // a host that fired both would simply reset twice, which is idempotent.
+            //
+            // The container bookkeeping is cleared with the cache, and the owner set
+            // is replaced rather than merely zeroed alongside it. A watcher closed
+            // mid-rebuild leaves a container still registered, and its later
+            // `buildEnd` would then decrement a counter that is already zero and
+            // strand it below zero, after which the disposal above could never fire
+            // again for this plugin instance.
+            closeWatcher() {
+                viteBuildOwners = new WeakSet();
+                viteBuildLifecycles = 0;
+                transform.resetTtscTransformCache(transformCache);
+            },
+        },
+        // Rollup and Rolldown carry none of the Vite block's hooks, so before this
+        // they had no disposal site at all. They get both halves of the same
+        // boundary: a watching session ends at `closeWatcher`, and a one-shot build
+        // ends when its build phase does. `this.meta.watchMode` separates the two
+        // there, the way `build.watch` does for Vite, so a one-shot build is not
+        // left without a site the way `vite build` was (samchon/ttsc#1301).
+        // unplugin merges each of these blocks only into its own adapter, so the
+        // Vite adapter never receives them.
+        //
+        // A `buildEnd` at the top level instead of inside a block would be a
+        // regression rather than a shorthand: unplugin forwards a top-level one to
+        // esbuild's `onEnd` and to webpack's and Rspack's `hooks.emit`, each of
+        // which repeats per rebuild, so those hosts would start discarding a valid
+        // generation on every edit, which is samchon/ttsc#1300 again.
+        rollup: {
+            buildEnd() {
+                if (this.meta?.watchMode !== true) {
+                    transform.resetTtscTransformCache(transformCache);
+                }
+            },
+            closeWatcher() {
+                transform.resetTtscTransformCache(transformCache);
+            },
+        },
+        rolldown: {
+            buildEnd() {
+                if (this.meta?.watchMode !== true) {
                     transform.resetTtscTransformCache(transformCache);
                 }
             },
+            closeWatcher() {
+                transform.resetTtscTransformCache(transformCache);
+            },
         },
         buildStart() {
             if (viteCommand !== undefined && !viteBuildOwners.has(this)) {
@@ -104,14 +189,18 @@ const unpluginFactory = (rawOptions = {}) => {
             // no client is hot-updated. Validating each delivery there does not buy
             // freshness, it buys incoherence — modules delivered before an edit and
             // after it would come from two different compilations of one program —
-            // while costing a full derived-input proof per delivered module. The
-            // build-scoped lifecycle settles each module's first delivery against the
-            // generation the session started from, exactly as a build does, and still
+            // while costing a full derived-input proof per delivered module. The pass
+            // lifecycle settles each module's first delivery against the generation
+            // the session started from, exactly as a build does, and still
             // revalidates a module this session already delivered. A one-shot suite
             // configures precisely this server (`vitest --run` sets `server.watch =
             // null`) and is the workload behind samchon/ttsc#970
             // (samchon/ttsc#1260). The neighbouring watch-registration decision reads
             // the same two properties for the same reason.
+            //
+            // Opening a pass no longer discards the generation, so the `else` branch
+            // is what every host with a repeating `buildStart` takes without paying a
+            // whole-project transform per rebuild (samchon/ttsc#1300).
             if (viteCommand === "serve" && viteWatching) {
                 transform.resetTtscTransformCache(transformCache);
             }
@@ -177,10 +266,15 @@ const unpluginFactory = (rawOptions = {}) => {
 };
 const unplugin = unplugin$1.createUnplugin(unpluginFactory);
 /**
- * Returns `true` when the module id refers to a real TypeScript/JavaScript
- * source file that should be processed by the ttsc transform.
+ * Returns `true` when the module id refers to a real TypeScript source file
+ * that should be processed by the ttsc transform.
+ *
+ * TypeScript only. {@link sourceFilePattern} deliberately excludes JavaScript,
+ * so a `.js` module reaches no adapter's transform, and this docstring used to
+ * say otherwise while the pattern it is built from said the truth
+ * (samchon/ttsc#1309).
  *
- * Excluded ids: virtual modules (NUL prefix), `.d.ts` declaration files, and
+ * Also excluded: virtual modules (NUL prefix), `.d.ts` declaration files, and
  * anything inside `node_modules`.
  */
 function isTransformTarget(id) {
@@ -198,6 +292,8 @@ exports.createTtscTransformCache = transform.createTtscTransformCache;
 exports.isProjectWalkPath = transform.isProjectWalkPath;
 exports.resetTtscTransformCache = transform.resetTtscTransformCache;
 exports.transformTtsc = transform.transformTtsc;
+exports.mergeMembershipPolicyOverlay = tsconfigPaths.mergeMembershipPolicyOverlay;
+exports.readProjectMembershipPolicy = tsconfigPaths.readProjectMembershipPolicy;
 exports.default = unplugin;
 exports.isTransformTarget = isTransformTarget;
 exports.sourceFilePattern = sourceFilePattern;

package/lib/core/index.js.map

@@ -1 +1 @@
-{"version":3,"file":"index.js","sources":["../../src/core/index.ts"],"sourcesContent":[null],"names":["options","resolveOptions","createTtscTransformCache","createViteServeMissingInputWatch","resetTtscTransformCache","beginTtscTransformBuild","stripQuery","transformTtsc","createUnplugin","isDeclarationFile"],"mappings":";;;;;;;;;;;AAoBA,MAAM,IAAI,GAAG,eAAe;AAC5B;;;;AAIG;AACI,MAAM,iBAAiB,GAAG;AACjC;AACA,MAAM,kBAAkB,GAAG,oCAAoC;AAC/D;;;AAGG;AACH,MAAM,oBAAoB,GAAG,IAAI;AAEjC;;;;;;;;;;;AAWG;AACH,MAAM,eAAe,GAGjB,CAAC,UAAU,GAAG,EAAE,KAAI;AACtB,IAAA,MAAMA,SAAO,GAAGC,sBAAc,CAAC,UAAU,CAAC;AAC1C,IAAA,MAAM,cAAc,GAAGC,kCAAwB,EAAE;AACjD,IAAA,MAAM,aAAa,GAAGC,0CAAgC,EAAE;AACxD,IAAA,IAAI,OAAgB;AACpB,IAAA,IAAI,WAA+B;IACnC,IAAI,YAAY,GAAG,IAAI;;;;;AAKvB,IAAA,MAAM,eAAe,GAAG,IAAI,OAAO,EAAU;IAC7C,IAAI,mBAAmB,GAAG,CAAC;IAE3B,OAAO;QACL,IAAI;AACJ,QAAA,OAAO,EAAE,KAAK;AAEd,QAAA,IAAI,EAAE;AACJ,YAAA,cAAc,CAAC,MAAM,EAAA;AACnB,gBAAA,OAAO,GAAG,MAAM,CAAC,OAAO,CAAC,KAAK;;;;;AAK9B,gBAAA,WAAW,GAAG,MAAM,CAAC,OAAO;;;;;;;;;gBAS5B,YAAY;AACT,oBAAA,MAA2C,CAAC,MAAM,EAAE,KAAK,KAAK,IAAI;YACvE,CAAC;;;;;;;AAOD,YAAA,eAAe,CAAC,MAAM,EAAA;AACpB,gBAAA,aAAa,CAAC,MAAM,CAAC,MAAM,CAAC;YAC9B,CAAC;;;;YAID,QAAQ,GAAA;gBACN,aAAa,CAAC,OAAO,EAAE;AACvB,gBAAA,IAAI,eAAe,CAAC,MAAM,CAAC,IAAI,CAAC,EAAE;oBAChC,mBAAmB,IAAI,CAAC;gBAC1B;AACA,gBAAA,IAAI,mBAAmB,KAAK,CAAC,EAAE;oBAC7BC,iCAAuB,CAAC,cAAc,CAAC;gBACzC;YACF,CAAC;AACF,SAAA;QAED,UAAU,GAAA;AACR,YAAA,IAAI,WAAW,KAAK,SAAS,IAAI,CAAC,eAAe,CAAC,GAAG,CAAC,IAAc,CAAC,EAAE;AACrE,gBAAA,eAAe,CAAC,GAAG,CAAC,IAAc,CAAC;gBACnC,mBAAmB,IAAI,CAAC;YAC1B;;;;;;;;;;;;;;;;AAgBA,YAAA,IAAI,WAAW,KAAK,OAAO,IAAI,YAAY,EAAE;gBAC3CA,iCAAuB,CAAC,cAAc,CAAC;YACzC;iBAAO;gBACLC,iCAAuB,CAAC,cAAc,CAAC;YACzC;QACF,CAAC;AAED,QAAA,gBAAgB,CAAC,EAAE,EAAA;AACjB,YAAA,MAAM,IAAI,GAAGC,oBAAU,CAAC,EAAE,CAAC;AAC3B,YAAA,OAAO,iBAAiB,CAAC,IAAI,CAAC;QAChC,CAAC;AAED,QAAA,MAAM,SAAS,CAAC,MAAM,EAAE,EAAE,EAAA;AACxB,YAAA,MAAM,IAAI,GAAGA,oBAAU,CAAC,EAAE,CAAC;AAC3B,YAAA,IAAI,CAAC,iBAAiB,CAAC,IAAI,CAAC,EAAE;AAC5B,gBAAA,OAAO,SAAS;YAClB;YACA,OAAOC,uBAAa,CAAC,IAAI,EAAE,MAAM,EAAEP,SAAO,EAAE,OAAO,EAAE,cAAc,EAAE;;;;;;;;;;;AAWnE,gBAAA,YAAY,EAAE,CAAC,OAAO,EAAE,QAAQ,KAAI;oBAClC,IAAI,WAAW,KAAK,OAAO,IAAI,aAAa,CAAC,OAAO,EAAE,EAAE;;;;AAItD,wBAAA,MAAM,OAAO,GAAG,QAAQ,EAAE,OAAO,IAAI,CAAC,EAAE,CAAC,UAAU,CAAC,OAAO,CAAC;wBAC5D,IAAI,OAAO,EAAE;AACX,4BAAA,aAAa,CAAC,KAAK,CACjB,OAAO,EACP,IAAI,CAAC,OAAO,CAAC,IAAI,CAAC,EAClB,QAAQ,EAAE,QAAQ,CACnB;4BACD;wBACF;oBACF;;;;;;;AAOA,oBAAA,IAAI,WAAW,KAAK,OAAO,IAAI,CAAC,YAAY,EAAE;wBAC5C;oBACF;AACA,oBAAA,IAAI,CAAC,YAAY,CAAC,OAAO,CAAC;gBAC5B,CAAC;;;;gBAID,YAAY,EAAE,MAAK;AACjB,oBAAA,MAAM,MAAM,GAAG,IAAI,CAAC,qBAAqB,IAAI;AAC7C,oBAAA,IACE,MAAM,EAAE,SAAS,KAAK,SAAS;AAC/B,wBAAA,MAAM,EAAE,SAAS,KAAK,QAAQ,EAC9B;wBACA,MAAM,CAAC,aAAa,EAAE,SAAS,GAAG,KAAK,CAAC;oBAC1C;gBACF,CAAC;AACF,aAAA,CAAC;QACJ,CAAC;KACF;AACH,CAAC;AAED,MAAM,QAAQ,GACZQ,yBAAc,CAAC,eAAe;AAyBhC;;;;;;AAMG;AACG,SAAU,iBAAiB,CAAC,EAAU,EAAA;AAC1C,IAAA,QACE,iBAAiB,CAAC,IAAI,CAAC,EAAE,CAAC;AAC1B,QAAA,CAAC,oBAAoB,CAAC,IAAI,CAAC,EAAE,CAAC;QAC9B,CAACC,2BAAiB,CAAC,EAAE,CAAC;AACtB,QAAA,CAAC,kBAAkB,CAAC,IAAI,CAAC,EAAE,CAAC;AAEhC;;;;;;;;;;;;;;;"}
+{"version":3,"file":"index.js","sources":["../../src/core/index.ts"],"sourcesContent":[null],"names":["options","resolveOptions","createTtscTransformCache","createViteServeMissingInputWatch","resetTtscTransformCache","beginTtscTransformBuild","stripQuery","transformTtsc","createUnplugin","isDeclarationFile"],"mappings":";;;;;;;;;;;;AAoBA,MAAM,IAAI,GAAG,eAAe;AAC5B;;;;;;;;AAQG;AACI,MAAM,iBAAiB,GAAG;AACjC;AACA,MAAM,kBAAkB,GAAG,oCAAoC;AAC/D;;;AAGG;AACH,MAAM,oBAAoB,GAAG,IAAI;AAEjC;;;;;;;;;;;;;AAaG;AACH,MAAM,eAAe,GAGjB,CAAC,UAAU,GAAG,EAAE,KAAI;AACtB,IAAA,MAAMA,SAAO,GAAGC,sBAAc,CAAC,UAAU,CAAC;AAC1C,IAAA,MAAM,cAAc,GAAGC,kCAAwB,EAAE;AACjD,IAAA,MAAM,aAAa,GAAGC,0CAAgC,EAAE;AACxD,IAAA,IAAI,OAAgB;AACpB,IAAA,IAAI,WAA+B;IACnC,IAAI,YAAY,GAAG,IAAI;;;;;IAKvB,IAAI,iBAAiB,GAAG,KAAK;;;;;AAK7B,IAAA,IAAI,eAAe,GAAG,IAAI,OAAO,EAAU;IAC3C,IAAI,mBAAmB,GAAG,CAAC;IAE3B,OAAO;QACL,IAAI;AACJ,QAAA,OAAO,EAAE,KAAK;AAEd,QAAA,IAAI,EAAE;AACJ,YAAA,cAAc,CAAC,MAAM,EAAA;AACnB,gBAAA,OAAO,GAAG,MAAM,CAAC,OAAO,CAAC,KAAK;;;;;AAK9B,gBAAA,WAAW,GAAG,MAAM,CAAC,OAAO;;;;;;;;;gBAS5B,YAAY;AACT,oBAAA,MAA2C,CAAC,MAAM,EAAE,KAAK,KAAK,IAAI;;;;;;gBAMrE,iBAAiB;AACd,oBAAA,MAA0C,CAAC,KAAK,EAAE,KAAK,IAAI,IAAI;YACpE,CAAC;;;;;;;AAOD,YAAA,eAAe,CAAC,MAAM,EAAA;AACpB,gBAAA,aAAa,CAAC,MAAM,CAAC,MAAM,CAAC;YAC9B,CAAC;;;;;;;;;;;;;;;;YAgBD,QAAQ,GAAA;gBACN,aAAa,CAAC,OAAO,EAAE;AACvB,gBAAA,IAAI,eAAe,CAAC,MAAM,CAAC,IAAI,CAAC,EAAE;oBAChC,mBAAmB,IAAI,CAAC;gBAC1B;gBACA,IACE,mBAAmB,KAAK,CAAC;qBACxB,WAAW,KAAK,OAAO,IAAI,CAAC,iBAAiB,CAAC,EAC/C;oBACAC,iCAAuB,CAAC,cAAc,CAAC;gBACzC;YACF,CAAC;;;;;;;;;;;;;;;YAeD,YAAY,GAAA;AACV,gBAAA,eAAe,GAAG,IAAI,OAAO,EAAU;gBACvC,mBAAmB,GAAG,CAAC;gBACvBA,iCAAuB,CAAC,cAAc,CAAC;YACzC,CAAC;AACF,SAAA;;;;;;;;;;;;;;;AAgBD,QAAA,MAAM,EAAE;YACN,QAAQ,GAAA;gBACN,IAAI,IAAI,CAAC,IAAI,EAAE,SAAS,KAAK,IAAI,EAAE;oBACjCA,iCAAuB,CAAC,cAAc,CAAC;gBACzC;YACF,CAAC;YACD,YAAY,GAAA;gBACVA,iCAAuB,CAAC,cAAc,CAAC;YACzC,CAAC;AACF,SAAA;AACD,QAAA,QAAQ,EAAE;YACR,QAAQ,GAAA;gBACN,IAAI,IAAI,CAAC,IAAI,EAAE,SAAS,KAAK,IAAI,EAAE;oBACjCA,iCAAuB,CAAC,cAAc,CAAC;gBACzC;YACF,CAAC;YACD,YAAY,GAAA;gBACVA,iCAAuB,CAAC,cAAc,CAAC;YACzC,CAAC;AACF,SAAA;QAED,UAAU,GAAA;AACR,YAAA,IAAI,WAAW,KAAK,SAAS,IAAI,CAAC,eAAe,CAAC,GAAG,CAAC,IAAc,CAAC,EAAE;AACrE,gBAAA,eAAe,CAAC,GAAG,CAAC,IAAc,CAAC;gBACnC,mBAAmB,IAAI,CAAC;YAC1B;;;;;;;;;;;;;;;;;;;;AAoBA,YAAA,IAAI,WAAW,KAAK,OAAO,IAAI,YAAY,EAAE;gBAC3CA,iCAAuB,CAAC,cAAc,CAAC;YACzC;iBAAO;gBACLC,iCAAuB,CAAC,cAAc,CAAC;YACzC;QACF,CAAC;AAED,QAAA,gBAAgB,CAAC,EAAE,EAAA;AACjB,YAAA,MAAM,IAAI,GAAGC,oBAAU,CAAC,EAAE,CAAC;AAC3B,YAAA,OAAO,iBAAiB,CAAC,IAAI,CAAC;QAChC,CAAC;AAED,QAAA,MAAM,SAAS,CAAC,MAAM,EAAE,EAAE,EAAA;AACxB,YAAA,MAAM,IAAI,GAAGA,oBAAU,CAAC,EAAE,CAAC;AAC3B,YAAA,IAAI,CAAC,iBAAiB,CAAC,IAAI,CAAC,EAAE;AAC5B,gBAAA,OAAO,SAAS;YAClB;YACA,OAAOC,uBAAa,CAAC,IAAI,EAAE,MAAM,EAAEP,SAAO,EAAE,OAAO,EAAE,cAAc,EAAE;;;;;;;;;;;AAWnE,gBAAA,YAAY,EAAE,CAAC,OAAO,EAAE,QAAQ,KAAI;oBAClC,IAAI,WAAW,KAAK,OAAO,IAAI,aAAa,CAAC,OAAO,EAAE,EAAE;;;;AAItD,wBAAA,MAAM,OAAO,GAAG,QAAQ,EAAE,OAAO,IAAI,CAAC,EAAE,CAAC,UAAU,CAAC,OAAO,CAAC;wBAC5D,IAAI,OAAO,EAAE;AACX,4BAAA,aAAa,CAAC,KAAK,CACjB,OAAO,EACP,IAAI,CAAC,OAAO,CAAC,IAAI,CAAC,EAClB,QAAQ,EAAE,QAAQ,CACnB;4BACD;wBACF;oBACF;;;;;;;AAOA,oBAAA,IAAI,WAAW,KAAK,OAAO,IAAI,CAAC,YAAY,EAAE;wBAC5C;oBACF;AACA,oBAAA,IAAI,CAAC,YAAY,CAAC,OAAO,CAAC;gBAC5B,CAAC;;;;gBAID,YAAY,EAAE,MAAK;AACjB,oBAAA,MAAM,MAAM,GAAG,IAAI,CAAC,qBAAqB,IAAI;AAC7C,oBAAA,IACE,MAAM,EAAE,SAAS,KAAK,SAAS;AAC/B,wBAAA,MAAM,EAAE,SAAS,KAAK,QAAQ,EAC9B;wBACA,MAAM,CAAC,aAAa,EAAE,SAAS,GAAG,KAAK,CAAC;oBAC1C;gBACF,CAAC;AACF,aAAA,CAAC;QACJ,CAAC;KACF;AACH,CAAC;AAED,MAAM,QAAQ,GACZQ,yBAAc,CAAC,eAAe;AA8BhC;;;;;;;;;;;AAWG;AACG,SAAU,iBAAiB,CAAC,EAAU,EAAA;AAC1C,IAAA,QACE,iBAAiB,CAAC,IAAI,CAAC,EAAE,CAAC;AAC1B,QAAA,CAAC,oBAAoB,CAAC,IAAI,CAAC,EAAE,CAAC;QAC9B,CAACC,2BAAiB,CAAC,EAAE,CAAC;AACtB,QAAA,CAAC,kBAAkB,CAAC,IAAI,CAAC,EAAE,CAAC;AAEhC;;;;;;;;;;;;;;;;;"}