Skip to content

[finding] @objectstack/metadata has no typecheck script, and its own tsconfig program does not compile: 89 pre-existing errors across 12 test files, checked by nothing #14342

Description

@os-musk

Observation-class finding, measured while implementing #14205 (PR #14340). Filed unassigned; nothing was changed for it.

Same shape as #13978 (@objectstack/metadata-protocol, closed) but a different package, so this is a sibling instance rather than a duplicate.

Measured

packages/metadata/package.json declares build, dev, clean, test, test:watch, test:coverage — and no typecheck. The root pnpm typecheck is turbo run typecheck, which selects only packages that declare the task, so this package is never selected.

packages/metadata/tsconfig.json nevertheless declares a program over the whole source tree:

{ "include": ["src/**/*"], "exclude": ["node_modules", "dist"] }

Run it and it does not compile. On 909a441 plus the #14205 branch, tsc --noEmit -p packages/metadata/tsconfig.json reports 89 errors, none of them in any file that branch touches:

file errors
src/metadata.test.ts 34
src/register-notifies-watchers.test.ts 16
src/metadata-manager-cluster.test.ts 9
src/metadata-service.test.ts 8
src/loaders/database-loader.test.ts 7
src/serializers/serializers.test.ts 3
src/plugin-hmr-reload.test.ts 3
src/metadata-history.test.ts 3
src/plugin.test.ts 2
src/metadata-realtime-events.test.ts 2
src/utils/lru-cache.test.ts 1
src/loaders/overlay-index-single-producer.test.ts 1

Every one is in a test file, and they are the two mundane kinds: TS2835 (a relative import written without the .js extension that nodenext requires) and TS7006 (an implicitly-any callback parameter). The shipped sources are clean.

Why it is worth a card

The type coverage this package actually has is the tsup DTS build, which compiles the entry points and reaches no test file. So a test file here is checked by exactly two things: vitest at runtime, and — per the repo's own recorded measurement in eslint.config.mjs — not ESLint, which "never enables type-aware linting (no parserOptions.project, no typed @typescript-eslint rules) for ANY file, test or not".

The concrete cost is that a test asserting on a wrongly-shaped object cannot be caught at author time in this package, which is the failure mode the repo's declared-equals-enforced posture exists to prevent. The secondary cost is that the checked-in tsconfig.json reads like a live check and is not one: an agent (this one) reasonably ran it as a gate and had to spend a measurement establishing that the 89 reds were pre-existing rather than its own.

Suggested shape, for triage to weigh

Either make the declaration true or narrow it — the point is that the two stop disagreeing:

  1. Repair the 89 (mechanical: add .js extensions, type the callback params) and add a typecheck script so turbo run typecheck selects the package and holds it.
  2. Or, if test files are deliberately outside this package's type program, say so in tsconfig.json with an exclude for **/*.test.ts, matching the packages that already do this — then the config stops claiming coverage it does not provide.

Option 1 is the one consistent with the repo's direction, and it is what #13978 chose for the sibling package. Option 2 is cheaper and still removes the false signal. Not something I should pick unasked, since it decides how much type safety this package's tests get.

Related: #13978 (same shape, @objectstack/metadata-protocol), #14205.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions