[cmm-cmm]

Summary

Three related pieces of work on the way to 0.7.0, in five commits.

1. Appearance: per-component color, corner radius, and hover

appearance previously reached only the dialog surface and backdrop. It now scopes styling per component, and adds two things that were not adjustable at all:

• Per component — surfaceColor, titleColor, titleBackground, titleOpacity, contentColor, contentOpacity, borderColor, borderOpacity. The title and body had no color of their own; the header had no background.
• radius — corner rounding was fixed to the global --fd-radius token. It now takes one value for every corner, any CSS border-radius value, or a per-corner object whose omitted corners keep the theme radius.
• shadow — still accepts a preset or a raw box-shadow, and now the parts of one: angle picks the direction the shadow falls (0 up, 90 right, 180 down, 270 left), plus distance, blur, spread, color, opacity, inset.
• hover — applied only while the pointer is over the dialog, and only for dialogs that opt in, so every other dialog stays static. Same color and shadow options plus lift, scale, duration. Honours prefers-reduced-motion.

Four bugs found by testing rather than by reading:

• Hover rules had to set real CSS properties instead of redefining the --fd-dialog-* custom properties. Those are written as inline styles by applyAppearance, and an inline declaration beats a stylesheet rule on the same element, so the first implementation silently never applied hover colors. box-shadow and transform worked, which is what exposed it.
• A hover lift or scale resizes the box the drag logic clamps against, letting a dragged dialog escape the viewport. Hover transforms are suspended while dragging. The existing drag bounds test caught this.
• Substituting the radius variable twice — as the bottom sheet did to square its lower corners — expands a per-corner value into ten lengths and voids the declaration, leaving the sheet with no rounding at all. Measured in a browser: 0 0 0 0 before, 24px 24px 0 0 after. Squared with longhands instead.
• import 'forgedialog/appearance' was silently a no-op. Capabilities register through a bare side-effectful import, which a bundler keeps only when the resolved file is named in sideEffects. ESM code splitting had moved the registerAppearanceApplier call into a shared chunk, and a chunk name cannot be listed there. forgedialog/interactions and forgedialog/animations escaped this only through how their code happened to be chunked, not by design. Entries are now published unsplit.

Budgets had almost no headroom left (index.cjs 0.09 KiB under, the alert-only fixture 0.02 KiB, interactions.cjs 0.04 KiB), so ordinary changes tripped them. They are widened across the board. With that room, forgedialog and forgedialog/core both ship the full appearance applier, so nothing needs an extra import; the single-purpose entries keep the lightweight one and the alert-only fixture is unchanged at 5.48 KiB.

2. Community health files

The community profile had only a README and a license. Added CONTRIBUTING.md, SECURITY.md, CODE_OF_CONDUCT.md (Contributor Covenant 2.1), issue forms, and a pull request template.

These document the repository's actual workflow rather than a generic one: the validate gate, when API reports and changesets must be refreshed, why capabilities register through side-effectful imports, that bundle budgets are enforced, and that computed-style behaviour belongs in e2e because jsdom has no cascade. SECURITY.md scopes reports and names unsafeHtml as out of scope, since it is documented as trusted-input-only and sanitizes nothing by design.

Contact points route to GitHub's private vulnerability reporting rather than an email address, so no personal address is published without the maintainer choosing to. Private vulnerability reporting must be enabled in Settings → Security for those links to work.

format:check now runs Prettier over the whole repository instead of a hand-maintained path list — which is exactly why new root-level files were not covered by it.

3. npm release pipeline

The release workflow published with a bare npm publish --access public and inherited whatever npm shipped with Node — the very thing trusted publishing depends on, and a version that varies by Node patch release. It also had no guard against a tag and package.json disagreeing.

• The workflow now installs a current npm explicitly and logs the version.
• New scripts/check-release.mjs verifies the tag matches package.json, the package is not private, required metadata is present, and that version is not already on the registry, where versions are immutable and a duplicate would otherwise fail mid-release. A registry outage warns rather than fails, since npm refuses duplicates on its own.
• publishConfig.access is public; CHANGELOG.md now ships in the tarball.
• docs/releasing.md covers cutting a release and the one-time setup this automation cannot do.

Three things still need a human, all documented in docs/releasing.md: create the npm environment, add the trusted publisher on npmjs.com, and set the NPM_PUBLISH_ENABLED repository variable. Until that last one is true, the release workflow runs every check and deliberately publishes nothing.

One caveat stated honestly: npm configures trusted publishers from a package's settings page, which normally requires the package to exist, and forgedialog is unpublished (registry returns 404). That could not be verified from primary sources here because docs.npmjs.com is blocked by this environment's egress proxy, so the document flags it and gives the token-based first publish as a fallback rather than asserting either way.

Test plan

• npm run validate passes end to end
• npm test — 172 tests pass, up from 162
• npm run test:capabilities — verified it actually catches the bundler bug: fails on core and appearance with splitting re-enabled, passes with it off
• npm run check:release — verified all three paths: no tag (pass), matching tag (pass), mismatched tag (fails with a clear message)
• npx playwright test --project=chromium — 15 passed, 1 skipped (mobile-only), against the pre-installed Chromium
• Browser e2e added for hover restyling and reverting, shadow direction following angle, per-corner radius across modal/sheet/drawer shapes, and the header background reserving its padding
• Issue form YAML validated with a parser
• publint clean, attw green across all four resolution modes, tarball 119.9 kB / 71 files
• Manually verified in Chromium and checked against screenshots: title red → orange on hover, body green at 0.5 opacity, border purple → orange, shadow cast right at 90° and left at 270°, dialog lifting 8px and scaling 1.02, top-left corner at 40px while the others stay 4px, header background clipped by the corners

The visual regression baseline was refreshed once. That snapshot covers the whole demo page and the appearance builder gained controls, so the page got taller and the dialog shifted. Confirmed this was a fixture change and not a rendering regression: with the library changes but the original demo page, alert visual remains stable passed untouched — and CI's own browser then accepted the regenerated baseline.

Note: npm run test:e2e cannot run unmodified in the dev environment used here — the pinned @playwright/test wants browser build 1228 while only 1194 is installed, and downloads are disabled. The suite was run against the pre-installed Chromium via an executablePath override; CI installs its own browsers and passes.

🤖 Generated with Claude Code

https://claude.ai/code/session_01MtJ3nDatGiv7dHjvZL1uZ4

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}