AG Grid's paid tier starts exactly where grids get hard

The commercial tier begins where grids become difficult

The readme describes two versions and the split is the most important thing in the file. The community package is free under the MIT licence and carries what most teams reach for first: sorting, filtering, pagination, cell editing, custom components and theming. The enterprise package is under a commercial licence and adds row grouping, aggregation, pivoting, a master and detail layout, the server-side row model, integrated charting, a formulas feature, an AI toolkit, find and exporting, plus dedicated support from the engineering team. Read that list as an argument about where the difficulty lives. Everything on the free side is client-side convenience; everything on the paid side is about data too large or too shaped to handle in the browser. If your requirement is grouping or pivoting on day one, the free package will not get you there.

The dependency-free claim, and the three dependencies in the root

The headline description calls this a fully-featured and highly customizable JavaScript data grid with no third-party dependencies, delivering outstanding performance, and it claims support for React, Angular and Vue through separate packages under the monorepo. The claim is narrower than it sounds, and the root manifest explains why. The repository's own dependency list contains exactly three runtime packages: a file-copying utility, a YAML parser, and the TypeScript runtime helper. None of those is a grid dependency. They exist because this repository builds the grid, its documentation site and its tooling in one place. So the defensible reading is that the published grid package pulls in nothing you did not choose, while the development checkout is not dependency-free. That distinction matters for anyone auditing what ends up in a browser bundle.

A default branch named latest, and versions stamped with a date

The branch and version naming in this repository is unusual enough to trip people up. The default branch is not master or main but latest, which is also what the readme's asset links point at. The root manifest is private, named after the project, and its version field is not a plain release number: it reads as a release line with a beta marker, a date and a clock time. The published tags are different again, a release branch name plus a version, with a plain version tag attached, and the recent history shows a 36.2.0 release, a 36.1.0 release and a patch on the earlier line. So there are three version vocabularies in play: the branch, the internal stamp and the release tag. If you are pinning in a lockfile, pin the tag, and if you are contributing, expect the manifest version to look unstable because it tracks nightly builds.

The bootstrap script uses a private registry and gates install scripts

The scripts section is the most revealing part of the manifest. Bootstrapping sets three environment variables before anything runs: telemetry disabled, an override telling a native image library to ignore a globally installed copy, and the yarn registry pointed at the project's own host rather than the public one. It then installs with scripts ignored, passes the result through a tool whose job is to allow specific install scripts, and finally runs the postinstall chain. Those postinstall steps are worth reading individually. One applies patches from a directory committed in the repository, and it is skipped when a fast-path variable is set. Another builds code generators through the task runner. Then two steps install git hooks and set up editor prompts, both from shell scripts inside the repository. For a team that cares about supply chain, this is the file to read: install scripts are not trusted by default, patches are reviewed in-tree, and the registry is the vendor's.

A hand-written script deletes your local branches for you

Two developer scripts in the root deserve attention because they are unusually direct about what they destroy. The clean script removes every untracked and ignored file and resets the working tree to the last commit, which is the sledgehammer version of starting again. The purge script is cleverer and worth reading once: it fetches with pruning, then enumerates local branches together with their upstream tracking status, filters for branches whose upstream is gone, strips the remote prefix and deletes them one by one. It is a shell loop with a text-processing filter doing something a version control tool does not offer directly, which is the kind of utility a large team accumulates. Both scripts sit next to the behavioural test runner and the documentation end-to-end runner, which are separate shell entry points rather than tasks in the main script list.

Documentation has its own end-to-end suite and a cache invalidation script

The repository treats documentation as a tested artefact. There is a separate end-to-end script for the documentation site, another for the grid itself, a benchmarks shell script and a checks script, so the four concerns are separate entry points rather than one command. Then there is the script whose name tells you how the docs are hosted: it invalidates a CDN cache. That implies the documentation is served from a content delivery network with a cache that has to be purged on deploy, which is a different deployment shape from the package itself. Alongside those sit the version pins. There are two files pinning the runtime, one for the version manager that reads a file in the home directory and one for the tool that reads a file in the repository, and an ignore file for the task runner, which is how a monorepo this size keeps a targeted build from crawling documentation.

Nx, Vitest and esbuild under a workspace with submodules

The file listing describes a workspace assembled from several tools at once. A task runner configuration and its ignore file run builds and scripts across packages. A Vitest configuration and a Vitest workspace file run the tests. An esbuild configuration, plus a separate plugin file whose name says it exists to alias a superclass, handles bundling. A PostCSS plugin file and a stylelint configuration with its own ignore handle stylesheets. The linting is a flat ESLint config, formatting uses Prettier with its own ignore, and TypeScript is configured from a base file shared by the packages. There is a git submodules file, an external directory for shared code and website tooling, a community modules directory, and directories for plugins, testing helpers and utilities. The dependency list also includes a sequential-thinking server implementation for the model context protocol, and the feature matrix's first visible row is an MCP server for the grid itself, so the project both ships and consumes an agent-facing surface.

Editorial conclusion

AG Grid fits a team that needs a real data grid in a framework it already uses, especially one that starts with client-side rows and may not need grouping. It does not fit a team whose requirements include pivoting, aggregation or a server-side row model on day one, because those sit in the commercial package, and the readme is clear about where the boundary falls. Before you commit, read the two package descriptions side by side rather than the feature matrix headline, and decide which framework wrapper you need, since React, Angular and Vue each have their own package directory. Then read the bootstrap script before you install, because it uses a private registry and gates install scripts through a sandbox tool. The newest release is 36.2.0 from 2026-09-16 and the default branch was pushed on 2026-10-01.

Frequently asked questions

Official sources

1. ag-grid/ag-grid on GitHub
2. Issues
3. Project website
4. README
5. Releases