Sexy Field Entity Laravel Package

Getting Started

tardigrades/sexy-field-entity sits on top of Dion Snoeijen's sexy-field field/form system and adds code generation: you describe a set of fields (name, type, options), and the package scaffolds the corresponding entity/PHP class for you. It is a small, zero-star, MIT-licensed package with no dependents, so treat the source as the documentation — the README is likely thin and the real contract lives in src/ and resources/stubs/.

Minimal path to a first result:

1. Install from VCS, not (only) Packagist. With 0 stars and no dependents, the version on Packagist may lag the repo. Add the repository explicitly and pin a commit:

   "repositories": [{ "type": "vcs", "url": "https://github.com/dionsnoeijen/sexy-field-entity" }],
   "require": { "tardigrades/sexy-field-entity": "dev-master#<commit-sha>" }
   

2. Check auto-discovery. Laravel 5.5+ will register the service provider if extra.laravel.providers is set in its composer.json. If not, add it manually to config/app.php.
3. Publish anything publishable. Run php artisan vendor:publish --provider="Tardigrades\\SexyFieldEntity\\...ServiceProvider" and see what lands (config, stubs, migrations). If the tag doesn't exist, list tags with php artisan vendor:publish and pick interactively.
4. Discover the actual command surface. This is the most important step for an undocumented package:

   php artisan list | grep -i -E 'sexy|entity'
   php artisan help <command-name>
   

   The generator commands will be in src/Console/ — read those classes to learn the argument signature before you script anything.
5. Where to look first, in order: composer.json (namespaces, provider), src/Console/* (what it generates and where), resources/stubs/* (the shape of the output), config/* (field-type → class mappings), tests/ (intended usage, if any exist).

First use case: describe a small entity — say a Product with name:string, price:decimal, description:text — run the generator into your app namespace, inspect the generated class, and wire it into a throwaway route before committing to the pattern. Do this on a branch; the value of the package is entirely in whether its generated output matches your conventions.

Implementation Patterns

Generate into a dedicated namespace, not App\Models. Point the generator at something like App\Entities or a module namespace (App\Modules\Catalog\Entities) via the package config. This gives you one directory you can diff, regenerate, and eventually eject from if the package is abandoned.

Keep generated classes as thin bases. The single most valuable pattern with any entity generator is the two-class split:

App\Entities\Generated\ProductBase   // regenerated, never edited
App\Entities\Product                 // extends base, hand-written

If the package's stubs don't support a base class out of the box, publish the stub and edit it — this is the primary extension point. Without this split, every regeneration is a merge conflict.

Drive generation from a checked-in field definition. However the package accepts fields (config array, fluent builder, or YAML/JSON), commit that definition alongside the generated output. The definition is the source of truth; the generated PHP is a build artifact. Add a composer script so regeneration is one command:

"scripts": {
  "entities": ["@php artisan sexy:entity --all"],
  "entities:check": ["@php artisan sexy:entity --all --pretend"]
}

Use --pretend/dry-run if the command supports it in CI to catch drift between the definition and the committed entities.

Treat the output as a starting point, then own it. Generated entities typically give you properties, maybe fillable, maybe casts. Expect to add by hand: relationships, accessors, validation rules, and casts for anything exotic. If the package maps field types to PHP types, verify the mapping for decimals (string, not float), dates (Carbon cast), and JSON columns before trusting it.

Integration with Eloquent. If the generated class is plain PHP rather than an Eloquent model, subclass it or have it extend Model via the stub. The cleanest integration is: generated base defines the schema-shaped surface (properties, casts, $fillable), your concrete model adds extends Model, relationships, scopes, and business logic.

Custom field types. The extension seam is almost certainly a registry or config map from field type → generator/stub. Bind your own entry there rather than editing package source; then your field types survive composer update.

Test the generated output, not the generator. A small test that instantiates a generated entity, mass-assigns an array, and asserts the resulting attributes/casts catches 90% of the breakage from a version bump or stub change.

Gotchas and Tips

Regeneration overwrites silently. Assume no merge protection. Before the first real run, git status must be clean, and the base-class split (above) should be in place. If the package writes directly to app/, generate once into a scratch directory and inspect every file before letting it touch your tree.

No migrations are generated — probably. "Field entity" suggests the PHP side only. You will still hand-write migrations, and they will drift from the field definitions the moment someone edits one without the other. Keep them in the same PR.

Config caching bites generators. php artisan config:cache during deploy is fine, but if the generator reads config at runtime and you're running it in a container, run config:clear first or the generator may read a stale field-type map.

PSR-4 / namespace mismatch is the #1 failure mode in small generator packages. If the generated class lands in the wrong place, the cause is nearly always a hard-coded namespace in the stub or a config value that doesn't match your composer.json autoload block. Publish and edit the stub; don't fix it post-generation.

Debugging a generator with no tests: the fastest route is to read the command class, identify the write call, and either (a) comment it out and dd() the generated string, or (b) point the output path at a temporary directory. Do this once and you'll understand the whole package — it is small enough that reading src/ end-to-end is a 20-minute exercise, and worth doing before you build on it.

Extension points to prefer, in order of durability: publishable stubs → config mappings → container bindings for generator classes → service provider extend(). Never patch vendor/; if you must, fork the repo, keep the VCS requirement, and pin the fork's commit.

Bus-factor mitigation is part of the implementation. Zero stars, zero dependents means no community to answer questions and a real chance the package stops tracking Laravel releases. Concretely: pin the commit, add the field definitions and generated output to version control, write the three-line smoke test described above, and know your exit path — because the output is plain PHP, ejecting means deleting the dependency and keeping the generated files. Design as if you'll eject in a year, and the package is a genuine shortcut rather than a liability.

When it's not worth it: if your project has fewer than ~10 entities or non-uniform field conventions, a generator adds more surface area (stubs, config, regeneration workflow) than it saves. The package pays off when you have many similar-looking entities derived from a form/field schema — that's the case to reach for it.