Habarico

Habarico is a schema-driven admin library for building admin dashboards in CMS and ERP applications. The backend exposes a JSON schema describing resources, fields, views, and actions; the frontend auto-generates the full admin UI from that schema without hand-written UI code.

This repository is a monorepo containing the three library implementations:

The paid extensions — dashboard and widgets, AI assistant, global search, change history, aggregations, chunked uploads and CZ localflavor — are developed and released from a repository of their own as habarico-enterprise (npm, PyPI and gem). They are documented on docs.habarico.com beside the free features, where their pages are marked premium.

The contract/openapi.yaml file contains the OpenAPI 3.0.3 specification that serves as the contract between backend and frontend.

The repository is not licensed as a whole — node/, python/ and ruby/ each carry their own LICENSE file and are MIT.

The paid habarico-enterprise packages are commercial and proprietary — use, copying and distribution only under a valid licence agreement with Eluvia.land s.r.o. They are developed and released from a repository of their own.

The free packages never reference the paid ones: a paid package registers itself through runtime extension points resolved by name, so the split is enforced in code, not only on paper.

1. A backend library (Ruby or Python) defines resources via a DSL or admin classes and exposes a schema endpoint.
2. The frontend library (JavaScript) fetches the schema and uses it to auto-render list, show, create, edit, and action views — including fields, inputs, filters, and layout containers (boxes).

The documentation website docs.habarico.com is the source of truth — installation, configuration and usage for all three libraries, the REST reference generated from contract/openapi.yaml, and the shared concepts:

• JavaScript — habarico
• Python — habarico
• Ruby — habarico
• API reference — the contract between backend and frontend

The pages live beside the code they document, in node/docs/, python/docs/ and ruby/docs/; write documentation there, not in the READMEs. Each library's README is a quick start — install, a minimal example, and a link to the site. The site itself is built from a separate, private repository, so contributors change the pages here and the published site follows with the next release.

All packages follow Semantic Versioning (MAJOR.MINOR.PATCH):

The three libraries share MAJOR.MINOR: a new minor or major moves all of them, even one with no changes of its own, and they are released together. Only patch releases are made per library. Each release is tagged <dir>@X.Y.Z (node@7.3.0).

The paid habarico-enterprise packages share MAJOR.MINOR with the free package of their language — habarico-enterprise 7.3.x is the release for habarico 7.3.x.

Version file locations:

OpenAPI schema (contract/openapi.yaml) is versioned via its info.version field and must be bumped together with any package that introduces a schema-level change.

Changes are tracked at two levels:

All changelogs follow the Keep a Changelog convention.

Package changelogs use version headers:

## [6.2.0] — YYYY-MM-DD

### Added
### Changed
### Deprecated
### Removed
### Fixed
### Security

Root changelog uses schema version or date:

## [schema 1.2.0] — YYYY-MM-DD   ← OpenAPI schema change
## 2026-05-15                     ← documentation-only change

1. Every release gets an entry. No release without a changelog entry, no matter how small.
2. Unreleased changes go to [Unreleased]. The top section always exists and is renamed to the version on release.
3. One bullet per logical change. Write for a human reader — describe what changed and why it matters, not implementation details.
4. Breaking changes are marked. Prefix the bullet with **BREAKING:** when the change requires action from library users.
5. Schema changes go to root CHANGELOG.md. Any change to contract/openapi.yaml must bump info.version and add an entry there, regardless of which package triggered it.
6. Omit internal-only changes. CI tweaks, test refactors, and tooling changes do not need changelog entries unless they affect users.
7. Reference YouTrack issues where relevant: (HAB-123).