Kotlin Wrappers: JetBrains' Type-Safe Bindings for JavaScript Libraries in Kotlin

What Kotlin Wrappers provides and who it is for

Kotlin Wrappers gives Kotlin developers type-safe access to JavaScript libraries from Kotlin/JS and Kotlin/Wasm code. Without wrappers, calling a JavaScript library from Kotlin requires writing external declarations manually, which are untyped, error-prone, and require maintenance every time the upstream library changes its API.

The repository is maintained by JetBrains and targets Kotlin developers who build web frontends, GitHub Actions scripts, Electron desktop apps, or any other JavaScript-interoperating Kotlin project. It covers libraries from the React ecosystem, the Material UI design system, the TanStack utility collection, the Emotion CSS-in-JS system, and many other categories.

Each wrapper is a separate Maven artifact under the org.jetbrains.kotlin-wrappers group on Maven Central. Developers add only the wrappers they need as Gradle dependencies. A BOM (Bill of Materials) artifact, kotlin-wrappers-bom, is available to align versions across multiple wrappers in the same project.

Library catalogue: what is wrapped and what targets are supported

The README lists the included libraries in a table. Each row shows the library name, its supported Kotlin targets, a link to the generated API reference, a link to its own README, any notes, and the current version on Maven Central.

The target column uses icons to indicate JS and Wasm support. Not every wrapper supports both targets; the individual README files in each library's subdirectory document the specifics.

Highlighted categories from the repository tree include:

React bindings: kotlin-react, kotlin-react-dom, kotlin-react-router, and lazy-module support for code splitting.

Material UI: kotlin-mui-material, kotlin-mui-base, kotlin-mui-lab, kotlin-mui-system, kotlin-mui-icons-material, and the extended date pickers in kotlin-muix-date-pickers.

TanStack: kotlin-floating-ui-core, kotlin-floating-ui-dom, kotlin-floating-ui-react-dom, plus TanStack table, router, and virtual scroll wrappers.

Emotion: kotlin-emotion-css, kotlin-emotion-react, kotlin-emotion-styled, kotlin-emotion-cache, and kotlin-emotion-utils.

AJV validation, Electron, jszip, Cesium (cesium-engine and cesium-widgets), and browser APIs (kotlin-browser, kotlin-cssom-core, kotlin-csstype).

GitHub Actions integrations: kotlin-actions-artifact, kotlin-actions-cache, kotlin-actions-core, kotlin-actions-exec, kotlin-actions-github, kotlin-actions-glob, kotlin-actions-http-client, kotlin-actions-io, kotlin-actions-tool-cache.

A catch-all kotlin-js package covers additional JavaScript utilities, with kotlin-js-core, kotlin-js-plain-object, and kotlin-js-test as subpackages.

Using the BOM and adding dependencies to a Gradle project

The kotlin-wrappers-bom artifact pins all wrapper versions together. This prevents version conflicts between wrappers that depend on each other. The BOM approach means adding one version constraint aligns the entire set.

The API reference at jetbrains.github.io/kotlin-wrappers/ documents every wrapper's Kotlin API surface. The reference is generated from the source code and reflects the current release.

The examples/ directory contains runnable Gradle projects that demonstrate common usage patterns. The top-level examples include: a browser application, a React application, MUI materials usage, TanStack React Router (both browser and Node.js test variants), TanStack table and virtual table, Tanstack Router, a Tic-tac-toe game, web components, an export-suspend-with-cancellation example, an MDN AudioWorklet example, and a simple Wasm application.

Each example has its own build.gradle.kts and settings.gradle.kts, and shares build-logic from the examples/build-logic/ directory. The examples/gradle.properties file pins the Kotlin version used across all examples. Running any example follows the standard Gradle tasks for Kotlin/JS: the browserDevelopmentRun or browserProductionWebpack task depending on the target.

Release cadence and how wrappers track upstream versions

The project uses a date-based versioning scheme. The most recent releases visible in the prompt are 2026.9.2 (released 2026-09-16), 2026.9.1 (released 2026-09-05), and 2026.9.0 (released 2026-09-01). This indicates roughly one to two releases per month.

Each wrapper's version on Maven Central is shown in the README's library table via a dynamic badge. The version number in the badge reflects the latest published version of that specific wrapper.

The CHANGELOG.md tracks changes across releases. The NPM.md document in the repository covers details specific to the npm packaging behaviour of the wrappers, since Kotlin/JS uses npm packages internally for the wrapped JavaScript libraries.

The GENERATE.md document describes how the wrapper generation process works. Many wrappers in this repository are generated from TypeScript type definitions rather than written entirely by hand. This means when an upstream JavaScript library publishes new TypeScript definitions, the wrapper can be regenerated to track API changes, rather than requiring a full manual rewrite.

Limitations and what Kotlin Wrappers does not cover

Kotlin Wrappers wraps JavaScript libraries that have TypeScript definitions. Libraries that are untyped or have incomplete type definitions are harder to wrap accurately. The generated output depends on the quality of the upstream TypeScript definitions; a library with partial types produces a wrapper with gaps.

The wrappers target Kotlin/JS (with IR backend) and Kotlin/Wasm. Kotlin/Native targets are outside the scope of this repository. Developers building shared code for Kotlin Multiplatform that includes native iOS or macOS targets need to handle UI separately; these wrappers do not produce native code.

Each wrapper requires that the corresponding JavaScript package be resolvable by the Kotlin/JS webpack or Vite build step. This makes the wrappers incompatible with strict offline or fully air-gapped build environments where npm resolution cannot reach the public registry.

For Kotlin developers who want to use a JavaScript library not covered by this repository, the alternative is to write external declarations manually using Kotlin's external modifier, or to use Dukat, the tool that generates Kotlin externals from TypeScript definitions. Dukat produces the same kind of output that many of these wrappers are generated from; the advantage of this repository is that JetBrains maintains and tests the generated output against real Kotlin compilation.

The FAQ.md file in the repository documents common questions; the CONTRIBUTING.md and CODE_OF_CONDUCT.md cover the process for adding new wrappers or reporting issues.

Editorial conclusion

Kotlin Wrappers is the standard choice for Kotlin/JS and Kotlin/Wasm developers who want to use popular JavaScript libraries without writing manual external declarations. The wrappers track upstream library versions and are published monthly to Maven Central. Teams that are already committed to Kotlin Multiplatform for shared business logic and need a frontend layer will find these wrappers reduce the friction of integrating JavaScript UI libraries. For teams evaluating Kotlin for the first time on the frontend, note that each wrapper depends on the corresponding npm package being available in the build; the Kotlin/JS toolchain manages this, but it adds a build dependency that pure Kotlin/Native teams do not encounter. Before adopting a specific wrapper, check the README.md in the individual library's subdirectory for target platform support, since not every wrapper targets both JS and Wasm.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes