Adminix Documentation Help

Development

This page is for contributors who work on the Adminix package itself.

Official Laravel support is limited to Laravel 12 and 13.

Install dependencies

Install package dependencies from the package root.

composer install

If you change development dependencies, update the lock file intentionally.

composer update --prefer-stable

Run tests

Adminix uses PHPUnit with Orchestra Testbench for package-level regression tests.

composer test

or

./vendor/bin/phpunit

Check coverage

Coverage requires a PHP coverage driver such as Xdebug or PCOV.

composer coverage

The command writes:

  • build/logs/clover.xml;

  • coverage/ HTML report;

  • text summary in the terminal.

Use coverage locally before release-sensitive changes when a coverage driver is available.

Format code

Run Laravel Pint before publishing changes.

composer pint

Inspect package integration

Use Adminix Doctor when changing configuration, page discovery, modules, console commands, or docs that affect consuming app setup.

php artisan adminix:doctor

Use --json for machine-readable output and --strict when warnings should fail a local or application pipeline.

Run Qodana

Adminix includes a local Qodana PHP scanner configuration. Run it locally only when needed. Adminix CI does not run Qodana and the project does not use Qodana tokens.

qodana scan --config qodana.yaml

What to cover

When changing core behavior, add or update regression tests for the affected public contract:

  • page generation and route parameters;

  • module factories and data provider resolution;

  • datasource validation for table names and Eloquent class strings;

  • list lenses, filters, escaped search, sorting, pagination, actions, and criteria validation;

  • invalid date filters and browser-provided sort directions;

  • resource loading, validation, create, update, readonly, empty writable input, image URL/path, and JSON textarea flows;

  • unique validation ignores for string rules and Rule::unique() objects;

  • modal API fetch, save, create, malformed params, empty writable input, and validation behavior;

  • authorization middleware behavior, session regeneration on login, and POST-only CSRF-protected logout;

  • console commands, Adminix Doctor diagnostics, and publish paths for public assets.

  • generator options, generated stubs, force behavior, and package-safe test stubs.

  • CKEditor 5 runtime publishing and editor textarea synchronization.

  • shared endpoint resolution, controlled endpoint errors, criteria operators, SQLite-compatible query behavior, and no-JS fallbacks where the rendered HTML can still submit safely.

Keep tests focused on package contracts rather than implementation details.

SemVer

Use patch versions for bug fixes, docs, tests, frontend polish, and internal refactors that preserve the public PHP DSL and route/config contracts. Use minor versions for additive Adminix APIs such as new modules, fields, opt-in module methods, console options, providers, DTOs, and publishable assets. Use a major version only for breaking DSL/config/route contracts, changed persistence semantics, removed module methods, changed package support ranges, or behavior that consuming Laravel applications must rewrite.

CI

GitLab CI only builds the Writerside documentation artifact and publishes GitLab Pages. Package tests, Pint, coverage, and compatibility checks are local release gates, not CI jobs.

Laravel Boost

Adminix exposes Laravel Boost resources:

  • resources/boost/guidelines/core.blade.php;

  • resources/boost/skills/adminix-development/SKILL.md.

Keep guidelines short and action-oriented. Keep the skill as a high-signal Adminix module API reference for agents in parent Laravel projects, covering page providers, menus, list/search/filter/action flows, resource forms, modal CRUD, charts, counters, links, safety rules, and package checks. It should summarize operational behavior without duplicating every Writerside example.

Last modified: 22 June 2026