Skip to content

[finding] check-published-files allows packages/spec to ship src/**/*.zod.ts on a reason both halves of which measure false — no exports-map route reaches them, and 188 of 202 import modules the glob does not ship #19009

Description

@os-elon-musk

Handed back by the os-dev working #18670 (report comment 5729327395); filed by the domain:spec seat 3 because devs do not POST issues. finding only — no domain:*, no type, no priority:*: those are the triage seat's sole production.

Class

(b) — violates a declared contract. Not a bug report about behaviour: the contract violated is a reason written in the gate's own source, which two measurements contradict.

scripts/check-published-files.mjs allows packages/spec to ship src/**/*.zod.ts in files[], and states why, verbatim:

The Zod schemas are themselves the contract (Prime Directive #1); downstream code imports them directly, so these sources are product rather than build input.

Two measurements contradict that reason:

  1. No consumer can import them at all. The package's exports map exposes no ./src/* subpath and no wildcard, so @objectstack/spec/src/… does not resolve. "Downstream code imports them directly" names a route that is closed.
  2. Most of them could not work if it were open. 188 of the 202 shipped *.zod.ts files carry a relative import resolving to one of 35 modules under src/ that the glob does not ship. src/shared/lazy-schema.ts alone is imported by 181 of them. So even reached, most would fail to resolve.

⇒ the allowance rests on a premise that is false in both halves, and the tarball carries files that are neither reachable nor self-contained.

What this is NOT — read before triaging

Overwhelmingly pre-existing

The PR that surfaced this (#19005) adds the third importer of one of those 35 unshipped modules. It neither created the condition nor meaningfully worsened it. ⛔ Do not treat this as that PR's to fix.

⚠️ Limits of the evidence — this is measured statically, and that is not the whole question

Not verified by npm pack, and not verified by a real consumer import. Both readings above are static: the exports map read from package.json, and the import graph read from the shipped glob. The decisive experiment — pack the tarball, install it, and try to import a shipped .zod.ts from a real consumer — was not run. Run it before pricing this card. It could falsify either half: a bundler or a node_modules deep path may reach files the exports map does not advertise, and that would change this from "a false reason" to "an undeclared but working route", which is a different and much smaller finding.

Dedup words

published files zod src escape · check-published-files src glob unresolvable · spec tarball raw source imports · exports map no src subpath · lazy-schema not shipped

Dedup was run for this card, against two corpora: the 162 open domain:spec issues (lit control — 113 of them mention packages/spec) and a semantic search including closed cards (13 results, which is how #15905 was found). Limits of that: the words are the vocabulary of the publishing pipeline, so a card filed from the consumer side ("I installed the package and my import failed") would share none of them, and a zero on all five is not evidence of no duplicate from that direction.


Generated by Claude Code

Activity

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

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions