Getting Started

Do not install this package for new work. Version 1.4.2 is an explicit deprecation release: the upstream recommendation is to use Filament's built-in colour picker instead. The package should now be treated as legacy-only.

For an existing application, start here:

Check whether the package is a direct dependency:
```
composer show rvxlab/filament-colorpicker
```

Find all usages in your codebase:

grep -R "RVxLab\\\\FilamentColorPicker\|FilamentColorPicker" app/ resources/ config/ database/

Identify the field class currently imported in Filament form schemas.
Replace it with Filament's built-in Filament\Forms\Components\ColorPicker, then remove the package from composer.json.

A typical first migration is a one-line import and class swap:

// Before
use RVxLab\FilamentColorPicker\Forms\Components\ColorPicker;

// After
use Filament\Forms\Components\ColorPicker;

If the field configuration is basic, the form schema generally does not need to change. If you used package-specific methods or customisation, verify each one against the built-in component before removing the dependency.

For teams that cannot migrate immediately, pin the package to a known working version and treat it as frozen:

"rvxlab/filament-colorpicker": "1.4.2"

Avoid floating constraints such as dev-main or *. The code may be unchanged in 1.4.2, but future compatibility with Filament or PHP is not guaranteed.

Implementation Patterns

Recommended migration pattern

Use a short-lived compatibility layer rather than editing every form at once. For example, create an application-level field alias:

namespace App\Filament\Fields;

use Filament\Forms\Components\ColorPicker;

class AppColorPicker extends ColorPicker
{
    // Temporary extension point while legacy usages are migrated.
}

Then replace package imports with the application field. This gives you one place to add compatibility shims and one place to remove them later.

A more aggressive approach is a codemod across form classes:

# Inspect matches first
grep -R "RVxLab\\\\FilamentColorPicker" app/

# Replace imports and usages, then run tests and static analysis

Only automate this after checking for package-specific method calls.

Day-to-day usage if already installed

The field behaves like a normal Filament form component. Typical usage is in a resource form schema:

use Filament\Forms\Components\ColorPicker;

ColorPicker::make('brand_color')
    ->label('Brand colour')
    ->required();

Use it in the same places you would use any Filament form field:

Resource create/edit forms
Custom Filament pages
Action forms and modals
Table filters, if the field supports filter state
Widgets with embedded forms

For existing applications, keep usage narrow. Do not build new features, custom field extensions, or shared UI components on top of the deprecated package.

Data and validation

Colour pickers generally persist a string such as #RRGGBB. Confirm your application's expected format before and after migration:

ColorPicker::make('brand_color')
    ->regex('/^#[0-9A-Fa-f]{6}$/')
    ->required();

Check:

The database column type and length.
Model casts and accessors.
API resources or JSON output.
Validation rules in form requests and Filament schemas.
Any normalisation done in observers or model events.

If the built-in picker outputs a different format or supports different options, normalise at the application boundary rather than relying on the package.

Testing pattern

Prefer asserting form state and persisted data over asserting package-specific markup:

livewire(CreateProduct::class)
    ->fillForm([
        'brand_color' => '#ff0000',
    ])
    ->call('create')
    ->assertHasNoFormErrors();

$this->assertDatabaseHas('products', [
    'brand_color' => '#ff0000',
]);

This keeps tests valid after the component swap. Tests that assert CSS classes, asset names, or package view names will need rewriting during migration.

Integration tips

Centralise colour field creation in an application factory or helper if the field appears in many forms.
Search for package view overrides and published assets under resources/views/vendor/ and public/.
Check config/ for any published package configuration and remove it once the package is gone.
Search for the package namespace in Blade views, Livewire components, and JavaScript if custom assets were published.
Add a migration ticket or code comment near remaining usages so the deprecation is visible during review.

Gotchas and Tips

Deprecation means no maintenance

The most important pitfall is assuming 1.4.2 is a normal patch release. It is a deprecation signal. There is no commitment to future bug fixes, security patches, Filament compatibility, or PHP version support. Plan removal rather than waiting for a future release to fix issues.

Do not rely on Composer to enforce the migration

Composer will install the package if the constraint allows it. A deprecation notice in the release notes or README does not necessarily produce a hard install failure or CI error. Add an explicit check if you want to prevent new usage:

composer show rvxlab/filament-colorpicker

Or add a review rule or static-analysis check for the package namespace.

Filament version compatibility

The deprecation points to Filament 2.x documentation for the built-in colour picker. Verify the equivalent component and API for the Filament version actually installed in your application. Filament 2 and Filament 3 differ in form APIs, namespaces, and asset handling. Do not assume the migration is identical across major versions.

Colour format and alpha handling

Check whether existing data contains:

Short hex values such as #fff
Alpha values such as #ffffff80 or rgba(...)
Named colours
Empty strings or null

The built-in picker and the deprecated package may not accept or emit identical formats. Add validation and normalisation before migrating production data.

Asset and view publishing

If the package published assets, views, translations, or configuration, removing the Composer dependency alone may leave stale files. Search for:

grep -R "filament-colorpicker\|RVxLab" resources/ public/ config/ lang/

Remove published files only after confirming they are not referenced by application code.

Extension points are now unsafe

Any custom subclass, macro, view override, or wrapper around the package is effectively unmaintained. If business requirements depend on package-specific behaviour, fork the code or reimplement the behaviour on top of Filament's built-in field. Do not submit upstream-dependent changes expecting a release.

Debugging after removal

If forms break after removing the package, check in this order:

Cached config and autoload files:

composer dump-autoload
php artisan config:clear
php artisan view:clear

Remaining imports of the old namespace.
Cached Filament component registrations or cached views.
Published views still extending the package's view namespace.
Front-end assets referencing the old package's JS or CSS.

Recommended team policy

New projects: use Filament's built-in colour picker.
Existing projects: pin 1.4.2, stop new usage, and schedule removal.
Pull requests: reject new imports of RVxLab\FilamentColorPicker.
Security and upgrade planning: treat the package as end-of-life, not merely deprecated.

Filament Colorpicker Laravel Package