{"id":20102493,"url":"https://github.com/clickhouse/click-ui","last_synced_at":"2026-03-02T20:02:16.824Z","repository":{"id":157435957,"uuid":"615461459","full_name":"ClickHouse/click-ui","owner":"ClickHouse","description":"The home of the ClickHouse design system and component library.","archived":false,"fork":false,"pushed_at":"2026-02-23T19:38:58.000Z","size":10826,"stargazers_count":116,"open_issues_count":87,"forks_count":15,"subscribers_count":25,"default_branch":"main","last_synced_at":"2026-02-23T20:28:36.627Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"https://clickhouse.design/click-ui","language":"TypeScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/ClickHouse.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2023-03-17T18:47:19.000Z","updated_at":"2026-02-21T22:17:30.000Z","dependencies_parsed_at":"2026-02-23T14:04:31.856Z","dependency_job_id":"99dad4e7-7500-4349-a335-8745d2da474c","html_url":"https://github.com/ClickHouse/click-ui","commit_stats":null,"previous_names":[],"tags_count":260,"template":false,"template_full_name":null,"purl":"pkg:github/ClickHouse/click-ui","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ClickHouse%2Fclick-ui","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ClickHouse%2Fclick-ui/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ClickHouse%2Fclick-ui/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ClickHouse%2Fclick-ui/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/ClickHouse","download_url":"https://codeload.github.com/ClickHouse/click-ui/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ClickHouse%2Fclick-ui/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":29831700,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-02-25T15:41:19.027Z","status":"ssl_error","status_checked_at":"2026-02-25T15:40:47.150Z","response_time":61,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-11-13T17:31:24.907Z","updated_at":"2026-03-02T20:02:16.804Z","avatar_url":"https://github.com/ClickHouse.png","language":"TypeScript","readme":"\u003cp align=\"center\"\u003e\n  \u003ca href=\"https://clickhouse.com\" target=\"_blank\"\u003e\n    \u003cimg\n      alt=\"Clickhouse logo\"\n      src=\"./.repo/images/banner.jpg?202601211122\"\n    /\u003e\n  \u003c/a\u003e\n\u003c/p\u003e\n\n# Click UI\n\n[![Conventional Commits](https://img.shields.io/badge/Conventional%20Commits-1.0.0-blue.svg)](https://conventionalcommits.org)\n\nClick UI is the ClickHouse design system and component library. Our aim with Click UI is to provide an accessible, theme-able, modern, and attractive interface with which to experience the speed and power of ClickHouse.\n\nYou can find the official docs for the Click UI design system and component library at [clickhouse.design/click-ui](https://clickhouse.design/click-ui).\n\n## Overview\n\n* [Requirements](#requirements)\n* [Quick Start](#quick-start)\n* [Development](#development)\n  - [Generating design tokens](#generating-design-tokens)\n  - [Local development](#local-development)\n* [Tests](#Tests)\n  - [Functional tests](#functional-tests)\n  - [Visual regression tests](#visual-regression-tests)\n* [Storybook](#storybook)\n  - [Stories development server](#stories-development-server)\n  - [Public static site](#public-static-site)\n* [Distribution](#distribution)\n  - [Build](#build)\n  - [Use Click UI](#use-click-ui)\n  - [Deep imports support](#deep-imports-support)\n  - [Examples](#examples)\n* [Assets Management](#assets-management)\n  - [Convert SVG to React Component](#convert-svg-to-react-component)\n* [Changesets](#changesets)\n  - [Add a new changeset](#add-a-new-changeset)\n  - [Checking the changeset status](#checking-the-changeset-status)\n  - [Create a new version and changelogs](#create-a-new-version-and-changelogs)\n* [Release](#release)\n  - [Required admin permissions](#required-admin-permissions)\n  - [Create a new release pull request](#create-a-new-release-pull-request)\n  - [Publish](#publish)\n  - [Maintaining Multiple Versions](#maintaining-multiple-versions)\n  - [Release Cycle](#release-cycle)\n  - [Applying Fixes to Stable Versions](#applying-fixes-to-stable-versions)\n  - [Switching Release Modes](#switching-release-modes)\n* [Contributing](#contributing)\n  - [Conventional commits](#conventional-commits)\n\n## Requirements\n\n- Nodejs (\u003e= 22.12.x) as runtime\n- Yarn (\u003e= 4.5.3) for development, any other package manager in a host project\n\n## Quick Start\n\nInstall the package via npm or your favourite package manager:\n\n```sh\nnpm i @clickhouse/click-ui@latest\n```\n\nTo use Click UI, you must wrap your application in the provider. This ensures styles and themes are applied correctly across all components.\n\n```ts\nimport { ClickUIProvider, Title, Text } from '@clickhouse/click-ui'\n\nfunction App() {\n  return (\n    \u003cClickUIProvider theme=\"dark\"\u003e\n      \u003cTitle type=\"h1\"\u003eHello ClickHouse\u003c/Title\u003e\n      \u003cText\u003eStart building today!\u003c/Text\u003e\n    \u003c/ClickUIProvider\u003e\n  )\n}\n```\n\nFor more examples, including theme switching and configuration, see the [How to](#how-to-use) use section, or explore our design system at [clickhouse.design/click-ui](https://clickhouse.design/click-ui).\n\n## Development\n\nThe project uses yarn package manager for development.\n\nAfter cloning the repository change to the work directory and install the dependencies:\n\n```sh\nyarn\n```\n\n### Generating design tokens\n\nTokens are provided by a style directionary sourced from [tokens-studio](https://tokens.studio/).\n\nIt's expected to have theme tokens provided externally, e.g. Figma tokens-studio output is stored in the repository and a PR's opened. The assets are stored in the directory [./tokens/themes].\n\nOnce [./tokens/themes] files are updated or provided from exernal source, e.g. Figma, we must regenerate the tokens for consumption in the project.\n\nRun the command to generate tokens in the path `./src/theme/tokens/`:\n\n```sh\nyarn generate:tokens\n```\n\nOnce done, you must commit the changes.\n\nLearn more about tokens-studio [here](https://documentation.tokens.studio/).\n\n### Local development\n\nWe leverage Storybook as our primary development environment and documentation, see [Storybook](#storybook).\n\nYou can start the Storybook development server by:\n\n```sh\nyarn dev\n```\n\n\nWe do NOT maintain a separate development environment; our Storybook stories serve as the source of truth for component implementation.\n\n\u003e [!IMPORTANT]\n\u003e We operate collaboratively with the Product Design team. While stories reflect the current implementation (live), Figma files remain the source of truth for design research and decision-making. Changes are typically finalized in Figma before being implemented in code to ensure design-sync.\n\nBy avoiding local preview files, we ensure that component experimentation happens in isolation; free from application side effects and providing a live look at component interfaces and usage examples at time of writing.\n\n\u003e [!NOTE]\n\u003e To ensure stability, we utilize Visual Regression and Unit Testing, see [tests](#tests). When contributing features or tweaks, you're expected to include or update the relevant tests to maintain stability, e.g. remember the components are consumed by a number of applications.\n\nTo get started with the development playground, refer to the Storybook section [here](#storybook).\n\n## Tests\n\n### Functional tests\n\nThe package uses [vitest](https://vitest.dev/) and [react testing library](https://testing-library.com) for tests, e.g. functional tests.\n\n```sh\nyarn test\n```\n\n### Visual regression tests\n\nThe project uses [Chromatic](https://www.chromatic.com/) for visual regression testing of UI components.\n\nIt captures screenshots of Storybook and compares them across builds to detect unintended visual changes by:\n\n- Automated visual testing in GitHub CI/CD pipeline, e.g. storybook publish, UI tests\n- Leveraging storybook stories\n- Provides visual diff reviews and approval workflows\n- Helps catch UI bugs\n\nTo setup, you must get a team member project token.\n\nAdd the token as an environment variable to your environment preference or profile, e.g. `~/.zshrc`:\n\n```sh\nexport CHROMATIC_PROJECT_TOKEN=\u003cYOUR-TOKEN-HERE\u003e\n```\n\nOnce ready, you can run tests by:\n\n```sh\nyarn test:chromatic\n```\n\u003e [!NOTE]\n\u003e Chromatic does NOT generate a report in the terminal due to its cloud nature, which only outputs:\n\u003e - Build status, e.g. uploading or testing\n\u003e - Link to the cloud runner or dashboard\n\u003e - Exit code\n\nIf you need quicker iteration feedback, or more testing control during local development, read [here](./docs/tests/playwright.md)\n\n## Storybook\n\nThe component library provides a collection of ready-to-use components. We use [Storybook](#storybook) to showcase and document our components.\n\n### Stories development server\n\nStart the storybook development server:\n\n```sh\nyarn storybook\n```\n\nIt'll default to the location [http://localhost:6006](http://localhost:6006), if port available.\n\n### Build static site\n\nTo build a static version:\n\n```sh\nyarn storybook:build\n```\n\nOnce built, you can serve the static files by:\n\n```sh\nyarn storybook:serve\n```\n\n### Public Static Site\n\nThe latest static version's built and deployed automatically when contributing to `main` of [Click UI](https://github.com/ClickHouse/click-ui).\n\nOnce deployed it's available publicly at [clickhouse.design/click-ui](https://clickhouse.design/click-ui).\n\n## Changeset\n\nLearn to manage the versioning of changelog entries.\n\nThe following is a brief description of available commands to allow a person making a contribution make key decisions about their changes.\n\nIt'll generate a changeset, which is effectively two key bits of information:\n\n- A version type which follows [semver](https://semver.org/)\n- Change information placed in a changelog\n\nMake good use of this simple workflow to help us release new package versions more confidently.\n\n### Add a new changeset\n\nWhen contributing, declare an intent or describe the changes you're making or adding to a release by executing the `changeset:add` command.\n\nThe wizard will ask a few questions and generate a changelog entry for you:\n\n```sh\nyarn changeset:add\n```\n\nThe changesets tool keeps track of all declared changes in the `.changeset` directory.\n\nOnce completed, you must commit the changeset!\n\n### Checking the changeset status\n\nTo check if your branch contains a changeset:\n\n```sh\nyarn changeset:status\n```\n\n### Create a new version and changelogs\n\nTo consume all changesets, and update to the most appropriate semver version and write a friendly changelog based on those changesets, the following command is available:\n\n\u003e [!IMPORTANT]\n\u003e Consuming changesets is done automatically in the CI/CD environment. For this reason, you don't have to execute the command, as a contributor your single concern should be adding changesets to any relevant changes.\n\n```sh\nyarn changeset:version\n```\n\n## Distribution\n\nThe package is distributed as ESM.\n\n### Build\n\nTo build the distribution version of the package run:\n\n```sh\nyarn build\n```\n\n\u003e [!NOTE]\n\u003e Optimizations are responsability of consumer or host apps, e.g. they can't remove unused code if already minified it! We ship unminified code so their build tools can: analyse and remove what they don't need or dead code, debug more easily, compress everything together in one go instead of handling conflicting compression algorithms, etc.\n\n### Use Click UI\n\nNavigate to your app's work directory and add the package.\n\nHere, we use `yarn` but you can use your favorite package manager, e.g. pnpm.\n\n```sh\nyarn add @clickhouse/click-ui\n```\n\u003e [!NOTE]\n\u003e Click UI should be supported by react frameworks.\n\u003e If you run into any issues consuming it in your react app, report it [here](https://github.com/ClickHouse/click-ui/issues/new). Provide all important details, including information on how to replicate the issue!\n\nOnce installed, wrap the application with Click UI provider:\n\n```js\nimport { ClickUIProvider } from '@clickhouse/click-ui'\n\nexport default () =\u003e {\n  return (\n    \u003cClickUIProvider theme='light'\u003e\n      \u003cp\u003eHello world!\u003c/p\u003e\n    \u003c/ClickUIProvider\u003e\n  );\n}\n```\n\nAfter, you are able to import your favorite [Click UI components](https://clickhouse.design/click-ui).\n\n```js\nimport { ClickUIProvider, Title } from '@clickhouse/click-ui'\n\nexport default () =\u003e {\n  return (\n    \u003cClickUIProvider theme='light'\u003e\n      \u003cTitle type='h1'\u003eClick UI Example\u003c/Title\u003e\n    \u003c/ClickUIProvider\u003e\n  );\n}\n```\n\nTo learn more about individual components, visit [Click UI components](https://clickhouse.design/click-ui).\n\n### Deep imports support\n\nDeep imports are supported, you can import directly from path.\n\n\u003e [!WARNING]\n\u003e At time of writing, there are components that consume from theme provider, which means that these will fail when unwrapped. This will change in future versions.\n\n```ts\nimport { Button } from '@clickhouse/click-ui/Button';\n```\n\n### Examples\n\nHere's a quick copy and paste NextJS example with interactive components you can play:\n\n```ts\nimport { ClickUIProvider, Text, ThemeName, Title, Switch } from '@clickhouse/click-ui'\nimport { useState } from 'react'\n\nfunction App() {\n  const [theme, setTheme] = useState\u003cThemeName\u003e('dark')\n\n  const toggleTheme = () =\u003e {\n    theme === 'dark' ? setTheme('light') : setTheme('dark')\n  }\n\n  return (\n    \u003cClickUIProvider theme={theme} config={{tooltip:{ delayDuration: 0 }}}\u003e\n      \u003cSwitch \n        checked={theme === 'dark'} \n        onCheckedChange={() =\u003e toggleTheme()} \n        label=\"Dark mode\"\n      /\u003e\n\n      \u003cTitle type='h1'\u003eClick UI Example\u003c/Title\u003e\n      \u003cText\u003eWelcome to Click UI. Get started here.\u003c/Text\u003e\n    \u003c/ClickUIProvider\u003e\n  )\n}\n\nexport default App\n```\n\n## Assets management\n\nThe Click UI has image asset files, such as Flags, Icons, Logos and Payments.\n\nFiles are originally curated in the context of the design system Figma project. Once exported/sourced from the Figma project file these have to be transformed into the Click UI desired format, e.g. an SVG as a React Component.\n\n### Convert SVG to React Component\n\nWe provide an automated tool to convert SVG files to React components for Flags, Icons, Logos and Payments.\n\nLet's assume that you want to add a new logo. You are a macOS user and have stored the logo SVG file in your home **Downloads** directory, e.g. **/Users/MyUsername/Downloads**.\n\nIn the root of Click UI repository, you'd run:\n\n```sh\nyarn convert:logo ~/Downloads/click-ui.svg\n```\n\nOr provide explicit component name:\n\n```sh\nyarn convert:logo ~/Downloads/click-ui.svg Click_UI\n```\n\nAlternatively, you can replace `logo` in the command by the remaining assets types, e.g. `convert:flag` or `convert:icon`.\n\nFor more detailed instructions, see [converting SVG to React Components](./docs/converting-svg-to-react-components).\n\n## Release\n\n**TLDR;** Use the [Create a new release Pull Request](#create-a-new-release-pull-request) for automated process.\n\nYou're expected to [create a new version](#create-a-new-version-and-changelogs), which will consume all changesets, and update to the most appropriate semantic version (semver) based on those changesets; which also writes changelog entries for each consumed changeset file content.\n\nOnce the artifacts and version bump is completed, the package can be published to npm. Doing all of this manually can be tedious and prone to mistakes, as such, we have a GitHub action that creates a Pull request containing all of this for team review; And once approved, another GitHub action that publishes the package to npm and creates a GitHub release.\n\n### Required admin permissions\n\nThe repository administrator has to set correct permissions for changeset workflow to work, namely: GitHub repository workflow permissons and add GitHub ascitons as a trusted publisher in NPM package settings.\n\n#### GitHub Workflow Permissions\n\nThis workflow requires permissions to \"Create pull requests\", which can be configured in [workflow permissions](https://github.com/Clickhouse/click-ui/settings/actions).\n\nIf you don't have permission to change these settings, you can use workflow authentication to generate a GitHub token as described [here](https://github.com/apps/workflow-authentication-public). This will generate a short-lived access token that grants the workflow \"create pull requests\" permission.\n\nFor more detailed information about `actions/create-github-app-token`, see the documentation [here](https://github.com/actions/create-github-app-token).\n\n#### NPM Trusted publisher\n\nAdd GitHub actions as a trusted publisher on [NPM package settings](https://www.npmjs.com/package/@clickhouse/click-ui). Make sure you select the provider \"GitHub Actions\", enter the repository \"Clickhouse/click-ui\" and finally the workflow name as \"release-publisher.yml\".\n\n### Create a new release Pull Request\n\nConsuming changesets is done automatically in the CI/CD environmment.\n\nTo create a new release, locate the [create release](https://github.com/ClickHouse/click-ui/actions/workflows/create-release.yml) and use the interface to select the release type, e.g. release candidate (rc), testing, stable or latest.\n\nIt'll create a new Pull request for review, e.g. changelog, version bump, etc. There, you have the opportunity to make any further tweaks, refinements and check if everything's correct.\n\nYou can find the pull requests in the GitHub tab [Pull Request](https://github.com/ClickHouse/click-ui/pulls). E.g. let's say you're about to release v0.1.0-rc.1, you'd find `chore: 🤖 release v0.1.0-rc.1 (rc)`.\n\n\u003e [!WARNING]\n\u003e Releasing a \"stable\" or \"latest\" version requires that you have previously published a pre-release version (e.g. test or rc / release candidate). This process exists to help us maintain quality standards.\n\u003e Only promote a release to \"stable\" or \"latest\" when you are confident it is production-ready, e.g., after thorough testing and gathering feedback from users or consumers. Take extra caution with \"latest\" in particular, as it becomes the default version installed by users.\n\nOnce the pull request is approved and merged, it'll trigger the release of a new version to [npm registry](https://www.npmjs.com/package/@clickhouse/click-ui?activeTab=versions).\n\nThe process will also create a branch for long lived version maintenance support, e.g. `chore/v0.5.0-rc.1`.\n\n### Publish\n\nOnce you've reviewed the changelog entries and version changes, addressed all [Pull Request](#create-a-new-release-pull-request) comments and suggestions, and are confident everything looks correct, go ahead and **squash and merge** the pull request.\n\nMerging to `main` will automatically trigger the [release publisher](https://github.com/ClickHouse/click-ui/actions/workflows/release-publisher.yml), which will publish the package to npm. If successful, the new version will appear under the [@clickhouse/click-ui](https://www.npmjs.com/package/@clickhouse/click-ui?activeTab=versions) versions tab on npm, and a new [GitHub release](https://github.com/ClickHouse/click-ui/releases) will be created containing all generated release assets.\n\n### Maintaining Multiple Versions\n\nWe maintain long-lived branches for each version, so you can get fixes without upgrading:\n\n```sh\nmain → active development (latest features)\n├── chore/v2.2.x → maintenance for v2.2.x releases\n├── chore/v1.x.x → maintenance for v1.x.x releases\n└── chore/v0.5.x → maintenance for v0.5.x releases\n```\n\nHere's how it works:\n\nNew features and improvements land in main, while critical bugs and security fixes are backported to the relevant maintenance branch. We recommend tracking changes against a base minor branch (e.g. chore/v1.1.x rather than chore/v1.1.1) so that all patches within a minor version are consolidated in one place. Note that the branch naming convention may change in the future (e.g. to v1 or v1.x), but this is the current approach at the time of writing.\n\n\u003e [!NOTE]\n\u003e While some changes might only make sense for a specific version, it's best practice to source fixes from `main` whenever possible. This keeps versions aligned and reduces diversion over time. Otherwise, you must make sure that your changes are put in the main development branch.\n\nLet's say that you need something specific for an older version, you can work in version isolation without pulling in changes from active development.\n\nEach release gets tagged and lives on its own version branch, e.g. `v1.5.0` making it easy to apply patches without forcing you to upgrade to the latest version.\n\n#### Release Cycle\n\nOur releases start from the `main` branch and go through a simple two-step process to help ensure quality:\n\n**Pre-release (test/rc)**\n\n1. Create a pre-release pull request, e.g. a test or release candidate (rc)\n2. The team reviews and provides feedback\n3. Once approved and merged, our release publisher pushes it to npm, e.g. `1.2.5-test.1`\n4. You can find all pre-release versions in the [npm package versions tab](https://www.npmjs.com/package/@clickhouse/click-ui?activeTab=versions)\n\n**Production release (latest)**\n\n1. Once a pre-release has been tested and available on stage, you can promote it to production\n2. Create a \"latest\" release PR for team review\n3. After approval and merge, the publisher strips the pre-release suffix and publishes the final version, e.g. `1.2.5-test.1` becomes `1.2.5`\n\nThis workflow lets us test changes at any time before they reach production while keeping the process simple, inclusive and collaborative!\n\n#### Applying Fixes to Stable Versions\n\nTo keep active development moving while ensuring you can apply critical fixes when needed, the Click UI team recommends the following approach:\n\n1. Choose the version needing a fix (e.g. `chore/v0.5.0`)\n2. Apply your changes, like backporting a security fix or updating a design token\n3. Create a new release from that branch\n\nThis lets us experiment and iterate freely on Click UI while giving you or your team a quick path to deploy urgent fixes without waiting for the next major release cycle.\n\n\u003e [!WARNING]\n\u003e Always use `chore/vX.X.X` branches for maintenance work, not `changeset-release/v*` branches. The `changeset-release` branches are auto-generated during publishing, e.g. `changeset-release/v0.2.0-test.0`) and not meant for direct updates. All version-specific changes should go through `chore/vX.X.X` branches where the full commit history is tracked.\n\n#### Switching Release Modes\n\nA new changeset is required before switching between release modes.\n\nChangesets are how the release pipeline determines whether anything has actually changed between versions. Without one, promoting a release from one mode to another (for example, from `test` to `rc`) would produce a package that is identical in content but with a different version label, which is meaningless and potentially confusing.\n\nHere's what changes in package.json:\n\n```sh\n{\n  \"name\": \"@clickhouse/click-ui\",\n-  \"version\": \"1.1.0-test.1\",\n+  \"version\": \"1.1.0-rc.1\",\n  ...\n}\n```\nAlways include a changeset to ensure each promotion reflects real, trackable changes.\n\n### Conventional commits\n\nWe prefer to commit our work following [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0) conventions. Conventional Commits are a simple way to write commit messages that both people and computers can understand. It help us keep track fo changes in a consistent manner, making it easier to see what was added, changed, or fixed in each commit or update.\n\nThe commit messages are formatted as **[type]/[scope]**\nThe **type** is a short descriptor indicating the nature of the work (e.g., feat, fix, docs, style, refactor, test, chore). This follows the conventional commit types.\n\nThe **scope** is a more detailed description of the feature or fix. This could be the component or part of the codebase affected by the change.\n\nHere's an example of different conventional commits messages that you must follow:\n\n```txt\ntest: 💍 Adding missing tests\nfeat: 🎸 A new feature\nfix: 🐛 A bug fix\nchore: 🤖 Build process or auxiliary tool changes\ndocs: 📝 Documentation only changes\nrefactor: 💡 A code change that neither fixes a bug or adds a feature\nstyle: 💄 Markup, white-space, formatting, missing semi-colons...\n```\n","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fclickhouse%2Fclick-ui","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fclickhouse%2Fclick-ui","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fclickhouse%2Fclick-ui/lists"}