Sexy Field Laravel Package

Getting Started

tardigrades/sexy-field is a base package, not a batteries-included field library — it exists to be extended. Expect to spend most of your first hour in vendor/tardigrades/sexy-field/src rather than in documentation.

1. Install and pin. With 1 star, 0 dependents, and no apparent stable release cadence, always pin an explicit version in composer.json rather than relying on ^:

   composer require tardigrades/sexy-field --prefer-dist
   

   Then hard-pin whatever tag or branch Composer resolved (or a commit hash for a branch).

2. Read the entry point first. Open composer.json and look at the autoload PSR-4 prefix, then read the service provider (typically src/SexyFieldServiceProvider.php or src/Tardigrades/SexyField/...). Look specifically for:

   • register() / boot() — what gets bound into the container
   • publishes() — any config, migrations, or view stubs
   • mergeConfigFrom() — the config key namespace

3. Publish anything that exists. If the provider registers publishes:

   php artisan vendor:publish --provider="Tardigrades\\SexyField\\SexyFieldServiceProvider"
   

   Inspect the resulting config/sexy-field.php — that config is almost certainly where field types get registered.

4. Find the abstract classes. The real API of a base package is its abstract base classes and interfaces. grep -r "abstract class\|interface " src/. These are what you will subclass.

First use case: create one trivial custom field (a text input or select) end-to-end — subclass the base field, register it in config, render it once in a Blade view — before touching anything real. That proves the package's contract to you in ~30 minutes.

Implementation Patterns

Subclass the base field and register it in config. The typical shape for a package like this:

namespace App\SexyField;

use Tardigrades\SexyField\Field;

class ColorPickerField extends Field
{
    public function render(): string
    {
        return view('fields.color-picker', [
            'name'  => $this->getName(),
            'value' => $this->getValue(),
        ])->render();
    }
}

Then add ColorPickerField::class (or a string key) to the fields array in config/sexy-field.php. If registration is by string key rather than class, prefer the class — you get IDE support and refactor safety.

Keep field definitions in code, not the database. If the package offers DB-backed field persistence, resist it for anything that maps to your domain. Use the package for rendering and validation, and keep the canonical schema in migrations. DB-driven fields make schema drift invisible and CI impossible to reason about.

Wrap rendering in a Blade component. Don't scatter {!! $field->render() !!} through views. One <x-sexy-field :field="$field" /> component gives you a single place to add error states, old-input repopulation, and escaping policy.

Pair with FormRequest validation rather than trusting package-local rules. If the base class exposes a rules() method, have it delegate to a shared validation class so the same rules serve both admin forms and API endpoints.

Test against the abstract base. If the package ships an abstract test case, extend it for every field you create — it will catch contract breaks when a composer update silently moves a method signature.

Gotchas and Tips

• Treat it as unmaintained until proven otherwise. 1 star and 0 dependents means nobody is stress-testing this against new Laravel versions. Pin the version, and consider forking into app/Support/SexyField/ (or a private VCS repo) if you depend on it in production. A 300-line base package is cheaper to own than to babysit.
• Auto-discovery may not be registered. Check config/app.php and composer.json extra.laravel.providers. Small packages sometimes omit it; if artisan throws "class not found," add the provider manually.
• Watch the config cache. After editing config/sexy-field.php, run php artisan config:clear. Field types registered in config will simply not exist after a cache rebuild if you edited the published file and forgot.
• Namespace collisions within the tardigrades/* family. If you also pull in tardigrades/sexy-field-* sibling packages, verify they don't each register a similarly-named config key or alias. php artisan about and php artisan config:show sexy-field are your friends.
• Debugging rendering failures. Because base packages usually return view()->render() from inside a class, Blade errors surface with a confusing stack trace pointing at the field class. Temporarily swap render() for dd($this) to see the field's internal state before the view layer.
• Extension points to inventory before you write code: abstract field base class, any Registrar/Factory/Manager class, boot()-registered Blade directives, and the config file. Those four cover ~90% of what a base package exposes — everything else is likely internal.
• Missing documentation is a signal, not an obstacle. Read the package's own tests (vendor/tardigrades/sexy-field/tests) — for an undocumented base package they are the de facto specification and often the fastest path to understanding intended subclass behavior.