uiw: a React component monorepo where the tags stopped before the commits did

The root package publishes nothing on purpose

uiw describes itself as a component library for React 16+, published under the @uiwjs organisation, and the repository root makes that structure explicit. The root package.json is named uiw-project and carries a "private": true flag, which is the conventional way of saying the root exists to orchestrate the workspace rather than to be installed from a registry. Every package that a consumer would actually install lives under the packages/ directory.

  "name": "uiw-project",
  "description": "A high quality UI Toolkit, A Component Library for React 16+.",
  "homepage": "https://uiwjs.github.io",
  "private": true,

The rest of the root tells you the toolchain is shared rather than per package. A lerna.json drives the workspace, tsconfig.json holds the TypeScript configuration, renovate.json shows dependency updates are handled by automation, .prettierrc and .prettierignore set formatting rules, and a .husky/ directory holds Git hooks. A .gitpod.yml is also present, so there is a ready-made cloud development environment for working on the components themselves.

The practical consequence for an adopting team is simple: you do not depend on uiw-project. You depend on one or more scoped packages such as @uiw/react-collapse, and the monorepo is the only place where all of them can be read side by side.

Less compilation and tsbb builds run one scope at a time

The interesting part of the build configuration is that it is scoped per package rather than run across the whole workspace by default. The lib:css script targets @uiw/react-collapse specifically and compiles Less from src into esm, and the dist variant adds --combine=dist.css to fold the sources into a single stylesheet.

    "lib:css": "lerna exec --scope @uiw/react-collapse -- compile-less -d src -o esm",
    "lib:css:dist": "lerna exec --scope @uiw/react-collapse -- compile-less -d src -o lib --combine=dist.css",

The JavaScript side uses tsbb, a build tool that wraps TypeScript compilation and can emit CommonJS output. The umbrella build script chains the three phases in a fixed order, first the packages, then the stylesheets, then the combined CSS.

    "build": "npm run b:uiw && npm run b:css && npm run b:css:dist",

Watching works differently from building. There is a script that runs lerna exec in parallel across the @uiw scope with --ignore @uiw/doc, and separate scripts that watch a single package at a time, including one for the uiw bundle and one for @uiw/react-menu with its own Less watcher. The result is a component library whose styling is a first class part of the build, not an afterthought bolted on afterwards. That matters for anyone who needs to theme components: you get a Less source tree and a compiled dist.css, so theming happens at the stylesheet level.

The documentation site is a package inside the same tree

The website/ directory at the repository root is a workspace member of its own, and the root scripts show it being run as such. The start script delegates to the website package, and the doc script first builds that site and then runs the documentation package.

    "start": "lerna exec --scope website -- npm run start",
    "doc": "npm run b:website && npm run b:doc",
    "b:doc": "lerna exec --scope @uiw/doc -- node script/released.js",

That last line is the most informative detail in the whole file. The @uiw/doc package runs a script called released.js, which means the published documentation is generated from release data rather than being hand maintained in prose. In practice this couples the docs to the tagging workflow: if tags stop being cut, the release notes on the site stop filling in.

The public face of all of this is the homepage at https://uiwjs.github.io, which is also the homepage field in package.json. The README in the repository root is largely occupied by a grid of sponsored macOS applications and a logo, so a first-time reader gets little about the components themselves from the root file. The site is where the actual component documentation lives, and the site is built from the repository, which is why the doc pipeline is part of the build rather than a separate manual process.

Tags stopped in November 2023 while pushes kept arriving

The release history and the commit history tell different stories, and any team doing upgrade planning needs to hold both of them. The most recent tagged releases are v4.22.1 on 2023-11-08, v4.22.2 on 2023-11-09 and v4.22.3 on 2023-11-29, three tags shipped inside three weeks at the end of 2023.

After that, the recorded releases stop while the repository itself does not. The last push was on 2026-04-21, roughly two and a half years after the newest tag, and the repository is not archived. The repository also keeps a README-zh.md next to README.md, so the project maintains a Chinese translation alongside the English one, and the renovate.json configuration shows dependencies are still being tracked by a bot.

The gap is the interesting part. Commits have continued without new v4.22.x tags appearing in the release list, which usually means fixes and features have landed on master without a corresponding version bump, or that tags are cut somewhere other than this list. The README does not explain the release policy, so you cannot tell from the repository alone whether a fix you need exists only on master. The safe move for a production team is to install a specific published version if you need reproducibility, and to read the commit history directly if you need to know what changed after 2023-11-29.

Where the README leaves you stuck

Two gaps are worth naming before anyone commits a sprint to this library. The first is documentation coverage. The README as published is essentially a sponsor wall, a badge grid for macOS apps and a logo, with no install command, no component list and no props reference. Anyone looking for how to add a uiw component will end up on the homepage instead, and that means the repository itself is not a sufficient place to evaluate the API surface.

The second gap is the version claim. The description targets React 16+, which is a wide and increasingly old range. The repository root does not expose a peer dependency range for any individual component, so the only way to confirm that a given @uiw package still accepts the React version your app runs is to open that package's own package.json under packages/. The root directory listing also shows no test directory and no test script in the visible part of the root package.json, so the project's own test approach is not visible from the root.

Both gaps are survivable, but neither is free. They push the cost of evaluation onto the reader: before adopting, you have to open the packages you intend to use and check their peer ranges and their prop types yourself.

A first run starts from the clone, not from an install line

Because the README documents no install command, there is nothing to copy for a quick start. The project points to its homepage at https://uiwjs.github.io for component documentation, and the repository itself is where the workspace mechanics live. If you want to see the components rather than read about them, the workable path is to clone the repository and drive the root scripts, which are the only commands the project actually defines.

    "build": "npm run b:uiw && npm run b:css && npm run b:css:dist",
    "start": "lerna exec --scope website -- npm run start",

The build chain above is the entry point to see anything at all: it runs the package builds, then the Less compilation, then the combined stylesheet, and the start script brings up the website package that renders the component documentation.

To check what exists before installing anything, list the packages/ directory and read the package.json of each scoped package you care about, because the root never publishes and the README never lists them. That check is also where the peer dependency question gets answered, since the root description says only React 16+.

Adopting components versus assembling your own

The real alternative to uiw is not another component library, it is a different way of producing the same UI. You can assemble an internal component set inside your own application repository, where each component is a local file, the styling is whatever your build already supports, and there is no separate package to version or upgrade. The difference in approach is ownership: a local set means your team owns every fix and every breaking change, and the design system lives and dies with the people who wrote it.

uiw moves that work outside your repository. You get scoped packages with a peer dependency range, a Less source tree compiled into a combined dist.css, and a documentation site generated by a release script, and the exchange is that you now track an upstream project whose tags stopped on 2023-11-29. The second alternative is the opposite philosophy: utility class styling, where a component is composed in markup rather than imported as a package. That route gives you no component API and no version migration to track, but it also gives you no ready-made behaviour.

For a team that wants opinionated components with their own styling pipeline and no build system of its own, the first option fits. For a team that would rather write and own a handful of components in house, the second is cheaper than integrating any external toolkit.

Editorial conclusion

Adopt uiw if you want ready-made React components with their own Less build under an MIT licence, and you are willing to check each scoped package's peer dependency range and its unpublished commits yourself. Do not adopt it on the assumption that a v4.22.3 tag tracks the current tree, because the tags stop on 2023-11-29 while the last push was on 2026-04-21. Before writing a line of code, look inside packages/ for the exact @uiw scope you need, read its peer dependency range, and confirm on the uiwjs.github.io homepage that the component you want is documented.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. uiwjs/uiw on GitHub