Laravel Thermite Laravel Package

Getting Started

Laravel Thermite is a Livewire-powered, Nova-style CRUD/admin panel generator: you describe an Eloquent model as a resource class with a list of fields, and Thermite renders index, detail, create, and edit screens for it — no hand-written controllers or Blade views.

1.0.0 platform requirements (verify before you start):

• PHP 8.0+ (7.3 and 7.4 support was dropped)
• Laravel 8.x or 9.x (7.x support was dropped; 9.x support was added in this release)

Minimal path:

composer require renoki-co/laravel-thermite
php artisan thermite:install        # publishes config/assets and scaffolds the service provider

If the install command isn't available in your version, publish manually:

php artisan vendor:publish --tag=thermite-config
php artisan vendor:publish --tag=thermite-assets

Then register your resources (typically in the provider created by the installer):

Thermite::resources([
    \App\Thermite\UserResource::class,
    \App\Thermite\PostResource::class,
]);

A resource is a small class extending RenokiCo\Thermite\ThermiteResource with a fields() method built from field objects (Text, Textarea, BelongsTo, HasMany, Boolean, Date, etc.). The panel is served at the path in config/thermite.php (default /thermite).

Where to look first, in order:

1. config/thermite.php — path, domain, middleware stack, per-page, branding.
2. One generated resource class — this is where 90% of your day-to-day work happens.
3. The field classes under RenokiCo\Thermite\Fields — read two or three to learn the make() / rules() / resolveUsing() conventions before writing a custom one.

First use case: pick your most boring internal model (a Tag, Category, or Announcement), write one resource with three or four fields, and confirm the CRUD flow works behind auth middleware before you invest in wiring up every model.

Implementation Patterns

One resource per model, thin and declarative. Keep business rules in the model, formatters, and policies — not in the resource. Resources should read like a schema: Text::make('Name')->rules('required|max:255'), BelongsTo::make('Author', 'user').

Authorization via policies, not conditionals. Thermite respects the standard Laravel policy/gate checks for viewAny, view, create, update, delete. This is the cleanest way to scope a panel to internal staff and to hide destructive actions from read-only roles. Don't reimplement authorization inside fields().

Relationship fields are the highest-leverage feature and the biggest performance trap. BelongsTo gives you a searchable dropdown; HasMany gives you a nested index. Always pair them with eager loading on the resource's underlying query, or the index page turns into an N+1 storm at 25 rows per page.

Custom actions for the "just one more button" case. Row and bulk actions defined on the resource keep ad-hoc operations (approve, resend, export) inside the panel instead of in a second admin tool. Put the actual work in a queued job or service class and let the action be a two-line dispatcher — actions that do real work inline become untestable and block the Livewire request.

Multi-model navigation. Group resources logically in the registration array; the sidebar order follows registration order in most versions. Treat that array as your information architecture and review it when you add a resource.

Testing. Because rendering is Livewire, Livewire::test() on the underlying component is the fast path for asserting a resource renders, a validation rule fires, or an action dispatches a job. Reserve Dusk/HTTP tests for the handful of flows where the panel's routing and middleware matter.

Local development workflow. Keep the panel enabled only in local/staging via the config enabled flag or middleware, and seed a realistic dataset — a Nova-style panel is only as useful as the relationships you can click through.

Gotchas and Tips

1.0.0 is a breaking release for the platform, not the API. The upgrade notes are all about dropped runtimes: PHP 7.3/7.4 and Laravel 7.x are gone. If you're on Laravel 7, you must upgrade Laravel first — Thermite 1.0.0 will not install. Budget the Laravel jump as the real work; the Thermite bump is the easy part. Pin "renoki-co/laravel-thermite": "^1.0" and run the suite after upgrading, since Livewire's own major version paired with Laravel 9 may also need attention.

2. Re-publish assets after upgrading. A Livewire-based panel serves compiled JS/CSS from public/vendor. After composer update, run php artisan vendor:publish --tag=thermite-assets --force and hard-refresh — a stale bundle produces "clicking does nothing" symptoms that look like application bugs but aren't.

3. Clear the right caches when the panel misbehaves. php artisan view:clear and php artisan optimize:clear fix most "my field change isn't showing" reports; Livewire component classes and Blade views are both cached aggressively.

4. Authorization fails open if you forget it. With no policy registered, gated abilities may resolve as allowed. Register a policy for every exposed model before deploying, and add an explicit canSee()-style guard or middleware for the panel entry point. This is the single most common way a Thermite install leaks data.

5. The default config is dev-friendly, not production-friendly. Check middleware, domain, and the path before going live. Wrapping the panel in ['web', 'auth', 'can:access-admin'] (or your own gate) is the norm.

6. Debugging a blank or 500 panel. Reproduce the resource in isolation with a Livewire test — the failing component usually points straight at the field or relationship definition. If a field silently doesn't render, check that the field class is imported from the correct namespace (RenokiCo\Thermite\Fields\...) rather than a similarly named class you wrote; wrong-namespace field objects are frequently accepted and then ignored.

7. Extension point: custom fields. When a built-in field doesn't fit, extend the base field class rather than forking the package — override the view, resolveUsing(), and validation. Keep those classes in app/Thermite/Fields so upgrades stay painless.

8. Upgrade hygiene. Treat the published config/thermite.php as your file after the first publish — new config keys in a future release won't appear automatically. Diff the package's shipped config against yours on every minor bump.