cereale

34 Commits 5 Branches 6 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
Claude	057f008ac0	🔍 fix: correct the last three findings from the page review Of 26 findings raised across five auditors, 23 were refuted on a second pass. These three survived. A renamed property's old key is still writable. The README, the landing page and two doc comments all said that once a property carries @JsonProperty its original name "is no longer accepted on input". It is no longer mapped — but it is not rejected either. Unlike @JsonReadOnly, whose JSON name goes into the blocked set, the old key falls through to the unknown-key policy, and the default `allow` copies it onto the instance untouched. Reproduced against dist: @JsonProperty('home_address') @JsonType(() => Addr) @ValidateNested() address!: Addr; toInstanceSync(Order, { address: { city: 'Paris' } }) -> address is a plain object, instanceof Addr === false -> validateSync() returns [] <- nothing complains -> round-trips out as home_address <- silently accepted Blocking the old key would fix it, but would also swallow the `unknownKeys: 'error'` report a strict caller gets today, which is arguably the more useful signal. That is a judgement call the library has not made, so this commit states the behaviour accurately everywhere it was stated wrongly and pins it with five tests covering the default, `strip`, `error` and the @JsonAlias fix — so it cannot drift either way while the question is open. @IsNotEmpty and @IsEmpty are not complements. `[]` and `{}` pass BOTH: isNotEmpty checks only null/undefined/'' while isEmpty also treats empty arrays and objects as empty. Listed one line apart as "must not be empty" / "must be empty", they invited exactly the wrong inference. unknownKeys is deserialization-only, in a group whose blurb says these apply per call or via configure(). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SAcqrz3FcadkYr3xG32CjK	2026-08-05 10:33:45 +00:00
Claude	8c9aea3062	📐 fix: correct what the adversarial review of the page found Five auditors read the finished page against the source; a second pass tried to refute each finding. What survived: The esbuild row was wrong, and dangerously so. It said esbuild takes "the same settings via tsconfigRaw" as tsc. It does not: esbuild lowers standard decorators only when its own top-level `target` is below `esnext`. A `target` inside `tsconfigRaw` sets the `useDefineForClassFields` default and nothing else. I ran it — the decorator survives verbatim and the module throws SyntaxError on import, which is the exact silent passthrough the section blames on oxc. The repo's own vite plugin and toolchain test always passed `target` top-level, so the executed matrix never backed the advice the docs gave. Both halves are now asserted in src/toolchain.test.ts. "This table is executed by a test" did not cover the oxc row — the only ✗, and the row the whole section is built around. It cannot be: oxc ships as a native binary with no standalone transform API, which the test file already said in a comment. Fixed on the page and in the README. Reference corrections, each verified against the source: - fromRequest has no …Sync twin; the group blurb claimed every entry did - @IsNotIn does not narrow its field, unlike its five neighbours - @MinDate/@MaxDate take a Date as well as a thunk - @Validate has three parameters, not two; defineRule has four - getConfig() and resetConfig() were missing from a group rendered under the heading "Everything cereale exports" And on the page itself: the vite.config.ts snippet never imported defineConfig, so pasting it failed; and the plugin note omitted that .tsx is excluded by default, which would drop a reader straight back into the 0-test hole the section exists to describe. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SAcqrz3FcadkYr3xG32CjK	2026-08-05 10:12:29 +00:00
Claude	c828f5cfe9	🌾 feat: rebuild the landing page, and stop it from rotting again The old page had been quietly broken for some time. It loaded @babel/standalone from an unpinned CDN URL, which rolled over to Babel 8 and dropped the `proposal-class-properties` plugin the page asked for, so Babel.transform threw before it ever reached the decorators — and the decorator config it passed was `{ legacy: true }`, which 0.2.0 had already made wrong. Nothing on the page said so. The copy was still selling the 0.1.0 pitch ("Spring-like"), listed about half the decorators, showed `npm install cereale` for a package the registry returns 404 for, and claimed "Zero overhead" against a README that publishes the real microsecond costs. The rebuild is one self-contained page: hand-written CSS, no Tailwind CDN, no CodeMirror, and a vendored compiler pinned by package.json. It loads nothing from the network. The playground runs the real bundled library across six examples, all verified in a headless browser. The reference covers all 68 decorators and the full API, counted from the bundle at runtime so it cannot drift. The hero's compiler error is not typed into the HTML. scripts/build-docs.mjs compiles the snippets with the real tsc and writes the verbatim diagnostics into docs/diagnostics.js, failing the build if a snippet the page calls a compile error ever compiles — and two snippets that must compile guard against the harness passing vacuously. Three guards keep it honest, all wired into CI: - check:docs fails on any remote subresource - build:docs + git diff fails if docs/ is stale against src/ - check:types compiles a consumer against dist/ with no DOM lib, no @types/node and no skipLibCheck That last one found a real packaging defect: `fromRequest` was declared as taking the global `Request`, so cereale's own published .d.ts raised "Cannot find name 'Request'" in any project whose lib and types did not happen to supply it — inside a dependency, in code they may never call, and unfixable from the outside. It now takes a structural JsonBody, which a Request still satisfies. The library's own type tests had been hiding it by enabling both DOM and skipLibCheck. An adversarial review of the finished page caught four more: the lede claimed every rule is type-checked (@IsDefined and @IsNotIn deliberately are not), the guarantee section was wrong about the mechanism (a legacy decorator does get design:type under emitDecoratorMetadata — the real claim is about its type signature), one sample called a Movie method on a Media[] and did not compile, and "nested objects come back as real classes" omitted that you have to declare them. WCAG contrast was measured rather than eyeballed: seven real failures fixed in the two themes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SAcqrz3FcadkYr3xG32CjK	2026-08-05 10:03:16 +00:00

Author

SHA1

Message

Date

Claude

057f008ac0

🔍 fix: correct the last three findings from the page review

Of 26 findings raised across five auditors, 23 were refuted on a second
pass. These three survived.

**A renamed property's old key is still writable.** The README, the landing
page and two doc comments all said that once a property carries
@JsonProperty its original name "is no longer accepted on input". It is no
longer *mapped* — but it is not rejected either. Unlike @JsonReadOnly,
whose JSON name goes into the blocked set, the old key falls through to the
unknown-key policy, and the default `allow` copies it onto the instance
untouched. Reproduced against dist:

  @JsonProperty('home_address') @JsonType(() => Addr) @ValidateNested()
  address!: Addr;

  toInstanceSync(Order, { address: { city: 'Paris' } })
    -> address is a plain object, instanceof Addr === false
    -> validateSync() returns []          <- nothing complains
    -> round-trips out as home_address    <- silently accepted

Blocking the old key would fix it, but would also swallow the
`unknownKeys: 'error'` report a strict caller gets today, which is arguably
the more useful signal. That is a judgement call the library has not made,
so this commit states the behaviour accurately everywhere it was stated
wrongly and pins it with five tests covering the default, `strip`, `error`
and the @JsonAlias fix — so it cannot drift either way while the question
is open.

**@IsNotEmpty and @IsEmpty are not complements.** `[]` and `{}` pass BOTH:
isNotEmpty checks only null/undefined/'' while isEmpty also treats empty
arrays and objects as empty. Listed one line apart as "must not be empty" /
"must be empty", they invited exactly the wrong inference.

**unknownKeys is deserialization-only**, in a group whose blurb says these
apply per call or via configure().

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SAcqrz3FcadkYr3xG32CjK

2026-08-05 10:33:45 +00:00

Claude

8c9aea3062

📐 fix: correct what the adversarial review of the page found

Five auditors read the finished page against the source; a second pass
tried to refute each finding. What survived:

**The esbuild row was wrong, and dangerously so.** It said esbuild takes
"the same settings via tsconfigRaw" as tsc. It does not: esbuild lowers
standard decorators only when its own *top-level* `target` is below
`esnext`. A `target` inside `tsconfigRaw` sets the
`useDefineForClassFields` default and nothing else. I ran it — the
decorator survives verbatim and the module throws SyntaxError on import,
which is the exact silent passthrough the section blames on oxc. The
repo's own vite plugin and toolchain test always passed `target`
top-level, so the executed matrix never backed the advice the docs gave.
Both halves are now asserted in src/toolchain.test.ts.

**"This table is executed by a test" did not cover the oxc row** — the
only ✗, and the row the whole section is built around. It cannot be:
oxc ships as a native binary with no standalone transform API, which the
test file already said in a comment. Fixed on the page and in the README.

Reference corrections, each verified against the source:
- fromRequest has no …Sync twin; the group blurb claimed every entry did
- @IsNotIn does not narrow its field, unlike its five neighbours
- @MinDate/@MaxDate take a Date as well as a thunk
- @Validate has three parameters, not two; defineRule has four
- getConfig() and resetConfig() were missing from a group rendered under
  the heading "Everything cereale exports"

And on the page itself: the vite.config.ts snippet never imported
defineConfig, so pasting it failed; and the plugin note omitted that
.tsx is excluded by default, which would drop a reader straight back
into the 0-test hole the section exists to describe.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SAcqrz3FcadkYr3xG32CjK

2026-08-05 10:12:29 +00:00

Claude

c828f5cfe9

🌾 feat: rebuild the landing page, and stop it from rotting again

The old page had been quietly broken for some time. It loaded
@babel/standalone from an **unpinned** CDN URL, which rolled over to Babel
8 and dropped the `proposal-class-properties` plugin the page asked for, so
Babel.transform threw before it ever reached the decorators — and the
decorator config it passed was `{ legacy: true }`, which 0.2.0 had already
made wrong. Nothing on the page said so. The copy was still selling the
0.1.0 pitch ("Spring-like"), listed about half the decorators, showed
`npm install cereale` for a package the registry returns 404 for, and
claimed "Zero overhead" against a README that publishes the real
microsecond costs.

The rebuild is one self-contained page: hand-written CSS, no Tailwind CDN,
no CodeMirror, and a vendored compiler pinned by package.json. It loads
nothing from the network. The playground runs the real bundled library
across six examples, all verified in a headless browser. The reference
covers all 68 decorators and the full API, counted from the bundle at
runtime so it cannot drift.

The hero's compiler error is not typed into the HTML. scripts/build-docs.mjs
compiles the snippets with the real tsc and writes the verbatim diagnostics
into docs/diagnostics.js, failing the build if a snippet the page calls a
compile error ever compiles — and two snippets that must compile guard
against the harness passing vacuously.

Three guards keep it honest, all wired into CI:
- check:docs fails on any remote subresource
- build:docs + git diff fails if docs/ is stale against src/
- check:types compiles a consumer against dist/ with no DOM lib, no
  @types/node and no skipLibCheck

That last one found a real packaging defect: `fromRequest` was declared as
taking the global `Request`, so cereale's own published .d.ts raised
"Cannot find name 'Request'" in any project whose lib and types did not
happen to supply it — inside a dependency, in code they may never call, and
unfixable from the outside. It now takes a structural JsonBody, which a
Request still satisfies. The library's own type tests had been hiding it by
enabling both DOM and skipLibCheck.

An adversarial review of the finished page caught four more: the lede
claimed *every* rule is type-checked (@IsDefined and @IsNotIn deliberately
are not), the guarantee section was wrong about the mechanism (a legacy
decorator does get design:type under emitDecoratorMetadata — the real claim
is about its type signature), one sample called a Movie method on a Media[]
and did not compile, and "nested objects come back as real classes" omitted
that you have to declare them. WCAG contrast was measured rather than
eyeballed: seven real failures fixed in the two themes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SAcqrz3FcadkYr3xG32CjK

2026-08-05 10:03:16 +00:00