Trov Components Laravel Package

Getting Started

This package is a Filament companion plugin, and v0.3.0 is a breaking release: its Panel component has been removed because the functionality now lives in Filament core. Before doing anything else, upgrade Filament itself and confirm which Filament version you're on — the package's Panel was merged into core, so the core version you run must be recent enough to expose Section.

Minimal upgrade path:

1. composer require <vendor>/<package>:^0.3 (or edit composer.json and composer update <vendor>/<package>).
2. Run composer update filament/filament in the same pass so Section is available from core.
3. Grep your app and any published views for the old component before you boot it:

   grep -rn "Panel" app/ resources/views/ tests/ --include="*.php" --include="*.blade.php"
   grep -rn "panel" config/ resources/views/ --include="*.php" --include="*.blade.php"
   

4. Swap each usage for Filament's Section, then load a page that renders it and check the layout.

Your first real use case is almost certainly a form or resource page where you were grouping fields inside the package's Panel. The direct replacement is:

{{-- before (v0.2.x) --}}
<x-<vendor>-panel heading="Details">
    ...
</x-<vendor>-panel>

{{-- after (v0.3.0) --}}
<x-filament::section heading="Details">
    ...
</x-filament::section>

If you have no Panel references anywhere, v0.3.0 is effectively a drop-in and you can upgrade without further work — but still run your test suite, since the removal can bite through dynamic component names or vendor-published Blade you've forgotten about.

Implementation Patterns

Bulk migration of Blade usages. Do this mechanically, not by hand, so you don't miss one:

# dry run first
grep -rl "<x-<vendor>-panel" resources/views | xargs sed -i 's/<x-<vendor>-panel/<x-filament::section/g'
grep -rl "</x-<vendor>-panel>" resources/views | xargs sed -i 's|</x-<vendor>-panel>|</x-filament::section>|g'

Do the opening and closing tags in separate passes, and review the diff — self-closing variants (<x-<vendor>-panel />) and namespaced forms (<x-vendor::panel>) won't be caught by the first pattern.

Attribute translation layer. If Panel and Section don't accept identical attributes, translate once rather than editing every call site. A small anonymous Blade component that forwards attributes keeps your templates stable:

{{-- resources/views/components/panel.blade.php --}}
@props(['heading' => null, 'description' => null, 'collapsible' => false])

<x-filament::section
    :heading="$heading"
    :description="$description"
    :collapsible="$collapsible"
    {{ $attributes }}
>
    {{ $slot }}
</x-filament::section>

Then migrate Panel → panel first, and only later inline the Section calls if you want to. This gives you a one-file rollback point if Section behaves differently in a specific layout.

Separate the upgrade commit from the API migration. Land composer.json + lockfile changes and the component rename in distinct commits. If something renders wrong, you can bisect the dependency bump against the markup change independently.

Wrap repeated form groups. Section is designed for exactly the grouping patterns Panel covered. Where you had a helper or partial that emitted a Panel around a repeated field set, point that partial at x-filament::section and leave the call sites untouched — that's the lowest-churn migration for anything generated in a loop.

CI guard. Add a grep step to your pipeline so the removed component can't creep back in via a stale branch or a copy-pasted snippet:

- name: Check for removed Panel component
  run: |
    ! grep -rn "<x-<vendor>-panel" resources/ app/ || \
      (echo "Use x-filament::section instead of the removed Panel component" && exit 1)

Gotchas and Tips

The component name change is the entire breaking change — but it's a hard failure, not a deprecation. A stale Panel reference throws a "component not found" style exception at render time, often on a page you don't visit in your happy-path smoke test. Grep the whole repo, not just app/: published views in resources/views/vendor/, theme overrides, and mail/PDF templates are the usual offenders.

Section is not a guaranteed attribute-for-attribute clone of Panel. The whole point of the merge was to consolidate, so assume some Panel-specific attributes or slots were dropped or renamed en route. Diff the old component's signature against Filament's Section before you trust a blind find-and-replace — check the package's v0.2.x source (still in vendor/ if you haven't updated, or on the tagged release) against core's Section class. Where an attribute has no equivalent, that's your real migration work, not the tag rename.

Watch attribute name collisions on the wrapper. If you use the forwarding component above, $attributes will pass through anything not explicitly declared — including class. Filament components merge classes in ways that can surprise you, so verify spacing on any call site that set class on Panel.

Published views are frozen at the version you published them. php artisan vendor:publish output does not update with the package. Re-publish (backing up your customisations first) or manually patch the published copies; otherwise you'll be running v0.3.0 with v0.2.x Blade.

Pin the old version if you can't migrate today. composer require <vendor>/<package>:^0.2 buys you time. Note the pairing: v0.2.x expects the pre-merge Filament, v0.3.0 expects Section in core. Don't upgrade Filament and the package independently without checking which side of the merge each expects — a half-upgraded pair is the most likely source of confusing errors here.

Tests are call sites too. assertSeeHtml, snapshot tests, and any Livewire::test() that asserts on rendered markup will fail on the tag change even though behaviour is identical. Update the expected strings — and if you have snapshot coverage, regenerate deliberately and read the diff rather than accepting it blind.

Debugging a blank or unstyled section: first confirm the tag actually resolved (<x-filament::section> with a typo renders as nothing or throws, depending on config), then check that Filament's assets are rebuilt if you use a custom theme — npm run build against the Filament theme is required after dependency bumps, and a stale asset build makes a correctly-migrated Section look broken.

Extension point: if you were subclassing or extending the package's Panel class in PHP, that class no longer exists. Extend or compose Filament's core Section instead, and keep your customisations in your own class so the next core merge doesn't strand you again.