@happyvertical/smrt-vitest 0.51.1 → 0.51.3

package/AGENTS.md

@@ -24,6 +24,31 @@ Without the plugin → "unregistered class" / "No field metadata found" errors.
 4. Registers all classes in ObjectRegistry
 5. Watch mode caveat: manifest only generated at startup — restart vitest after adding new classes/fields
 
+## Pool and isolation (#2897)
+
+Measured on a 333-file, 3,259-test unit suite, 16 cores (follow-up to #2893):
+
+| mode | wall | CPU | result |
+|---|---|---|---|
+| `pool: 'forks'`, isolated (default) | 22.9 s | 274 s | all pass |
+| `pool: 'threads'`, isolated | 19.4 s | 234 s | all pass |
+| `pool: 'forks'`, `isolate: false` | 12.1 s | 93 s | 7 fail in 1 file (leaked module mock from another file) |
+
+- `pool: 'threads'` is supported and ran ~15% cheaper here; try it per project
+  since native drivers can behave differently under threads vs. forks.
+- `isolate: false` is supported by this plugin's own setup: the registration
+  guard in `src/setup.ts` is self-healing by design (it re-registers after
+  `ObjectRegistry.clear()`, which is why that guard exists — #2750). Turning
+  isolation off is a consumer decision: it removes the leak guard between test
+  files, so a failing file under it is a real cross-file leak to fix, not a
+  plugin bug. Recommend it for unit projects only, never for integration
+  projects.
+- The per-file fixed cost is process + module-graph bootstrap (roughly half a
+  second of CPU per file), not manifest registration (50-90 ms). Precomputing
+  registration saves little against that fixed cost; see the #2893
+  measurements. Lazy-loading `@happyvertical/ai` in core is the
+  isolation-preserving lever, tracked separately.
+
 ## Vite 8 (rolldown/oxc) normalization (#2017)
 
 The plugin's `config` hook normalizes three vite 8 behaviors so consumers
@@ -116,6 +141,27 @@ the test transaction. Transaction handles are treated as already initialized
 by SMRT objects, so moving this provisioning into the transaction would leave
 the first interceptor-driven write without its required function (#2427).
 
+The setup file's mocked `getDatabase()` also prechecks a PostgreSQL handle's
+live schema before calling `syncSchema` (#2890): two constant-count queries
+(`information_schema.columns` joined to `information_schema.tables` on
+`table_type = 'BASE TABLE'` + `pg_indexes`, scoped to `current_schema()` —
+never a literal `'public'`, since in-repo suites open handles against other
+schemas via `search_path` — and batched across every registered table)
+replace a per-column `SELECT EXISTS` round trip for every table on every
+call, so a handle reopened against an already-provisioned database (a
+per-test database name defeats the connection-URL-keyed
+`preparedSchemasByConfig` cache) skips `syncSchema` entirely for tables that
+already have every declared column and index. The `BASE TABLE` join matters
+because `information_schema.columns` alone also lists a VIEW's columns; a
+same-named view would otherwise satisfy the precheck (no `pg_indexes` rows
+required) but cannot store rows. The precheck never runs on a
+transactional handle (it would read un-savepointed, and PostgreSQL silently
+no-ops every later statement on an aborted transaction) — `syncSchema` runs
+for every table there, same as on any precheck failure on a non-transactional
+handle, matching pre-#2890 behavior in both cases. Opt out per call with
+`getDatabase({ ..., __smrtSkipVitestSchemaPreparation: true })`, or disable
+automatic schema preparation globally with `SMRT_VITEST_AUTO_SCHEMA=0`.
+
 For local file-backed SQLite, identical schemas are prepared once per Vitest
 process and cloned from an immutable schema-only template for later databases.
 The cache key is the full generated DDL, concurrent first callers share one

package/README.md

@@ -33,7 +33,7 @@ Without this plugin, tests fail with `"No field metadata found"` or `"unregister
 | `include` | `string[]` | `['src/**/*.ts']` | Source patterns to scan |
 | `exclude` | `string[]` | `['**/*.d.ts', ...]` | Patterns to exclude |
 | `packages` | `string[]` | `[]` | Additional packages beyond auto-discovered |
-| `verbose` | `boolean` | `false` | Enable detailed logging |
+| `verbose` | `boolean` | `false` | Emit per-package manifest-registration log lines. Also on with `SMRT_VERBOSE=true` or `DEBUG` containing `smrt`, regardless of this option. A one-line per-process summary (`Loaded manifests from N/M packages`) always logs once even when this is `false`. |
 | `root` | `string` | `process.cwd()` | Root directory |
 | `setupFile` | `string` | package setup entry | Override the setup file injected into Vitest projects |
 | `aliasFilter` | `(entry) => boolean` | keep all | Drop auto-generated workspace alias entries (receives the raw string `find` and `replacement`) |
@@ -83,6 +83,31 @@ settings on vite 8.
 
 The manifest is generated once at vitest startup. Restart vitest after adding new `@smrt()` classes or fields.
 
+### Pool and Isolation
+
+Measured on a 333-file, 3,259-test unit suite, 16 cores (#2897, follow-up to #2893):
+
+| mode | wall | CPU | result |
+|---|---|---|---|
+| `pool: 'forks'`, isolated (default) | 22.9 s | 274 s | all pass |
+| `pool: 'threads'`, isolated | 19.4 s | 234 s | all pass |
+| `pool: 'forks'`, `isolate: false` | 12.1 s | 93 s | 7 fail in 1 file (leaked module mock from another file) |
+
+- **`pool: 'threads'` is supported** and came in ~15% cheaper on this suite. Try it per
+  project -- native drivers can behave differently under threads vs. forks.
+- **`isolate: false` is supported** by this plugin's own setup: the registration guard
+  in `src/setup.ts` is self-healing by design (it re-registers after
+  `ObjectRegistry.clear()`, which is why that guard exists -- #2750). Turning isolation
+  off is a consumer decision, though: it removes the leak guard *between* test files, so
+  a failing file under it is signaling a real cross-file leak to fix, not a plugin bug.
+  Recommended for unit projects only, never for integration projects.
+- The per-file fixed cost this plugin pays is process + module-graph bootstrap
+  (roughly half a second of CPU per file), not manifest registration itself
+  (50-90 ms). Precomputing registration would save little against that fixed cost; see
+  the measurements in #2893. Lazy-loading `@happyvertical/ai` in core (a separate,
+  isolation-preserving change) is the bigger lever for consumers with the ai package on
+  their dependency graph.
+
 ## API
 
 ### Plugin