VTable is a rush workspace with eight packages and a develop default branch

Eight packages sit in one rush workspace, not one manifest

The repository introduction enumerates what ships, and the split is by capability rather than by version. packages/vtable is the core code repository. vtable-gantt holds the Gantt chart component, vtable-editors the table editor components, vtable-plugins the plugins, vtable-export the export tool and vtable-search the search tool. Two of them are framework bindings rather than features: react-vtable and vue-vtable. The ninth entry, docs, is described as holding the site tutorials, demos, APIs and options plus all the Chinese and English documents. Around those sit the directories a rush layout needs: rush.json at the root, plus common, share, tools and types. So the source tree is a monorepo with shared internals, while the consumer only ever installs one of the packages.

Consumer install is one command, and the framework has its own

The installation section is two lines because there is one npm package:

// npm
npm install @visactor/vtable

// yarn
yarn add @visactor/vtable

That is the whole path for someone using the core table. Framework users install a different package, since react-vtable and vue-vtable exist precisely so that the bindings do not have to be part of the core. The documentation is split the same way: the introduction, a demo gallery, a tutorial for getting started and an API section whose example path is the ListTable option reference. A usage trend page comparing the package on npm is linked as well, and the project description itself frames the library in two terms, a high performance multidimensional data analysis table and a grid artist that creates art between rows and columns.

The demo derives everything from field and caption pairs

The quick start is short enough to read in full, and its structure is the API in miniature. The library is imported as a namespace from @visactor/vtable. A columns array is declared where each entry carries a field and a caption, and the five demo columns are Order ID, Customer ID, Product Name, Sales and Profit. An option object then carries a container, obtained from document.getElementById with a container id constant, and a records array whose objects are keyed by the same strings used as fields, with the first record carrying an Order ID of CA-2018-156720. The snippet is published so it can be run directly on CodeSandbox, which matters because the option shape is the contract and copying it into a sandbox is faster than assembling one from the option reference.

Contributing starts with rush installed globally, before the clone

The development section reverses the usual order, and the first requirement is a tool rather than a repository:

$ npm i --global @microsoft/rush

After that the repository is cloned and the dependencies are installed with rush update rather than npm or yarn at the root. Running the demo moves into the package directory and uses rushx demo, executed in ./packages/vtable, while the documentation server is started from the root with rush docs. One step after the code is finished is easy to miss: after committing, rush change-all has to be run from the root to update the change log. That requirement is why the repository also carries a change log driven file rather than leaving release notes to a maintainer, and it applies to every contributor, not only to maintainers.

A dependency problem is answered with rush purge, not a reinstall

There is a dedicated section for the case where the install misbehaves, and it is two commands:

$ rush purge
$ rush update

purge discards what rush has materialised locally and update fetches it again, which is the documented answer to a broken dependency state rather than a suggestion to change lock files. The same two commands appear in the documentation preview path, where the sequence is rush update, rush build and rush docs, the last of which serves the site locally after installation, clone and update. So there are three distinct levels of command in the project: workspace wide rush commands from the root, package scoped rushx commands inside a package directory, and ordinary npm or yarn commands for consumers who never touch rush at all.

Three claims rest on VRender underneath and VChart beside

The introduction places VTable on top of another project: it is based on the visual rendering engine VRender, which is a separate repository. From that base the project states three core capabilities. The first is performance, described as fast computation and rendering of millions of data points. The second is multidimensional analysis, where multidimensional data is analysed and presented automatically rather than being flattened by hand. The third is expressiveness, in the form of flexible graphics capability that integrates with the charts of VChart, the companion charting library. The relationship is worth noting for anyone choosing a stack: VTable renders the grid, VChart renders the charts beside it, and both sit on the same engine rather than on two unrelated renderers.

Tags track a 1.26 line while the default branch is develop

Two version facts matter when you pin a dependency. The recent releases are v1.26.6 published on 2026-08-04, v1.26.7 on 2026-08-20 and v1.26.8 on 2026-09-12, so the patch line advances every couple of weeks inside a single minor. The default branch, meanwhile, is develop rather than main or master, and the last push to it is dated 2026-09-28, after the newest tag. The repository is not archived. Reading the two together: the tags track the 1.26 minor line while development continues on a branch that is not where the tags are cut, so building from the default branch means building something newer than the newest release. The npm package that consumers install is @visactor/vtable, and the project also publishes Chinese and Japanese READMEs beside the English one.

Agent instructions and language variants sit at the root

Several root entries describe how work is expected to happen here rather than what the library does. AGENTS.md and CLAUDE.md are both present, and there is a skills directory with a skills-lock.json beside it, so the project carries machine instructions alongside human ones. Three languages of contribution guidance exist as CONTRIBUTING.md, CONTRIBUTING.zh-CN.md and CONTRIBUTING.ja-JP.md, matching the three README files. The Code of Conduct has its own file, and the contributing path points at both before any code. Linting is configured with .prettierrc.js, .prettierignore, .lintstagedrc and .editorconfig, and there is a .react19-deps directory, which lines up with the React bindings shipped as their own package. A test-release-build.sh script and a test_debug_output.txt file sit next to gantt_tasks.md, all three being working files kept in the repository rather than ignored.

Editorial conclusion

VTable suits a team already invested in the VisActor stack, or anyone who wants canvas based grid rendering with a React or Vue binding rather than a plain DOM table. It does not suit someone who wants a single repository with one package.json, because the source layout is a rush workspace with eight published packages and shared directories. Before contributing, install rush globally, expect to run rush change-all after every commit, and note that the default branch is develop while the tags track a 1.26.x line.

Frequently asked questions

Official sources

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