JetBrains Ring UI: React components for JetBrains-style web products

The problem Ring UI solves inside JetBrains products

JetBrains ships many web-based surfaces: plugin UIs, internal tools, and product pages. Without a shared component set, each one reinvents a button, a dialog, a loader, and an alert, and the results drift apart visually and behaviourally. Ring UI is the answer to that: the README states the collection "aims to provide all the necessary building blocks for web-based products built inside JetBrains, as well as third-party plugins developed for JetBrains' products." That sentence is the whole scope. It is not a general-purpose design system competing for the widest possible audience; it is the internal JetBrains kit published under Apache-2.0 so plugin authors can use it too.

The audience follows from that. If you are writing a plugin whose settings page should not look foreign next to the IDE, Ring UI is the closest thing to the native look. If you are building a standalone SaaS dashboard and have no relationship to JetBrains, the design language is a constraint rather than a benefit, and you are paying the build complexity for someone else's visual identity.

Two npm packages and one Webpack coupling

The mechanism is unusual and worth understanding before you install anything. Ring UI publishes two packages with different jobs. `@jetbrains/ring-ui-built` is the pre-built version, described in the README as the choice "for Quick Start". `@jetbrains/ring-ui` is the "sources" version for complex projects, and the README is explicit about the consequence: "You will then need to include building Ring UI into your WebPack build".

That is the architectural decision that shapes everything else. With the built package you import ES modules and the bundle size depends on how many components you pulled in, as the README notes. With the sources package, Ring UI's own source files become part of your compilation, which lets you share one build process and one set of loaders, but it ties you to Webpack because the package exports a Webpack configuration fragment. The repository layout supports that reading: `webpack.config.js`, `rollup.config.js`, `babel.config.js` and `postcss.config.js` all sit at the top level, and `package.json` lists `webpack.config.js`, `babel.config.js`, `postcss.config.js` and `typings.d.ts` in its published `files` array. The exported `webpack.config` entry is a real part of the package surface, not an internal detail.

Components are addressed by path, not by a barrel import. The exports map routes `./components/icon` to `./components/icon/index.js` and handles `.js`, `.css`, `.d.ts`, `.svg`, `.gif`, `.json` and `.md` suffixes. In practice you import a component from its own directory, which keeps tree shaking predictable but means there is no single `import { Button } from '@jetbrains/ring-ui'` entry point documented in the README.

Installing Ring UI and rendering a first button

Start with the pre-built package, which the README presents as the quickest route. The install is a single npm command:

npm install @jetbrains/ring-ui-built

After that, import the stylesheet once, then import the components you need as ES modules. The README's quick start example wires a button to the alert service:

// You need to import RingUI styles once
import '@jetbrains/ring-ui-built/components/style.css';

import alertService from '@jetbrains/ring-ui-built/components/alert-service/alert-service';
import Button from '@jetbrains/ring-ui-built/components/button/button';

export const Demo = () => {
  return (
    <Button onClick={() => alertService.successMessage('Hello world')}>
      Click me
    </Button>
  );
};

What you should see is a JetBrains-styled button, and a success notification when it is clicked. Two details in that snippet are easy to miss. The style import is described as something you do once for the whole app, so putting it in a component rather than an entry point will duplicate it. And the alert service is imported as a singleton object rather than a component, so the notification is triggered imperatively from the click handler.

If you need the sources build instead, the README's steps are: install with `npm install @jetbrains/ring-ui --save-exact`, import components where needed (or create an entry point such as `/app/app__components.tpl.js` that imports them), then create a `webpack.config.js` that spreads Ring UI's rules into your own:

const ringConfig = require('@jetbrains/ring-ui/webpack.config').config;

const webpackConfig = {
  entry: 'src/entry.js', // your entry point for webpack
  output: {
    path: 'path/to/dist',
    filename: '[name].js'
  },
  module: {
    rules: [
      ...ringConfig.module.rules,
      <Your rules here>
    ]
  }
};

module.exports = webpackConfig;

The `--save-exact` flag in that command is deliberate on JetBrains' part: the sources build compiles Ring UI's internals alongside yours, so a floating version range can change what your loaders see without any change on your side. The README does not document a version compatibility matrix between Ring UI and React, so pin the React version your project already uses and check the Storybook examples before upgrading either.

Where Ring UI is the wrong choice

The Webpack coupling is the sharpest limitation. The sources package ships a Webpack configuration fragment and expects you to merge its loader rules into your own config. If your project builds with Vite, esbuild, Parcel, or a framework toolchain that hides the bundler, that integration path does not apply, and you are left with the pre-built package or nothing. The README presents the two options as a binary, quick start or sources, and does not describe a supported path for non-Webpack bundlers.

The second limitation is scope. Ring UI is a component collection, not an application framework. It gives you buttons, loaders, icon handling, alerts, and the rest of the set shown in its Storybook examples, but it does not tell you how to route, fetch data, or manage state. Reaching for it as a full UI framework will leave you assembling the rest yourself.

The third is documentation depth in the README itself. The README points outward: design guidelines on jetbrains.com, a Figma community library, Storybook for usage examples, and YouTrack for issues. Anyone expecting a self-contained reference in the repository will need to follow those links. There is also no changelog content in the README beyond the link to `CHANGELOG.md` in the repository root, so upgrade impact has to be read from that file rather than from release notes on the README page.

Ring UI against a general-purpose React kit

The obvious comparison is a general-purpose React component library such as Material UI or Ant Design. The difference is not quality; it is whose design language you are adopting and what the library optimises for. Those libraries target the widest possible audience and ship their own theming systems, so you can restyle them toward almost any brand. Ring UI does the opposite: it encodes one brand, JetBrains, and offers a Figma community library and published design guidelines so that what you build matches the rest of the product family.

That makes the trade-off concrete. With a general-purpose kit you spend effort on theming to reach a JetBrains-like result, and you get a large ecosystem and a bundler-agnostic install in return. With Ring UI you get the JetBrains look immediately, and you accept the Webpack-shaped build path and the narrower scope. For a plugin that lives inside a JetBrains IDE, matching the host application is the requirement, and a themed Material UI button is a worse answer than a native-looking one.

One more difference sits in the packaging. Ring UI's two-package split, pre-built versus sources, is not a pattern most general-purpose kits offer. It lets a large internal build share one compilation pipeline with the library, which is a real benefit at JetBrains' scale and a real complication for a small project that would rather just import a component.

Licence, maintenance and what an upgrade costs

Ring UI is Apache-2.0, stated in both the README badge set and the `license` field of `package.json`, with the full text in `LICENSE.txt`. Apache-2.0 permits commercial and closed-source use and includes an explicit patent grant, which matters more for a component library than for a standalone tool because you are shipping the code inside your own product. It also requires that you preserve the licence and attribution notices for the parts you redistribute. That is a description of the licence text, not legal advice; if you are bundling Ring UI into a distributed product, have your own counsel read the terms.

The repository is not archived, and its last push was on 2026-09-21. The version in `package.json` is 7.0.125, and the README's quick start example is labelled as a Ring UI 7 demo in the linked sandbox, so the 7.x line is the current one. The repository has no published GitHub releases, so there is nothing here to say about what changed between 7.x versions.

Upgrade cost depends on which package you chose. With `@jetbrains/ring-ui-built`, an upgrade replaces a compiled artifact and your build is untouched. With `@jetbrains/ring-ui`, an upgrade can change the loader rules and PostCSS configuration that get merged into your Webpack build, which is why the README's install command uses `--save-exact`. Budget for that: read `CHANGELOG.md` in the repository root before moving the version, and re-run your own build rather than assuming the merge still produces the same output. The repository also carries `babel.config.js`, `postcss.config.js`, `eslint.config.mjs`, `stylelint.config.js` and `design-tokens.json` at the top level, so the toolchain surface you are inheriting is visible before you install anything.

Editorial conclusion

Adopt Ring UI when your product is a JetBrains plugin, an internal JetBrains tool, or anything that must match the Ring UI design guidelines and Figma library, and when your build already runs Webpack. Do not adopt it for a small marketing site or a project on Vite or esbuild, because the sources package expects Ring UI to be compiled inside your Webpack build. Before committing, check that the components you need exist in the Storybook example list, read the design guidelines for the interaction you are copying, and confirm which of the two packages your toolchain can consume.

Frequently asked questions

Official sources

1. Issues
2. JetBrains/ring-ui on GitHub
3. License: Apache-2.0
4. Project website
5. README