# Typewind: Tailwind classes written as typed property chains that compile away at build time

> Typewind replaces Tailwind class strings with a typed tw object and a Babel plugin that turns each chain back into static classes. This review covers the syntax, what the compiler does, the type generation from your config, and the gaps around version support and maintenance.

**Mokshit06/typewind** — The safety of Typescript with the magic of Tailwind.

- Repository: https://github.com/Mokshit06/typewind
- Website: https://typewind.dev/
- Stars: 2,287 · Forks: 24
- Language: TypeScript
- License: MIT
- Published: 2026-10-08 · Updated: 2026-10-30 · Language: en
- Canonical page: https://hysenlabs.com/projects/mokshit06-typewind

## Property chains instead of class strings: tw.border.hover(tw.border_black)

Typewind changes how you write Tailwind. Instead of a string of class names, you import tw from the typewind package and chain properties. The README's first example reads tw.border.hover(tw.border_black), and the output is the string 'border hover:border-black'. Each Tailwind class becomes a property, with dashes written as underscores, as in border_black. Variants become function calls: hover wraps the styles that should apply on hover.

```js
import { tw } from 'typewind';

const styles = tw.border.hover(tw.border_black);
```

The project describes itself as bringing the safety, productivity and intellisense of TypeScript over to Tailwind. The shift is that the class list is code the compiler can check, not text it must ignore. The cost is a new spelling to learn, since every class you already know from the Tailwind docs has to be translated into its tw property name.

## A Babel plugin removes the tw calls and leaves a plain string

The README says Typewind's compiler is a Babel plugin. It runs over your code, statically analyses it and converts every tw style into its Tailwind classes. Because the conversion happens at build time, the README states that Typewind compiles away, leaving zero runtime code, and lists zero bundle size as a feature.

```js
const styles = tw.border.hover(tw.border_black);

// ↓ ↓ ↓ ↓ ↓ ↓

const styles = 'border hover:border-black';
```

Two constraints follow from static analysis. The plugin must be able to read the chain at compile time, so a class built from a runtime value cannot be resolved the same way. The README does not describe what happens in that case, though a TRADEOFFS.md file at the top of the repository suggests the author wrote the trade-offs down separately. And since the plugin is Babel-based, a build that does not run Babel needs a route to it, which the examples are there to show.

## Variants take a group of styles, so sm(...) covers several classes at once

The README highlights one syntax advantage. Because Typewind uses TypeScript, variants can wrap several styles in one call:

```js
const mediaStyles = tw.sm(tw.w_4.mt_3).lg(tw.w_8.mt_6);
const groupInGroups = tw.text_sm.sm(tw.bg_black.hover(tw.bg_white.w_10));
```

In plain Tailwind, the same result needs a prefix on every class: sm:w-4 sm:mt-3 lg:w-8 lg:mt-6. Typewind states the variant once per group. The second example nests, with hover inside sm, so stacked variants are written as nested calls and not as long prefix chains.

This is the part that rewards readers who find repeated prefixes noisy. The README does not claim any change in the CSS that is generated, only in how you spell the input. The output is still ordinary Tailwind class names, so the Tailwind compiler does the actual style generation afterward.

## A misspelled class becomes a TypeScript error and a failed tsc run

Type safety is the headline feature. The README gives an example where tw.border_blackk produces a TypeScript error: Property 'border_blackk' does not exist on type 'Typewind'. Did you mean 'border_black'? The same code would also return a build error when you run tsc.

Plain Tailwind class strings are checked by no one at compile time. A typo in a string silently produces no style. Here the typo is caught in the editor and in CI, provided tsc is part of your pipeline. The editor also gets intellisense and autocomplete for all the classes from the Tailwind config, which the README ties to the TypeScript compiler.

The guarantee has a boundary. It covers classes written through tw. A class string typed directly into a className attribute is outside the type system, so a codebase that mixes both styles is only partly protected.

## Types come from your Tailwind config, including custom palettes and plugins

The type definitions of tw are generated directly from your Tailwind config. The README says this makes them always custom to you, and that Typewind also creates types for a custom theme palette and for plugins. If your config defines a brand colour, a property for it exists, and if you remove one, code that used it stops type-checking.

That design ties Typewind to the config file, so the generation step has to run again when the config changes. The README does not say when generation happens, whether it needs a command, or how editors pick up regenerated types, so the examples and the typewind.dev site are the sources.

The root package.json of the repository lists tailwindcss ^3.4.14 and typescript ^5.6.0 as dev dependencies, with Node 18 or newer in engines. The README never mentions Tailwind 4, so confirm your version works before you convert a codebase.

## Three example projects: Next.js, Vite and a runtime example

The repository includes an examples directory with three projects: next-example, vite-example and runtime-example. They are the only setup guidance in the repository text, because the README has no installation or configuration section at all. No install command, no Babel config and no Tailwind config appears in it.

The pairing of next-example and vite-example suggests the plugin has been wired into two common build setups. The runtime-example name is less clear. The README says Typewind leaves zero runtime code, so a separate runtime example implies another mode, but its contents are not shown and nothing in the README explains it.

The repository is an npm workspace over packages/* and examples/*, tested with jest, and has a site/ directory for the documentation website at typewind.dev. To learn the setup, copy the example closest to your stack and compare it against your own build.

## Last push on 2026-04-08 and a newest release from June 2025

Maintenance needs plain dates. The last push to the main branch was on 2026-04-08, and the three most recent releases are 0.3.0 on 2025-06-11, 0.2.0 on 2024-09-23 and 0.1.6 on 2024-05-25. The repository is not archived, but a gap of several months since the last push means you should not assume quick answers to issues or support for the newest Tailwind release.

The version numbers are all 0.x, which signals that the project has not declared a stable API. A minor bump such as 0.2.0 to 0.3.0 can change behaviour, so pin the version and read each release note.

The license is MIT. A Vercel sponsor badge closes the README. For a build-time dependency in a production codebase, the question to settle first is whether your team is willing to patch or fork the plugin if Tailwind or Babel moves on.

## Conclusion

Typewind suits TypeScript teams who want typo-proof Tailwind classes and are willing to adopt a Babel plugin to get them. It does not suit projects that need clear signs of current maintenance, because the last push was on 2026-04-08 and the newest release, 0.3.0, dates from 2025-06-11. Before adopting it, read TRADEOFFS.md in the repository and confirm that your Tailwind version and your bundler setup match one of the three example projects.

## FAQ

### What is Typewind?

Typewind brings TypeScript type safety and intellisense to Tailwind. A Babel plugin converts tw property chains into static Tailwind class strings at build time.

### Does Typewind add code to the browser bundle?

No. The README says Typewind compiles away and leaves zero runtime code. The tw calls are replaced by plain class strings during the build.

### Is Typewind still maintained?

The last push to the repository was on 2026-04-08 and the newest release, 0.3.0, was published on 2025-06-11. The repository is not archived.

## Sources

- [License: MIT](https://github.com/Mokshit06/typewind/blob/main/LICENSE)
- [Mokshit06/typewind on GitHub](https://github.com/Mokshit06/typewind)
- [Project website](https://typewind.dev/)
- [README](https://github.com/Mokshit06/typewind/blob/main/README.md)
- [Releases](https://github.com/Mokshit06/typewind/releases)

---

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