test(service-settings): alias the remaining three workspace deps to source, emptying its check-test-source-alias entry (#8104) (#8190)

#8063 aliased two workspace deps to source in this package's first
`vitest.config.ts`. The other three — `@objectstack/spec`,
`@objectstack/platform-objects`, `@objectstack/types` — stayed on their
`KNOWN_UNALIASED_TEST_IMPORTS` entry and kept resolving through `exports` to
`dist/`. They are now aliased to source and the registry entry is deleted.

17 of this package's 20 test files were really reading the artifact: with the
three `dist/` trees removed and the pre-#8104 config in place, 17 files fail to
load and only 58 of 413 cases run. With the aliases, the same tree with no
`spec`/`platform-objects`/`types` build output passes 413/413.

The subpath entry points were the actual work. This package imports no bare
`@objectstack/spec` and no bare `@objectstack/platform-objects` at run time —
every reachable specifier for those two is a subpath (`spec/api`,
`spec/contracts`, `spec/data`, `spec/system`, `platform-objects/system`, plus
`spec/security` reached transitively through `types`). The object alias form
would swallow them into `…/index.ts/<sub>` (`ENOTDIR`, #7778); the anchored bare
form #8063 established does not swallow them but does not cover them either, so
copying that shape would have left every one of them on `dist` with the registry
entry undeletable.

So `spec` takes the one-rule-for-all-namespaces capture form, its export map
being uniform, while `platform-objects` takes an explicit `/system` entry
because its map is not (`./plugin` is `src/plugin.ts`, a file, so a `([a-z-]+)`
rule would invent `src/plugin/index.ts`). `plugin-audit` writes its
`platform-objects/audit` entry the same way.

The registry deletion is half the change: the entry is audited for set equality
in both directions, so aliases-complete-with-entry-present and
entry-deleted-with-aliases-incomplete each fail the gate. It reads OK at 61
registered packages, down from 62.

413 passed / 20 files, unchanged from baseline. No change under `src/`.


Claude-Session: https://claude.ai/code/session_01SMN7p2W62YzA3bY7BaFv3r

Co-authored-by: Claude <noreply@anthropic.com>

Author: huangyiirene

.changeset/service-settings-tests-alias-remaining-deps-to-source.md

@@ -0,0 +1,61 @@
+---
+"@objectstack/service-settings": patch
+---
+
+test(service-settings): resolve the remaining three workspace deps from source, emptying this package's `check-test-source-alias` registry entry (#8104)
+
+#8063 gave this package its first `vitest.config.ts` and aliased two workspace
+deps to source (`@objectstack/objectql`, `@objectstack/core`) — the two that
+gate named when the package's first real-engine test landed. The other three,
+`@objectstack/spec`, `@objectstack/platform-objects` and `@objectstack/types`,
+stayed on their registered entry in `KNOWN_UNALIASED_TEST_IMPORTS` and kept
+resolving through `exports` to **`dist/`**. They are now aliased to source and
+the entry is deleted.
+
+**How much of the suite was actually reading the artifact: 17 of 20 files.**
+Measured, not inferred — with the three `dist/` trees removed from the checkout
+and the pre-#8104 config in place, 17 test files fail to load at all
+(`Cannot find package '@objectstack/spec/system'`) and only 58 of 413 cases run.
+With the aliases below, the same tree with no `spec`, `platform-objects` or
+`types` build output anywhere passes 413/413. The build artifact is off the
+resolution path rather than merely shadowed by a fresh copy of it.
+
+**The subpath entry points were the whole job, and the obvious shape does not
+do it.** This package imports **no bare** `@objectstack/spec` and **no bare**
+`@objectstack/platform-objects` at run time. Every specifier its tests can reach
+for those two is a subpath — `spec/api`, `spec/contracts`, `spec/data`,
+`spec/system`, `platform-objects/system` — joined by `spec/security`, reached
+transitively through `@objectstack/types` ([ADR-0105 D1] tenancy posture) once
+types itself resolves to source. So the two shapes that suggest themselves both
+fail, in opposite directions:
+
+- the **object** form matches by **prefix**, so a bare key whose replacement is
+  a file swallows the subpaths into `…/index.ts/system` — `ENOTDIR` at run time
+  in a config that reads as correct (#7778);
+- the **anchored bare** form (`/^@objectstack\/spec$/`, the shape #8063 left
+  behind) does not swallow them but does not **cover** them either — all six
+  specifiers stay on `dist` and the registry entry cannot come off.
+
+What covers them is a subpath rule. `spec` takes the one-rule-for-all-namespaces
+form `/^@objectstack\/spec\/([a-z-]+)$/` with the capture group inside the path,
+because its export map is uniform (`src/<ns>/index.ts` throughout) — so a new
+namespace import cannot make it stale. `platform-objects` gets an **explicit**
+`platform-objects/system` entry instead, because its map is *not* uniform:
+`./plugin` is `src/plugin.ts`, a file, so a `([a-z-]+)` rule would send
+`platform-objects/plugin` to `src/plugin/index.ts`, a path nobody wrote, failing
+on whoever next adds that import. `plugin-audit` writes its
+`platform-objects/audit` entry the same way for the same reason.
+
+**The registry deletion is half the change, not its cleanup.**
+`KNOWN_UNALIASED_TEST_IMPORTS` is audited for set equality in both directions,
+so the two halves constrain each other and neither is green alone: with the
+aliases complete and the entry still present the gate fails *"registry entry is
+no longer needed … Delete the entry"*; with the entry deleted and any one alias
+missing it fails *"tests import 1 workspace package(s) that resolve to `dist/`
+with no source alias"*. The gate goes from 62 registered packages to 61.
+
+No test turned red and no assertion moved: 413 passed / 20 files before and
+after, and **no change under `src/`**. That is the expected reading for a
+checkout whose `dist` was built from the same commit — dist and source agree
+here, which is exactly the condition under which the old setup looked fine. What
+changes is that the suite no longer has an opinion about build state at all.

packages/services/service-settings/vitest.config.ts

@@ -15,12 +15,23 @@
 // adapter), which pulls `resolveAuthzContext` from core — so core became
 // newly reachable from the package's tests and the gate named it.
 //
-// Only those two are aliased, deliberately. The package's other workspace
-// imports (`@objectstack/platform-objects`, `@objectstack/spec`,
-// `@objectstack/types`) are its registered set in that gate's
-// `KNOWN_UNALIASED_TEST_IMPORTS`; the registry is audited for set EQUALITY in
-// both directions, so aliasing them here is a separate, deliberate shrink and
-// not a rider on a P0 security fix.
+// #8104 finished the job for the remaining three — `@objectstack/spec`,
+// `@objectstack/platform-objects` and `@objectstack/types` — and with them this
+// package's entry in `KNOWN_UNALIASED_TEST_IMPORTS` came off. That registry is
+// audited for set EQUALITY in both directions, so deleting the entry is half of
+// that change rather than its cleanup: the aliases below and the absence of the
+// entry each fail the gate without the other.
+//
+// ⚠️ What the shrink actually required, measured rather than assumed: this
+// package imports NO bare `@objectstack/spec` and NO bare
+// `@objectstack/platform-objects` at run time. Every specifier its tests can
+// reach for those two is a SUBPATH — `spec/api`, `spec/contracts`, `spec/data`,
+// `spec/system`, `platform-objects/system` — joined by `spec/security`, reached
+// transitively through `@objectstack/types` ([ADR-0105 D1] tenancy posture)
+// once types itself resolves to source. An anchored BARE pattern
+// (`/^@objectstack\/spec$/`) matches none of them, so copying #8063's
+// two-entry shape would have left all of them on `dist` with the registry entry
+// undeletable. The subpath rules below are the load-bearing half.
 import { defineConfig } from 'vitest/config';
 import path from 'path';
 
@@ -43,6 +54,40 @@ export default defineConfig({
         find: /^@objectstack\/core$/,
         replacement: path.resolve(__dirname, '../../core/src/index.ts'),
       },
+      // `platform-objects` gets an EXPLICIT subpath entry rather than the
+      // one-rule-for-all-namespaces capture below, because its export map is
+      // not uniform: `./plugin` is `src/plugin.ts`, a FILE, while every other
+      // namespace is `src/<ns>/index.ts`. A `([a-z-]+)` rule would send
+      // `platform-objects/plugin` to `src/plugin/index.ts`, which does not
+      // exist — a path nobody wrote, failing on whoever adds that import.
+      // `plugin-audit` writes its `platform-objects/audit` entry the same way
+      // and for the same reason.
+      {
+        find: /^@objectstack\/platform-objects\/system$/,
+        replacement: path.resolve(__dirname, '../../platform-objects/src/system/index.ts'),
+      },
+      {
+        find: /^@objectstack\/platform-objects$/,
+        replacement: path.resolve(__dirname, '../../platform-objects/src/index.ts'),
+      },
+      // `spec`, by contrast, IS uniform — every namespace in its export map is
+      // `src/<ns>/index.ts` — so one rule covers all of them and cannot go
+      // stale when a new namespace import arrives. The capture group has to sit
+      // INSIDE the path, which is what forces the template literal here (the
+      // shape `service-knowledge` and `plugin-audit` already use, and the one
+      // the gate's canary fixture pins so a reader cannot misread it — #8020).
+      {
+        find: /^@objectstack\/spec\/([a-z-]+)$/,
+        replacement: `${path.resolve(__dirname, '../../spec/src')}/$1/index.ts`,
+      },
+      {
+        find: /^@objectstack\/spec$/,
+        replacement: path.resolve(__dirname, '../../spec/src/index.ts'),
+      },
+      {
+        find: /^@objectstack\/types$/,
+        replacement: path.resolve(__dirname, '../../types/src/index.ts'),
+      },
     ],
   },
 });

scripts/check-test-source-alias.mjs

@@ -302,9 +302,6 @@ const KNOWN_UNALIASED_TEST_IMPORTS = {
   '@objectstack/service-package': ['@objectstack/metadata-core'],
   '@objectstack/service-queue': ['@objectstack/objectql', '@objectstack/platform-objects'],
   '@objectstack/service-realtime': ['@objectstack/spec'],
-  '@objectstack/service-settings': [
-    '@objectstack/platform-objects', '@objectstack/spec', '@objectstack/types',
-  ],
   '@objectstack/service-sms': ['@objectstack/plugin-auth', '@objectstack/service-settings'],
   '@objectstack/service-storage': [
     '@objectstack/objectql', '@objectstack/observability', '@objectstack/platform-objects',