# XRender: four Ant Design admin-panel libraries in one Alibaba monorepo

> FormRender, TableRender, ChartRender and FormGenerator sit in a turbo and lerna workspace where forms, list pages and charts are described rather than hand-built. The README is almost entirely screenshots; the substance lives in the docs site.

**alibaba/x-render** — 🚴‍♀️ Very easy to use process form table chart solution.

- Repository: https://github.com/alibaba/x-render
- Website: https://xrender.fun
- Stars: 7,850 · Forks: 1,076
- Language: TypeScript
- License: not declared
- Published: 2026-10-06 · Updated: 2026-10-06 · Language: en
- Canonical page: https://hysenlabs.com/projects/alibaba-x-render

## Four libraries that share one workspace

XRender is a suite rather than a single library. The README lists four products, each with its own page on the documentation site: FormRender, described as writing a form the way you would write an input; TableRender, positioned as a schema-driven and flexible search-and-list tool; ChartRender, pitched at chart drawing that needs no ceremony; and FormGenerator, a visual builder for assembling forms without hand-writing the markup.

The topic list on the repository is a decent summary of the technical shape: ant, ant-design, form, formrender, table, chart, list, json-schema, react, typescript, webpack, widget. Ant Design is not an optional extra here. It is the substrate, which is why the comparison you will actually face is not XRender versus something generic but XRender versus hand-rolling the same screen on Ant Design components.

The README is honest about its audience in one line, in Chinese: a ready-to-use solution for forms, tables and charts in admin and internal tooling. That is the whole pitch. This is not a general component library and it is not trying to be.

## A turbo and lerna workspace with four kinds of member

The root `package.json` declares npm workspaces covering `packages/*` plus two tools, `tools/schema-generator` and `tools/form-render-excel`. Alongside that sits `lerna.json`, a `turbo.json`, and a `.turbo/` directory, so the build is a turbo pipeline on top of lerna rather than lerna alone. The docs come from `dumi`, configured through `.dumirc.ts` and a `.dumi/` directory.

The interesting members are the ones that are not libraries. A schema generator implies the form definitions are treated as data somewhere in the pipeline. An Excel export tool implies the same schema is used to produce spreadsheets, which is exactly the kind of reuse that motivates describing a form instead of hand-writing it. The top-level `widgets/` directory suggests a fourth category alongside the packages, though the repository does not spell out what belongs in it.

```json
{
  "workspaces": [
    "packages/*",
    "tools/schema-generator",
    "tools/form-render-excel"
  ],
  "scripts": {
    "build": "turbo run build",
    "test": "vitest run",
    "doc": "dumi build"
  }
}
```

Testing runs on vitest, with `vitest.config.ts` and `tsconfig.jest.json` at the root for the older Enzyme-era typings that are still around, which dates the setup.

## Running the documentation site from a clone

This is the part worth knowing before you evaluate anything, because the README does not include a getting-started section. The docs are the product documentation and the demo site at the same time, so the fastest way to see the libraries working is to run it locally.

```bash
npm run dev
```

That script sets `PORT=8080` and starts `dumi dev`, so the site comes up on port 8080. The build side is equally short:

```bash
npm run build
```

which is `turbo run build` across the workspace, with `npm run doc` for the dumi documentation build and `gh-pages -d docs-dist` wired into the deploy script. A separate `npm run size` sets `ANALYZE=1` before a dumi build, which is the bundle analysis path, useful if you care about what Ant Design costs you.

Testing is vitest throughout: `npm test` runs `vitest run`, and the scripts also expose `test:coverage`, `test:ui` and `test:clean` for clearing the cache. Formatting runs prettier across `docs/`, `packages/`, `tools/` and `widgets/` through lint-staged.

## Describing a form as data instead of writing JSX

The core design decision is visible in the topic list and in the one-line descriptions: forms and list pages are generated from a description rather than written by hand. The presence of `tools/schema-generator` and a package called form-render-excel suggests those descriptions are JSON-schema shaped and are consumed by more than one renderer.

That approach pays off in a specific kind of organization. If the same admin product needs a form, a table with search, a chart and an Excel export over the same fields, writing each of those four times is the cost. Generating all four from one description is the saving. It also means a non-specialist can adjust a field without touching component code, which matters more in internal tooling than in a consumer product.

The cost is the same in every schema-driven library: the description is a second language you have to learn, and the day it cannot express what you need you end up writing an escape hatch anyway. The repository does not document those escape hatches, and the README does not claim there are none.

## Where the README stops, which is almost immediately

Be clear-eyed about this one. The README for XRender is roughly 6,800 characters and is composed almost entirely of HTML: a logo, badge images pointing at npm and GitHub, an 18-cell grid of customer logos, and a contributor strip. The only substantive English in it is the four-item product list, a request for stars and pull requests, a link to the contributing guide, a support group image, and a note that the project follows the MIT license.

So there is no install command, no usage example, and no API description on the README page. Every real decision has to be made against xrender.fun, where each of the four products has its own documentation page, or by reading `packages/` directly. The repository also carries a `CONTRIBUTING.md`, a `CODE_OF_CONDUCT.md` and a `.github/` directory, so the project governance exists even though the front page does not describe it.

One naming detail can waste your afternoon. Several README badges and links point at `github.com/alibaba/form-render` rather than the `alibaba/x-render` path, a leftover from the repository's earlier name. The star history chart at the bottom of the page uses the current path, so history is preserved across the rename.

## Maintenance, releases and the licensing picture

The repository is not archived and the last push was on 2026-05-26, so the code is moving. The GitHub releases are less current than that: they are v1.0.4 for XFlow published 2025-04-24, FormRender v2.5.2 published 2025-03-20, and a v2.0.0 tag from 2023-10-13 whose notes are actually about FormRender 2.2.21 fixing a moment date handling bug. The version numbers in this repository are per-package rather than monorepo-wide, which is normal for a lerna setup with independent packages but means you have to check the right one.

The license field in the repository metadata is empty, but the README states MIT in its own protocol section. That is a discrepancy worth resolving in your own legal review before shipping anything commercial, and it is the kind of thing that takes a message to the maintainers to close.

If you are evaluating this for commercial use, the practical checklist is short: confirm the license text, confirm which package version you are actually installing, and read the documentation page for your specific widget rather than the front page.

## Conclusion

XRender makes sense when your team already lives in React and Ant Design and has a recurring pile of admin screens that look identical. It is a poor fit if you need one component, or if you are not willing to accept Ant Design as the visual system, because every piece here is built on it. Verify two things before committing: that the specific widget you need is in the library you expect rather than a sibling, and that the documentation site at xrender.fun covers your version, since the repository README is a wall of logos and the GitHub releases stop at 2025. A reasonable first step is to scaffold the docs locally with the dev script and read the guide for your widget there.

## FAQ

### What is XRender used for?

XRender is a suite of React libraries for internal admin tooling: FormRender for forms, TableRender for search and list pages, ChartRender for charts, and FormGenerator for building forms visually. All four sit on top of Ant Design and share one repository workspace.

### How do I run the XRender documentation site locally?

Clone the repository and run `npm run dev`, which sets `PORT=8080` and starts dumi in development mode. The root package.json also exposes `npm run build` for the turbo pipeline across workspaces and `npm run doc` for a production dumi build.

### Is XRender still being maintained?

The repository is not archived and the last push was on 2026-05-26. The GitHub releases trail behind that: the most recent are XFlow v1.0.4 from 2025-04-24 and FormRender v2.5.2 from 2025-03-20, with versions tracked per package rather than for the whole workspace.

## Sources

- [alibaba/x-render on GitHub](https://github.com/alibaba/x-render)
- [Issues](https://github.com/alibaba/x-render/issues)
- [Project website](https://xrender.fun)
- [README](https://github.com/alibaba/x-render/blob/master/README.md)
- [Releases](https://github.com/alibaba/x-render/releases)

---

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