chore: 🤖 initial css modules setup

[punkbit]

Why?

Provide the initial setup foundations for CSS Modules for migrating from Styled-Components in a sustainable and iterative manner.

This library will now use CSS Modules for styling and is distributed unbundled, giving your application full control over bundling and optimisations. This means you only include what you actually use, resulting in smaller bundle sizes and better performance!

⚠️ WARNING: Depends on #773 and #784; these should be merged first.

Regression risk assessment

The migration workflow provides visual regression tests, including changes to tests to include every relevant component state. For example, the following are implementations of it in practice:

chore: 🤖 support local visual regression testing via docker
#931

chore: 🤖 GitHub action for visual regression (development environment based [initial version])
#932

It ensures consistent visual regression snapshots by enabling local testing within a Dockerized environment. This prevents false positive diffs caused by operating system variations, e.g., macOS vs. linux.

Introduces a GitHub Action for visual regression testing within the CI/CD pipeline. Unlike our existing Chromatic implementation, which relies on Storybook stories and cloud-managed snapshots, this action executes tests using screenshots managed directly within the development environment (curated by author). This ensures snapshots remain tightly coupled with the implementation code.

It's important to note that the CI/CD process runs in every pull request contribution, under a matching Linux instance encountered in the local dev setup for an accelerated feedback loop.

Furthermore, these visual regression tests differ from the cloud-based regression testing Chromatic, as they're closer to local development setup, e.g. a contributor can run them in their environment immediately. Comparatively, the Chromatic setup provides feedback at a later stage of contribution, e.g. only running in the Cloud, causing the feedback loop to be much slower. While Chromatic automatically generates tests based on Storybook story screenshots, the local regression test suite allows the contributor to curate these for proper assessment and more in line with the intended implementation and behaviour checkup, e.g. can assess components singularly, compose scenarios with multiple components, and run interactive userflows to cause state changes.

Finally, it runs on Playwright but is adapted to Chromatic's extension, allowing for easier interchangeability.

Bug tracking

The Click UI has issues tracked, which can further any reports found during any test or release.

For example, during the migration process, there's an opportunity to snapshot and enhance checkups for proper testing against expected behaviour. If differences or unexpected behaviour's detected, these can be compared to the original Styled Component version and resolved comparatively, e.g. on visual regression testing, a local development suit is made available to help catch during time of contribution. Before, visual regression tests are solely base in Chromatic, which are autogenerated.

How?

• Process static CSS imports
• Stores raw stylesheets in distribution
• Makes distributed components import stylesheets from distribution
• Provide documentation

Preview?

demo-button-ss-to-css-migration-states.mov

Demonstrates computed CSS Module in DOM

Distribution showcasing Button.module.css (in-place)

dist
├── cjs
│   └── components
│       └── Button
│           ├── Button.cjs
│           ├── Button.cjs.map
│           └── Button.module.css
├── esm
│   └── components
│       └── Button
│           ├── Button.js
│           ├── Button.js.map
│           └── Button.module.css
└── types
    └── components
        └── Button
            └── Button.d.ts

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
click-ui	Ready	Preview, Comment	Feb 4, 2026 7:27pm

[changeset-bot]

🦋 Changeset detected

Latest commit: 60931e7

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@clickhouse/click-ui	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

Claude finished @punkbit's task in 3m 10s —— View job

---

Code Review — chore: initial CSS modules setup

Great work on this! The architecture is well thought-out — marking .module.css as external in the build, then copying them via viteStaticCopy so that the dist JS files import CSS co-located in the dist tree is a clean solution. The BEM naming, token usage, and prefers-reduced-motion support all look solid. Here are a few things worth addressing before merging.

---

🚨 Must Fix

• Button: The type prop shadows the native <button type="submit|reset|button"> attribute (Button.tsx:12). Because type is destructured before ...delegated, consumers can never pass type="submit" for form submission — it will be treated as a visual variant selector and silently dropped. The TODO comment in the code acknowledges this, but since this PR rewrites the component it's a good moment to fix it. Renaming the visual-variant prop to variant would be the breaking change needed (with a migration note). Fix this →

• Button loading shimmer — missing background-repeat: no-repeat on solid variants: The .button--empty.button--loading::before rule includes background-repeat: no-repeat (Button.module.css:231) but the primary, secondary, and danger shimmer rules do not (lines 218–237). Add it to the other three variants for consistent shimmer rendering. Fix this →

---

♿ Accessibility

• Button: aria-disabled={disabled || loading} will render aria-disabled="false" on every enabled button (Button.tsx:77). While technically valid, it pollutes the accessibility tree. Prefer aria-disabled={(disabled || loading) || undefined} so the attribute is omitted entirely when the button is interactive.

---

💡 Suggestions (non-blocking)

• Tests: No unit tests were added or updated for the migrated Button. The conventions require co-located tests (Button.test.tsx). Consider adding at minimum a smoke test that the loading state sets aria-busy and disabled, and that className merging works correctly.

• aria-busy when disabled but not loading: Currently aria-busy={loading} is correct, but aria-busy={false} is emitted on every non-loading button. Same pattern as aria-disabled above — use aria-busy={loading || undefined}.

• viteStaticCopy rename edge case: The rename function in vite.config.ts (lines 127–135) reassembles the relative path from the absolute srcPath by splitting on /src/. If a consuming project ever names a path segment src, this string-search would produce the wrong sub-path. Storing the glob root as a variable and using a path module for the relative calculation would be safer.

• Token bundle size: Both tokens-light.css and tokens-dark.css are unconditionally imported in ThemeProvider.tsx (~3,600 lines total). Since the dark tokens are only activated by [data-cui-theme="dark"] (set by ClickUIProvider via setRootThemeAttribute), this is functionally correct. Just worth noting for consumers who only ever use one theme — there's no escape hatch today.

---

Overall this is a well-structured foundation for the migration. The build pipeline approach (external CSS + static copy) is clever and the changeset with migration notes is appreciated. Resolve the type/variant naming and the shimmer inconsistency and this should be ready. 🙌

• Gather context and understand PR goals
• Read CONVENTIONS.md and CLAUDE.md
• Review Button component changes
• Review CSS module and token files
• Review build/vite config changes
• Review ThemeProvider and preview changes
• Compile findings

[workflow-authentication-public]

📚 Storybook Preview Deployed

✅ Preview URL: https://click-hbtuf53ux-clickhouse.vercel.app

Built from commit: 0c6765b7cfa72e60a78d4bebcc68d1c5526e3ffc