You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit bd29ec3
Browse filesBrowse the repository at this point in the historyBrowse files
fix(lint): refuse a present non-array stack.packages at all five recordsOf(stack.packages) readers
Ruling A on #15293 (comment 5634034754): a `packages` that is present but not
an array (`{}`, `0`, `'x'`, a keyed object) is malformed, not absent, and
every reader refuses it. Four `packages/lint` readers fell through
`recordsOf(stack.packages)` to `[]` instead of refusing:
`validate-object-references.ts`'s `artifactProvidedObjectNames`, and
`validate-translation-references.ts`'s `contributedNavItemsByApp`,
`objectExtensionsByTarget` and `artifactProvidedRecords`. A fifth copy of the
same pattern (`validate-mapping-target-fields.ts`'s `extensionFieldsByTarget`)
landed via #20208 after this ruling's site census and is fixed the same way.
All five now share one small reader, `packagesOf(stack)`
(`object-graph.ts`): absent stays `[]`, an array is read exactly as
`recordsOf` read it (junk entries dropped, unchanged), and anything else
present throws `INVALID_ARTIFACT_PACKAGES` (ADR-0112, status 422) -- the same
registered code `@objectstack/core`'s `resolveArtifactPackageOrder` already
raises for the identical defect. `recordsOf` itself is untouched: it stays
the shared map-or-array reader `objects`/`sections`/`tabs` need, where a
keyed map is legitimate -- `packages` never has a map form, so this is a
second, narrower reader rather than a branch on the first one.
Pins: `packagesOf` is pinned exhaustively (array control, absent/null
silence, refusal on `{}`/`0`/`'x'`/a keyed object, with code + status). Each
of the three public functions these readers sit behind
(`validateObjectReferences`, `validateTranslationReferences`,
`validateMappingTargetFields`) gets one throw-pin proving the wiring reaches
the shared reader. One existing pin asserted the old fall-through semantics
(`validate-object-references.test.ts`, "ignores a `packages` value that is
not a list of entries") and is flipped: `null` stays a silence control,
`42`/`'core'` now assert the refusal.
Co-authored-by: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QcAS3qiYYZNezaxZxaUdMV
`packages/lint`'s four `stack.packages` readers (plus a fifth added by #20208 after this ruling's own site census) now refuse a PRESENT non-array `packages` — `{}`, `0`, `'x'`, or a keyed object — the same way `@objectstack/core`'s `resolveArtifactPackageOrder` already does, instead of silently reading it as "no packages" (#20206, ruling A on #15293, comment 5634034754).
6
+
7
+
Clause-②: no (narrowing)
8
+
9
+
<!-- adr-0087: not-required (no-migration-prescription) an already-malformed `packages` value is refused rather than converted; no key, export or stored value moves, and nothing in this repo emits the shape today -->
10
+
11
+
-**What changes**: `validateObjectReferences`, `validateTranslationReferences` and `validateMappingTargetFields` (the three public `@objectstack/lint` functions these readers sit behind) now throw an `INVALID_ARTIFACT_PACKAGES` error (ADR-0112, `status: 422`) instead of returning findings, when the stack they are handed carries a `packages` key that is present but not an array. `os validate` / `os lint` / `os build` surface it as a refusal on stderr (and in `error`/`code` under `--json`) instead of reporting the stack as clean.
12
+
-**What does not change**: an absent `packages`, and `packages: null`, are still read as "no packages" — unchanged, and #19926's surface, not this one. A well-formed `packages[]` array is read exactly as before, junk entries dropped exactly as before.
13
+
-**Fix**: write `packages` as an array of `{ manifest: … }` entries, or omit the key entirely for a single-package stack.
0 commit comments