fast-crud: a Vue 3 CRUD layer driven by a column config

One column config drives the table, the form and the search

The central idea is that a CRUD screen is described once, as data, and the framework turns that description into the interface. The project describes itself as an options-oriented CRUD framework built on Vue 3, and the configuration object is a columns map where each entry carries a title, a type, and per-surface options. A field can declare a column width for the table, a search flag that makes it appear in the query bar, and a form flag that hides it from the edit form, which is how an id column is kept out of the way while a name field becomes searchable. The field type is what drives the generated form control, so a text field produces a text input, a dict-select produces a select, and a dict-radio produces a radio group. The framework's stated features follow from that: configuration-oriented CRUD programming that can serve as the base of a low-code platform, a data dictionary, a range of field types, custom field types, extension components and support for multiple UI libraries. The audience is a developer who has written the same list-and-form screen forty times and would rather not write the fortieth.

Dictionaries, local and remote, are the interesting part

The data dictionary feature is the one that goes beyond a generic table. A dictionary binds a stored value to a label to display, which is the pattern every admin interface needs and most forget. The dictionary helper is called with either a local data array or a remote url, and the configuration marks which one is in use. A local dictionary in the example carries id, text and an optional colour per entry, so the select renders a coloured tag rather than a bare code, and the entries are cities with their own identifiers. A remote dictionary is declared with a url and a single flag, and the framework fetches the options from the server instead. Because the field type is dict-radio in that example, the same dictionary mechanism produces a radio group rather than a dropdown. This is the piece that makes the configuration approach pay off, since the alternative is to hand-write a component for every enumerated field, and it is also the piece that ties the front end to a particular backend contract for dictionary endpoints.

The component is the product, the scaffold is a sample

The project is explicit about scope in a note that is easy to miss. It says the main goal is the fs-crud component, which helps you develop CRUD features quickly, and that the admin scaffold is not the focus. It then gives three ways to use it. Use the bundled fs-admin example directly, which is the simple option. Or take another open source admin project and integrate fast-crud into it, with an integration guide in the documentation. Or pick from the admin-starter collection the maintainers have built by integrating fast-crud into other admin projects. The topics list and the package list both confirm the structure, with packages for the component itself, the ant design admin sample, extensions, an ecology package and per-UI packages under a ui- prefix. The sample scaffold fs-admin is a separate concern with its own dependency list, including vue-router, antdv 3x, pinia and purge-icons, and it credits d2-admin, antdv-pro and vben-admin as reference projects. For a team with an existing admin shell, the component is the part to take.

A lerna monorepo with generated docs and a publish gate

The build infrastructure is a monorepo managed with lerna, with a pnpm workspace file and the packages/ directory holding the individual packages. The root package.json is private and named fast-crud-root, and its scripts show the whole release flow. The bootstrap script runs lerna bootstrap with hoisting. Documentation is built with vitepress from the docs/zh directory, with separate dev, build and serve scripts. The component and extension API documentation is generated rather than written, with vue-docgen reading the source and writing markdown through docgen/crud.config.js and docgen/extends.config.js, and there is a docgen/ directory and a docgen:all script that chains both. Before anything is published, a check runs through publish-check.mjs with the experimental json modules flag, and the prepublishOnly script builds a selected set of scopes. Publishing goes through lerna publish with conventional commits and a GitHub release, with a canary mode for prereleases. There is also a deploy.js at the root, a skills/ directory, an AGENTS.md and a CLAUDE.md, and a CHANGELOG.md that is regenerated with conventional-changelog using the angular preset. The setup step for a fresh clone is the init script, which is a submodule update:

git submodule update --init --recursive

The lerna bootstrap is the other half of a working local setup, run from the repository root:

lerna bootstrap --hoist

Three UI libraries, and why that choice is not free

The framework supports Antdv, Element Plus and Naive UI, and the README asks you to pick one, describing the choice as choose whichever you like. The value of that is real, because a Vue 3 admin project usually has an existing UI library and a component that is locked to one of them cannot be adopted. The cost is that the component must express its behaviour in terms of each library's own components, and the per-UI packages under the ui- prefix in the publish scopes are where that translation lives. It also means the configuration vocabulary is partly library-independent, the type names and the flags are, and the column, form and search options are, while the rendering is not. In practice, choosing a UI library is a decision you make once for a codebase, and the fast-crud configuration is written against that decision. The documentation also carries a note that the fs-admin-antdv4 example adopts the vben5 layout framework, which is a useful pointer for anyone assembling a full admin shell rather than just a CRUD screen.

Where fast-crud is the wrong tool

The scope is the limit, and the project is upfront about it. This is a CRUD screen generator, not a data layer, so it does not solve how your list endpoint is paged, filtered or sorted, and it does not define the REST contract your backend should implement. It assumes a list API and a set of create, update and delete endpoints, and the whole configuration model assumes the screen is a table of rows with a form above it, so a screen that is a tree, a kanban board, a timeline or a graph is not what it is for. The dictionary feature also imposes a contract, since a remote dictionary is fetched from a url, so a backend that exposes its enums differently needs an adapter. The multi-UI support is another constraint in practice, since the column configuration is written against one library's components, the choice is per application rather than per screen. And the delivery vehicle is a young monorepo: the published tag is v1.29.0 from 2026-10-13 while the root package.json still says 1.9.0, the docs live on a separate mirror domain, and the project advertises paid remote support through a group chat, which is a signal about who is expected to maintain an integration.

Editorial conclusion

Adopt fast-crud if you build Vue 3 admin interfaces and your screens are mostly list, filter, create, edit and delete against a REST backend, and if you can accept the coupling to its component model. Do not adopt it expecting a general low-code platform, since the project describes that as a base it could serve rather than something it delivers, and do not expect the bundled admin scaffold to be the product. Before you start, pick the UI library once, since the component is written against Antdv, Element Plus or Naive UI, and note that the published tag is v1.29.0 while the root package.json still reads 1.9.0, so check which version you actually install.

Frequently asked questions

Official sources

1. fast-crud/fast-crud on GitHub
2. License: MIT
3. Project website
4. README
5. Releases