Sexy Field Api Laravel Package

Getting Started

This package is very small and effectively undocumented in the public record (0 stars, 0 dependents), so treat the repository as the source of truth and budget an hour to read it before wiring it in.

1. Install from source, pinned. Because there are no dependents, there is no crowd-sourced signal that any given branch works. Install by explicit constraint or VCS reference rather than an unpinned dev-main:

   composer require tardigrades/sexy-field-api --with-all-dependencies
   

   Confirm the version you land on, then pin it ("tardigrades/sexy-field-api": "1.x" or a commit hash) in composer.json.

2. Check what auto-discovery registers. Laravel will boot whatever ServiceProvider is declared in the package's composer.json extra.laravel.providers. Open that provider first — it tells you whether the package ships routes, config, migrations, or bindings. If discovery is absent, add the provider manually to bootstrap/providers.php (Laravel 11+) or config/app.php.

3. Publish and read the config. Run php artisan vendor:publish --provider="Tardigrades\\...\\SexyFieldApiServiceProvider" (get the exact FQCN from the provider file). If a sexy-field-api.php config appears, it will almost certainly hold the route prefix and middleware — those two keys determine how the endpoints are reachable.

4. Inspect the route surface before calling anything. This is the fastest way to understand the package:

   php artisan route:list --path=sexy
   php artisan route:list -v | grep -i field
   

5. First use case. The realistic day-one scenario is exposing "sections" of fields (a page-builder or CMS content model) as JSON to a frontend or editor UI. Start by hitting the collection endpoint with an authenticated request from php artisan tinker or a Pest test using $this->actingAs($user)->getJson('/api/...'), and dump the raw response shape. Everything downstream — API resources, TypeScript types, frontend rendering — keys off that shape, so get it documented early.

6. Where to look first, in order: routes/ → src/Http/Controllers → the models/tables the controllers touch → config/ → src/Providers. Skip the README until last; on a package this small the code is more reliable than the prose.

Implementation Patterns

Wrap the package routes instead of consuming them raw. Register the package's endpoints behind your own middleware group in a dedicated route file, or override the config's middleware key. You almost never want a content-editing API reachable unauthenticated — attach auth:sanctum (or your guard) plus an authorization gate for edit operations:

// config/sexy-field-api.php
'middleware' => ['api', 'auth:sanctum', 'can:manage-content'],

Proxy through your own controllers when the contract needs to be stable. If the package's JSON shape is not something you control, put a thin controller in front of it that maps the package's output into your own API Resource. That gives you a seam to swap or fork the package later without breaking your frontend. It costs ~30 lines and buys you a lot of optionality on a zero-star dependency.

Use it as the admin/editor layer, not the public read path. The package name ("field section endpoints") suggests CRUD over section definitions. Serving your public marketing pages directly out of an unmaintained CRUD endpoint couples your frontend to its response format and its query patterns. A common pattern: use these endpoints in the CMS admin only, and cache the rendered result into your own read model or a static cache for the public side.

Test against the routes, not the classes. Since the internals may change, write feature tests that hit the HTTP endpoints:

it('returns sections', function () {
    $this->actingAs(User::factory()->create())
        ->getJson('/api/sexy-field/sections')
        ->assertOk()
        ->assertJsonStructure(['data' => [['id', 'fields']]]);
});

These tests survive a fork, a version bump, or a rewrite of the controller internals — which is exactly the risk profile here.

Extend via container bindings. If the provider binds a repository/manager interface, rebind it in your own AppServiceProvider rather than editing vendor code. That is the one extension point worth checking for immediately; if it exists, it is your escape hatch for adding caching, scoping by tenant, or adding eager loading without forking.

Seed and fixture realistically. Content-section APIs are shape-sensitive. Build a factory/seeder that produces sections with the maximum number of fields and nesting you expect, and develop the frontend against that. Half the integration bugs in this kind of package come from the frontend assuming a field is present when the section type does not include it.

Gotchas and Tips

• Zero dependents is a real signal. There is no ecosystem confirming this works on current Laravel versions. Before adopting, check the illuminate/* constraints in composer.json against your app's version. If it targets Laravel 8/9 and you are on 11, expect composer update conflicts and possibly deprecated APIs ($dates, Route::namespace, string-based model references in routes).
• Fork it on day one. For a package this small, a dionsnoeijen/sexy-field-api fork under your org is cheaper than fighting upstream. It also lets you add the tests, config, and middleware defaults the package lacks. Keep the fork as a VCS repository entry in composer.json and pin the branch.
• Route caching can bite. If the package registers routes with closures or resolves config at registration time, php artisan route:cache may serialize fine but behave differently from the uncached run — or fail outright on closures. Always validate with php artisan optimize && php artisan route:list in a staging build, not just locally.
• Config caching. Anything the package reads via config() at boot is frozen by php artisan config:cache. If you change the route prefix or middleware and see no effect, you forgot php artisan config:clear.
• Middleware mismatch is the #1 "it 404s" cause. A route registered in the web group will 419 on POST from an SPA because of CSRF; the same route in api will 401 without a token. Check route:list -v for the exact middleware stack before debugging anything else.
• Watch for N+1 on sections → fields. A naive Section::all() followed by per-row field access will explode on a page with fifty sections. Add ->with('fields') in a rebound repository, or accept it only for the admin editor where lists are paginated.
• Mass assignment and authorization. If the package uses $request->all() with Model::create(), verify the $fillable/$guarded on the underlying models. A field-section API that lets a client set arbitrary columns is a privilege-escalation path in a CMS context. Add a FormRequest or a policy in front rather than trusting package defaults.
• Table name collisions. If the package ships migrations, check migration filenames and table names against yours before running php artisan migrate on anything shared. On a fresh local DB it is safe; on an existing one, dry-run with --pretend first.
• Debugging the response shape. dd() inside a vendor controller is fine short-term but easy to leave behind — prefer Log::info() or Laravel Telescope's request payload/response view, and revert vendor edits before committing (or better, do the instrumentation in your proxy controller).
• No changelog means read the diff. Before any composer update, run composer diff or diff the vendor directory. Without release notes, a patch bump can silently change a response key.
• Document the response contract yourself. Write the JSON shape into a test or an OpenAPI stub in your repo. When the package is abandoned (a question of when, not if), that document is what lets you reimplement it in a day.