# Mishka Chelekom: generated Phoenix and LiveView components

> Mishka Chelekom is an Elixir library that generates Phoenix and LiveView components into your own source tree through a mix generator, with a colour and variant system, headless components, and an import file that replaces the Phoenix core components. The dependency is a development-only one, so nothing of it reaches production.

**mishka-group/mishka_chelekom** — Mishka Chelekom is a fully featured components and UI kit library for Phoenix & Phoenix LiveView

- Repository: https://github.com/mishka-group/mishka_chelekom
- Website: https://mishka.tools/chelekom
- Stars: 754 · Forks: 23
- Language: Elixir
- License: Apache-2.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/mishka-group-mishka-chelekom

## A code generator, not a component dependency

Mishka Chelekom is a library of templates for components in Phoenix and Phoenix LiveView, published on Hex as mishka_chelekom, and the README is explicit about the delivery model. It generates fully customizable components directly into your project, with no hidden dependencies and no complex configurations.

All components are generated locally by a mix generator, and the README explains why that matters. You get full control over the source code without being locked into any external library, and the components arrive as ordinary code in your own tree.

That is the whole design, and it is the design that distinguishes it from a component package. A dependency gives you components you import and call, and you upgrade them by changing a version constraint. A generator gives you components that are yours, that you can edit freely, and that you are responsible for keeping. The trade is that a bug fix in the library does not reach you unless you re-run the generator and merge the result.

The README is also clear about where the library lives in your project. You will only use this library in your development environment, and it will not have any presence in production. That is visible in the dependency declaration, which marks the package as only: :dev.

The primary language is Elixir, the licence field says Apache-2.0, and the homepage is the project's own site at mishka.tools/chelekom.

## The dependency declaration and the first generator call

The installation is a dependency entry in a Mix project.

```elixir
def deps do
  [
    {:mishka_chelekom, "~> 0.0.9", only: :dev}
  ]
end
```

The only: :dev flag is the whole point of the model, because the generator needs the templates at development time and the generated code needs nothing at runtime.

Generating a single component is a mix task with options for the colour and the variant.

```bash
mix mishka.ui.gen.component alert --color info --variant default
mix mishka.ui.gen.component alert
```

The second form generates with the defaults, and the README notes a wrinkle for Windows users, who should use an empty quoted string when passing more than one value for an argument, since the shell there handles the quoting differently.

```bash
mix mishka.ui.gen.component alert --color "info,danger"
```

So a single component can be generated with a chosen colour and variant, and the naming follows the pattern of a mix task, a library namespace and an action, which is the convention that makes the tool feel native inside a Mix project.

## Generating sets of components, with import files and helpers

The bulk generation tasks take either a list of components or nothing at all, and the flags control how the result is wired into your project.

```bash
mix mishka.ui.gen.components
mix mishka.ui.gen.components alert,accordion,chat
```

The --import flag adds a file that imports all of the generated components, and --yes skips the questions and generates directly.

```bash
mix mishka.ui.gen.components --import --yes
mix mishka.ui.gen.components alert,accordion,chat --import --yes
```

The --helpers flag goes further and adds helper functions and macros for the import, and --global makes the components accessible throughout the project without explicit imports, which is the variant the README marks as recommended because it replaces the Phoenix core components globally.

```bash
mix mishka.ui.gen.components --import --helpers --global --yes
mix mishka.ui.gen.components alert,accordion,chat --import --helpers --yes
```

And there is a path that does the setup in one step for projects that use Igniter and the latest alpha version.

```bash
mix igniter.new my_app --with phx.new --install mishka_chelekom
```

Igniter is the library that powers the whole approach, and the README explains its role for the future as well. If you want to add another variant later, the project is powered by Igniter, which makes it easy to update the previous code seamlessly, so the generated code is designed to be regenerated rather than hand-patched.

## Headless components and the option surface

The headless component line is the newer idea in the library and it is worth understanding separately.

Headless components ship only semantic markup, full WAI-ARIA wiring, named slots called anatomy parts, and JavaScript behaviour hooks. No colours, no variants, no sizes. Each one is written to a headless directory inside the web components directory, right next to the styled ones.

```bash
mix mishka.ui.gen.headless dialog
```

And the bulk version takes a list or generates everything.

```bash
mix mishka.ui.gen.headless.components dialog,tabs
mix mishka.ui.gen.headless.components
```

Removal is symmetric, with an uninstall task that takes the headless flag, and the README shows the form for a named component or for all of them.

The option surface for the two generator tasks is where the customisation actually lives. The single component task takes a variant, a colour, a size, a padding, a space, a type and a rounded flag, each with a short alias, plus a no-sub-config flag for dependent components that use default settings, a module flag for a custom component module name, a sub flag, a no-deps flag and a yes flag for generating without questions.

The bulk task takes the import, helpers, global and yes flags, plus an exclude option. The README notes that the exclude option lets you skip components you do not want, which is the practical way to use the full set without accepting all of it.

## What the repository contains and what it costs to depend on

The top level of the repository shows a library with the usual Elixir conventions and a few things that stand out.

There is mix.exs and mix.lock for the build, a .formatter.exs for code formatting, a lib/ directory for the Elixir source, a priv/ directory for the templates that get written into a project, a test/ directory, a development/ directory and a documentation/ directory, plus a CHANGELOG.md, a LICENSE, a SECURITY.md and an MCP.md.

Two of those are worth a note. The priv/ directory is where the component templates live, since the generator's job is to copy and format them into a target project. And the usage-rules.md file at the root, together with a usage-rules/ directory, is the pattern some of these projects use to ship instructions for coding agents alongside the library, so that a tool working on the project knows how the components are meant to be used.

The README also carries a sponsorship request, a GitHub sponsors link and a Buy Me a Coffee link, and it states that all components are free and open source while pro support and enterprise services are offered separately. That is the commercial model: the generator is free, and the paid part is the organisation that will adapt the library to your design system and support it.

The practical cost of depending on this is therefore not a runtime dependency but a build-time one, and the price of the copy-and-own model is that you own the copies.

## Where Mishka Chelekom is the wrong choice

The first limitation is the one that follows from generating code rather than depending on it. When the library fixes a bug or a component changes shape, your copy does not change with it, and the Igniter integration is designed to make the re-generation possible rather than automatic. A team that expects to pull improvements from upstream will be disappointed, and a team that wants a central place to fix a shared component across many applications will not find one here.

The second is the version numbering. The releases are v0.0.10-alpha.6 from 2026-08-08, v0.0.9 from 2026-07-12 and v0.0.8 from 2025-09-27, and the dependency example pins ~> 0.0.9. A 0.0.x line with alpha releases is a library in heavy development, and the difference between 0.0.9 and 0.0.10 can be a change in how the generator behaves.

The third is that this is a design system with an opinion, not a set of neutral primitives. The colour, variant, size, padding, space and type options are a vocabulary, and adopting the library means adopting that vocabulary. A team with an existing design system will find parts of it redundant and parts of it in conflict.

The fourth is the size of the generated output. Generating all components, especially with the global replacement of the Phoenix core components, produces a large amount of code in the project, and a project that later changes direction has to unpick it.

The fifth is the headless line. It is the newest part of the library, it writes into a separate directory, and the full WAI-ARIA wiring and the behaviour hooks mean you are adopting an opinion about accessibility markup as well as about appearance.

## How Mishka Chelekom compares with a Phoenix component dependency and with a Tailwind plugin

The comparison with a Phoenix component package is the one the design is arguing with, and the difference in approach is ownership. A package gives you components you import, with a version constraint, a changelog and an upgrade path, and it is the right choice when you want the upstream improvements and do not want to maintain the code.

A generator gives you code you own, and it is the right choice when you want to change a component without fighting a dependency, when your components are going to diverge from the library anyway, or when a project policy forbids a runtime UI dependency.

The second comparison is with a Tailwind plugin, and it is the most common route for a Phoenix team. A plugin gives you the CSS and the markup conventions, and Tailwind's utility classes mean there is often no need for a component library at all. The difference is that Tailwind gives you a vocabulary and a build, while a component library gives you finished components with behaviour, accessibility and structure already done.

The third comparison is with building your own components, and the argument here is consistency rather than effort. A team that has never agreed on what a card looks like will produce forty different cards, and a generator imposes the decision once. The cost is that the decisions are imposed rather than chosen.

The fourth is with a component library that also ships styles. This one ships no runtime CSS dependency, which is what keeps the production bundle free of it, and that is the reason the generator approach and the Tailwind approach fit together so well.

## Licence, project state and what to try first

The licence field on the repository says Apache-2.0, and the README links the LICENSE file in the repository, so the terms are the standard permissive ones. The components that get generated into your project are yours, which matters for a library whose output is source code.

The project is not archived and the last push was on 2026-10-17, so it is actively worked on, and the release history shows a slow but steady line of increments through 2025 and 2026.

The README also states that for pro support and enterprise services there is a separate offering, which is the commercial side of a project whose code is free.

Four things to try before committing to it.

Generate one component into a scratch Phoenix project and read the output, because the value of the library is entirely in the code it writes, and if the output is not the style you want, the configuration options will not save it.

Try the import file with helpers on a small set, since that is the mode the README recommends and the one that decides whether the components read as first class in your application.

Decide about the global replacement of the Phoenix core components, which is convenient and which removes the ability to fall back to the built-ins for a case where you want the default behaviour.

And check the version line you pin, since the example pins ~> 0.0.9 while the newest release is an alpha, so a dependency on the alpha is a dependency on a moving target.

## Conclusion

Mishka Chelekom suits a Phoenix team that wants a coherent set of components with a consistent design system and does not want a runtime dependency in exchange. It is the wrong tool if you need components that stay in step with an upstream library, because the generated code is a copy you own and maintain, and the wrong choice if you want headless behaviour with a runtime dependency you can update centrally. Before adopting it, generate a couple of components into a scratch project and read the output, because the value of the library is entirely in what it writes into your tree.

## FAQ

### What is Mishka Chelekom?

It is an Elixir library of templates for Phoenix and Phoenix LiveView components that generates fully customizable components directly into your project using a mix generator, so there is no hidden runtime dependency and no lock-in to an external library.

### How do I add Mishka Chelekom to a Phoenix project?

Add the dependency as `{:mishka_chelekom, "~> 0.0.9", only: :dev}` in your deps function. It is a development-only dependency because the generator runs at build time and the generated components need nothing at runtime.

### How do I generate components with Mishka Chelekom?

Use the mix tasks. A single component is `mix mishka.ui.gen.component alert --color info --variant default`, a set is `mix mishka.ui.gen.components alert,accordion,chat`, and the --import, --helpers and --global flags add an import file, helper functions and global availability respectively, with --yes to skip the questions.

### What are headless components in Mishka Chelekom?

They ship only semantic markup, full WAI-ARIA wiring, named slots described as anatomy parts, and JavaScript behaviour hooks, with no colours, variants or sizes. They are generated with `mix mishka.ui.gen.headless dialog` or in bulk with `mix mishka.ui.gen.headless.components`, and are written to a headless directory next to the styled ones.

### Why is the Mishka Chelekom dependency marked as development only?

Because the library is a code generator. The templates are needed at development time to write the components into your project, and the components that result are ordinary source code in your tree, so the library itself has no presence in production.

### What licence does Mishka Chelekom use?

Apache-2.0, with the terms in the LICENSE file at the root of the repository. The components are free and open source, while pro support and enterprise services are offered separately.

## Sources

- [License: Apache-2.0](https://github.com/mishka-group/mishka_chelekom/blob/master/LICENSE)
- [mishka-group/mishka_chelekom on GitHub](https://github.com/mishka-group/mishka_chelekom)
- [Project website](https://mishka.tools/chelekom)
- [README](https://github.com/mishka-group/mishka_chelekom/blob/master/README.md)
- [Releases](https://github.com/mishka-group/mishka_chelekom/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mishka-group-mishka-chelekom