ngx-formly: Angular forms generated from a JSON schema

Reactive Forms underneath, not replaced

The feature list is short enough to be worth quoting accurately. Formly is described as a dynamic, JSON powered form library for Angular that brings unmatched maintainability to your application's forms. Its features are automatic forms generation, easy extension with custom field types, validation, wrappers and extensions, support for multiple schemas, and a set of themes out of the box.

The line that matters most for architecture is that it is built on top of Angular Reactive Forms. Formly does not replace Angular's form model. It generates a reactive form from a schema object, and you still get the `FormGroup`, `FormArray` and control APIs underneath. That is a materially different proposition from a library that renders its own inputs and manages state itself.

The practical consequence is that anything Angular users already know about validation, disabled state, dirty tracking and value access keeps working. You are not opting into a parallel form system. You are choosing how the form gets built rather than which form primitives exist.

The README also makes two schema claims: it supports the Formly Schema, which is the core format, and it supports JSON Schema. That second one matters if your backend already emits JSON Schema, since it means the shape of your forms can come straight from an API rather than being hand-transcribed.

One package per UI kit, and which version to install

The core package is `@ngx-formly/core`, and each supported UI library has its own integration package with a demo and a StackBlitz link in the README table. The list covers Bootstrap, Material, Ionic, PrimeNG, Kendo, NG-ZORRO and NativeScript.

That structure means choosing a theme is choosing a dependency, not configuring a theme. If you later want to move between UI kits you are swapping packages and rewriting type mappings, not changing a stylesheet.

The table that matters more is the version mapping, and it is unusually explicit for a project like this.

| Angular version | Formly version | | --------------- | ---------------------- | | Angular >= 19 | `@ngx-formly/[email protected]` | | Angular >= 18 | `@ngx-formly/[email protected]` | | Angular >= 13 | `@ngx-formly/[email protected]` |

So Formly major versions track Angular majors with a one-to-one relationship, and choosing a Formly version is really choosing an Angular version. Note the naming change at the bottom of that table: Angular 2 and above used a package called `ng-formly` at version 1.x, and the scoped `@ngx-formly/*` naming came later. Searching for setup instructions without checking which generation you are in is a common way to end up with code that will not compile.

The repository root keeps `UPGRADE-2.0.md`, `UPGRADE-5.0.md`, `UPGRADE-6.0.md` and `UPGRADE-7.0.md` as separate documents, which is both helpful and a warning: four documented major migrations means breaking changes have been routine here rather than exceptional.

Upgrading to v8 means moving Angular first

Version 8.0.0 was published on 2026-09-08 and its release notes lead with breaking changes rather than features. Angular 19 or newer is now required, and the instruction is specific about ordering: upgrade Angular first, then update all `@ngx-formly/*` packages together to v8. Applications on Angular 18 should remain on Formly v7.

That ordering is the actionable part. Because the Formly major is tied to the Angular major, there is no intermediate state where you are on Angular 19 with Formly 7. You either stay on 18 with 7.x, or move both.

The second breaking change is narrower but easy to miss. The Material, PrimeNG and NG-ZORRO integrations now require version 19 or newer of their respective UI libraries. So an application that upgrades Angular and Formly but leaves an older Material in place has not finished the upgrade. The other integrations named in the README, such as Bootstrap or Kendo, are not called out in that particular note.

The features in the same release are ordinary: a map function enabled on the transform option, among others. The signal to take from v8 is that the project's centre of gravity has moved to current Angular, and the README version table now leads with Angular 19 rather than trailing it.

JSON Schema conditionals and CSP-safe evaluation in v7

Version 7.1.0, published on 2026-02-01, contains the two features that most change what you can build.

The first is JSON Schema conditional logic using `if`, `then` and `else`. The release notes describe this as the JSON Schema service matching standard compliance, which lets you define conditional field visibility directly inside the schema. Before this, conditional forms were typically expressed in Formly's own extension or expression mechanism, which meant a schema that was not portable to plain JSON Schema. Now a form that shows a field based on another field's value can be written in the standard vocabulary.

The second is CSP-safe expression evaluation, which allows the library to be used in strict Content Security Policy environments without `eval()`. This one is easy to underestimate. Angular applications under a strict CSP cannot evaluate strings as code, and a form library whose expression evaluation depends on dynamic evaluation is a blocker for anyone with that policy. Adding a non-eval path removes an entire category of objection.

Version 7.0.1, from 2025-11-16, is more mundane but tells you about the API surface's churn: it exports `FormlyTemplate` for standalone use and fixes config merging when using `provideFormlyConfig`. Both are the kind of fix that indicates an ongoing move toward standalone Angular APIs rather than a settled surface.

How this repository is built and tested

The `package.json` at the repository root describes a monorepo workspace. The package is named `@ngx-formly/common`, which is the shared package the individual UI integration packages are generated from, and the version there is 8.0.0, matching the newest release.

The build and release scripts are the interesting part. Building runs a TypeScript script through `ts-node` with the build directory, publishing runs another, and releasing uses `standard-version` for changelog generation and versioning. GitHub releases go through `conventional-github-releaser` with commits following a conventional commit format enforced by `commitlint.config.js` and `git-cz`.

Testing is layered and the layering is visible in the tree. `jest.config.ts` and `jestSetup.ts` with `jestGlobalMocks.ts` cover unit tests, `karma.conf.js` is present for a browser test runner, `cypress.config.ts` with a `cypress/` directory covers end-to-end, and an `integration/` directory sits alongside. There is a script for server-side rendering end-to-end tests that starts a production SSR server, runs Cypress against it and kills the process.

That is a heavier test setup than most form libraries carry, and it makes sense given the package is generated across several UI integrations that must all behave identically. The `demo/` directory, `angular.json`, a Gitpod configuration and a `.node-version` file round out a repository set up so a new contributor can open it and run it without asking questions.

What it costs you, and the case against it

The honest case against ngx-formly is the abstraction tax. Writing a form as a JavaScript object that a library turns into components means your form is not directly readable as an Angular template, debugging a rendering problem means understanding the library's template resolution as well as Angular, and anyone new to the codebase has to learn Formly before they can modify a form.

That cost is worth paying when forms are numerous and similar. A back-office tool with forty forms that share a validation style and a layout is exactly the case. It is not worth paying for a contact form with four fields.

There is also a dependency-surface consideration. Adopting Formly means the core package plus a UI integration package, each carrying peer dependencies on a specific major of your UI library. Version 8 tightened that coupling rather than loosening it, since the Material, PrimeNG and NG-ZORRO integrations now demand version 19 of those libraries. You are trading a hand-written template for a version-locked dependency set.

The MIT licence keeps the legal side simple, and the documentation lives off the repository at formly.dev, split into a guide, a themes section and an examples section, plus an egghead video course of 20 lessons and 78 minutes listed in the README. The last push was on 2026-09-09, one day after the v8 release, and the repository is not archived.

Editorial conclusion

ngx-formly is a good fit when your forms are data-driven and change with a backend response, and a poor fit for a small fixed form, where the indirection costs more than it saves. What the repository settles is the Angular version to Formly version mapping, the fact that the core is built on Angular Reactive Forms rather than replacing them, and the size of the upgrade you are signing up for. What it does not settle is which UI integration matches your stack without trial and error, because the table in the README lists supported libraries without pinning versions. Check the upgrade notes, `UPGRADE-2.0.md` through `UPGRADE-7.0.md`, before crossing a major boundary, since v8 is the third documented major break in the repository root. For v8 specifically, Angular goes first and every `@ngx-formly/*` package moves together.

Frequently asked questions

Official sources

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