develop
5
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Claude
|
f56d2811cb |
📦 docs: cereale is on npm, and release.yml moves to trusted publishing
0.4.0 published, so the three places that said it had not stopped being true: the README install section, the landing page's install panel, and the "what cereale is not" item. All three now say `npm install cereale`, and the last becomes a limitation that is actually still true — it is 0.x, where a minor bump is allowed to break you. An npm version badge joins the row, tinted the same brand brown as the rest. It was held back deliberately while the package did not exist, because a badge that renders "not found" is worse than no badge. page.js loses the install-shell substitution: it rewrote the tarball filename in a code block that no longer exists. --- release.yml: trusted publishing --- npm exchanges the workflow's short-lived GitHub identity token for a publish token scoped to this package, so no long-lived npm token has to exist. The header documents exactly what to enter on npmjs.com, including the two fields npm checks against the OIDC claims and refuses on mismatch: the workflow filename must match this file, and Environment must stay blank while the job declares none. The find that matters: Node 22 bundles npm 10.x, which has no OIDC code at all. Verified by unpacking the CLI — lib/utils/oidc.js is absent in 11.4.2 and present in 11.5.0. Since npm's OIDC step is deliberately non-throwing, an old CLI would have skipped trusted publishing in silence and fallen back to token auth while appearing to work. So the workflow raises npm and then asserts the version, rather than assuming it. NPM_TOKEN stays as a fallback for the same non-throwing reason: this can land before the registry side is configured, and nothing breaks. Delete the secret once a real run shows OIDC working. --provenance stays explicit. Under OIDC npm enables it itself for a public repo, but only when the flag is left at its default (config.isDefault check in oidc.js), so passing it just skips that auto-enable and lands in the same place — while remaining the only thing that produces an attestation on the token path. actionlint clean; the version guard tested against 10.9.7, 11.4.2, 11.5.0 and 12.0.2; the page re-rendered with no errors and no "not on npm" text left. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SAcqrz3FcadkYr3xG32CjK |
||
|
Claude
|
4b910f19bf |
🔍 fix: apply the code review — two visible regressions, and the gates behind them
Nine review angles, fourteen verified findings, all but the byte-table generator applied. The two that mattered most were regressions of mine: - a:hover repainted button-styled anchors, and in dark theme --accent-text equals --accent-solid — hovering the hero CTA drew its label in its own background colour. Verified invisible before (computed color == computed background) and distinct after: 10.39:1 dark, 6.90:1 light. The buttons and the skip link now re-assert their label colours on hover. - Footer links had lost every non-hover affordance: the text-decoration:none carve-out plus body-coloured links left a 2.37:1 shade difference as the only cue. The carve-out is deleted — .nav-links a and .brand already declare none themselves — and the accent rule is back on the footer. Also on the page: #ref-filter, the one text input, moves to --border-ui (it still had the 1.68:1 border the token's own comment calls decorative); focusable code surfaces get the --accent-on-code ring at -2px offset, inside the .code overflow clip; #output .out-err drops #ff8095, the last surviving colour of the deleted indigo palette; the two rgba(255,106,126) washes become color-mix over --err-line so a grep for the token finds them. The theme machinery loses a whole block: the dark media query is guarded with :not([data-theme="light"]), so an explicit light toggle falls through to the bare :root palette and the 21-token hand-copy in [data-theme="light"] is gone. Verified in all four system/toggle combinations. The page stops contradicting the repo: it claimed cereale/min "cannot tree-shake — nothing left to shake" while src/treeshake.test.ts proves the opposite on every run. Corrected here and in FRAMEWORKS.md, with the measured figures (1,837 vs 1,996 bytes for one decorator). The release facts the page was hand-bumping — both tgz names, "0.4.0 lives in the repository", the sixty-eight — now fill from meta.js/the bundle like the version badge always has. The workflows close three holes: - The docs sync gate was blind to NEW untracked build outputs (git diff does not report them; demonstrated). Both workflows now run check:docs-sync, one shared script that fails on anything porcelain reports — which also ends the copy-paste divergence between them. - pages.yml deploys on CI succeeding on main (workflow_run) instead of on the push itself, so a deploy implies green tests, not just in-sync docs. The deploy job refuses refs other than main, closing the workflow_dispatch any-branch deploy, and the build job drops pages/id-token — npm postinstall scripts no longer run alongside an OIDC grant. - The Junie action is pinned to the commit behind v1.7.4 rather than the tag, which is the immutability the previous comment promised but a mutable ref cannot deliver. Verified: every fix confirmed in a rendered browser in both themes; 72 contrast pairs still pass; no overflow at 20 widths; 268 tests, build, check:types, check:docs, actionlint all green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SAcqrz3FcadkYr3xG32CjK |
||
|
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
|
||
|
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 |
||
|
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
|