Demo

Concept

Rebuilding an app from scratch every time is slow and exhausting — if you keep rewriting login, roles, permissions, menus, and database wiring on every project, real business features arrive late. Quark ERP’s concept is derived from Odoo ERP: a thin core plus modules you extend. With Quark ERP you focus on business logic only. The core owns the foundations and loads your plugin code at runtime — accounting, inventory, POS, and other domain plugins come alive when the system starts, not when you compile.

Important: Naming

Read this before anything else. This framework was first built only for The Paradance’s own internal use, under the name quan-erp. Later it was open-sourced and the product was renamed Quark ERP. Docs and the UI now say Quark ERP — but when you develop in your codebase, you must still install and import @quan-erp/* packages. That npm scope was kept on purpose so existing imports keep working.

  • Say Quark ERP when talking about the product, docs, or UI
  • In your codebase, always use @quan-erp/* packages (example: @quan-erp/shared-ui)
  • Do not look for @quark-erp — that scope does not exist

What’s already in the core

The base runtime already includes the platform layer most ERP projects rebuild first. Use these capabilities instead of re-implementing them inside every plugin.

  • Auth & security — login, sessions, roles, permissions, and API guards
  • Builtin data — users, partners, branches, settings, files, currency, and related services
  • Backend runtime — DI container, routers, module lifecycle, cron/queue, and plugin env
  • Frontend shell — menus, routes, localization, spotlight search, dashboard, home shortcuts, and public routes
  • Your plugins add domain features on top of this core — they should not replace it

What is a plugin?

A plugin is a self-contained package with backend APIs, database tables, and React screens. The base app stays thin and loads plugins dynamically.

  • Source lives under plugins/<name>/ with backend/, frontend/, and module.metadata.json
  • The core discovers plugins via metadata and the module database table
  • Plugins never import another plugin’s src/ — they use shared libraries and declared dependencies

How it works

The base app discovers plugins from metadata, loads them in dependency order, then each plugin registers backend services and frontend surfaces.

Plugin lifecycle

From disk to a live feature in the ERP UI:

Shared libraries

Plugins should stay lean and reuse platform packages:

  • @quan-erp/shared-backend-core — decorators, DTOs, services
  • @quan-erp/shared-frontend-core — hooks, API helpers, sensors
  • @quan-erp/shared-ui — design system components
  • @quan-erp/shared-types — shared TypeScript contracts

Versioning rule

All @quan-erp/* packages in a plugin and the base images in docker-compose.yaml must use the same version (for example ^1.0.0) to avoid dependency conflicts.