Filed unassigned while measuring #11412. Recording only — not graded here, and
⛔ no config change was made: #11412's triage was explicit that this trade-off
goes to a decision rather than into a config edit. This card exists so the decision
starts from measurements instead of the assumption.
What #11412 assumed
That restoring the Node anchor via server.deps.external "may be in tension" with
the source-resolution invariant check:test-source-alias enforces, and that the
two goals might be irreconcilable.
What was measured
In packages/cli/vitest.config.ts, temporarily:
test: { server: { deps: { external: [/packages[\/]types[\/]dist/] } } }
- It works.
createHostImporter's body loses __vite_ssr_dynamic_import__,
and the no-base importer THROWS on a CLI-declared package exactly as it does
under real Node — the anchor is back. pnpm check:test-source-alias stays green (72 packages scanned).- No test cost: the 11
packages/cli test files that consume
@objectstack/types pass identically with and without it — 103/103 both ways.
Why there may be no tension at all
@objectstack/types is already registered in that gate's shrink-only
KNOWN_UNALIASED_TEST_IMPORTS['@objectstack/cli'], i.e. it already resolves
through exports to dist/. Externalising does not move it off source — it was
never on source.
More generally, and this is the part worth arguing with: an external pattern
anchored on /dist/ cannot match a package aliased to source, because an
aliased import resolves into src/. The two mechanisms address disjoint sets by
construction. If that holds, "externalise by dist realpath" and "alias to source"
are complementary rather than competing.
⚠️ The trap that made this read the other way first
The pattern must match the module's realpath. A pnpm-linked workspace package's
realpath is the package directory — packages/types/dist/node.mjs — which contains
neither /node_modules/ nor the package NAME. A natural-looking
/@objectstack[\/]types/ pattern therefore matches nothing, silently, and the
experiment reads as "externalising does not help". First measured wrong here for
exactly that reason. (It is also why every workspace package is inlined by default:
vitest's default external is [/\/node_modules\//], evaluated against that same
realpath.)
Not measured here
- The full
packages/cli suite under the entry (1498 tests) — only the 11
@objectstack/types consumers were run. - Any package other than
packages/cli. - The second-order costs of externalising:
vi.mock of an externalised package
stops working, and coverage instrumentation of it is lost. Neither bites the 11
files measured; both would need checking before any repo-wide policy. - Whether this should be per-package, or a shared vitest preset.
Related: #11412 · #7849 · #8249 · #8180 (the source-vs-dist axis this one is
adjacent to but distinct from)
Filed unassigned while measuring #11412. Recording only — not graded here, and
⛔ no config change was made: #11412's triage was explicit that this trade-off
goes to a decision rather than into a config edit. This card exists so the decision
starts from measurements instead of the assumption.
What #11412 assumed
That restoring the Node anchor via
server.deps.external"may be in tension" withthe source-resolution invariant
check:test-source-aliasenforces, and that thetwo goals might be irreconcilable.
What was measured
In
packages/cli/vitest.config.ts, temporarily:createHostImporter's body loses__vite_ssr_dynamic_import__,and the no-base importer THROWS on a CLI-declared package exactly as it does
under real Node — the anchor is back.
pnpm check:test-source-aliasstays green (72 packages scanned).packages/clitest files that consume@objectstack/typespass identically with and without it — 103/103 both ways.Why there may be no tension at all
@objectstack/typesis already registered in that gate's shrink-onlyKNOWN_UNALIASED_TEST_IMPORTS['@objectstack/cli'], i.e. it already resolvesthrough
exportstodist/. Externalising does not move it off source — it wasnever on source.
More generally, and this is the part worth arguing with: an external pattern
anchored on
/dist/cannot match a package aliased to source, because analiased import resolves into
src/. The two mechanisms address disjoint sets byconstruction. If that holds, "externalise by dist realpath" and "alias to source"
are complementary rather than competing.
The pattern must match the module's realpath. A pnpm-linked workspace package's
realpath is the package directory —
packages/types/dist/node.mjs— which containsneither
/node_modules/nor the package NAME. A natural-looking/@objectstack[\/]types/pattern therefore matches nothing, silently, and theexperiment reads as "externalising does not help". First measured wrong here for
exactly that reason. (It is also why every workspace package is inlined by default:
vitest's default
externalis[/\/node_modules\//], evaluated against that samerealpath.)
Not measured here
packages/clisuite under the entry (1498 tests) — only the 11@objectstack/typesconsumers were run.packages/cli.vi.mockof an externalised packagestops working, and coverage instrumentation of it is lost. Neither bites the 11
files measured; both would need checking before any repo-wide policy.
Related: #11412 · #7849 · #8249 · #8180 (the source-vs-dist axis this one is
adjacent to but distinct from)