Sexy Field Bundle Laravel Package

Getting Started

This is a Symfony bundle, not a Laravel package — there is no service provider, no config publish tag, and nothing that will resolve out of Laravel's container. Before writing a single line of app code, spend 30 minutes reading the source. With 0 stars, 0 dependents and no ecosystem around it, treat it as reference code you may vendor, not as a dependency you composer require and forget.

Audit order:

git clone https://github.com/dionsnoeijen/sexy-field-bundle && cd sexy-field-bundle
cat composer.json          # Symfony version caps are the make-or-break detail
find . -maxdepth 2 -type d # look for Form/, DependencyInjection/, Resources/, Tests/

Read these files first, in this order:

1. composer.json — require tells you which Symfony majors it targets. A cap like ^2.8|^3.0 means it cannot be installed on a current app at all.
2. src/*Bundle.php — getContainerExtension() / getPath() show whether it registers services and ships templates/assets.
3. DependencyInjection/*Extension.php + Resources/config/services.* — the real surface area: which services are public, which tags (form.type, twig.extension) are applied.
4. Form/Type/* — the actual field types, their configureOptions() defaults and buildView() vars. This is the part you will copy or wrap.
5. Resources/views/Form/*.html.twig — form theme blocks. If they exist, they are the fragile part of any integration.
6. README.md and any Tests/ directory. If there are no tests, assume nothing works until you've run it.

First use case (Symfony host app): register the bundle in config/bundles.php, build one throwaway FormType that uses a single field type from the package, and render it in a scratch controller. Do not wire it into a real page until that scratch form renders, submits and validates.

First use case (Laravel host app): do not attempt to install it. Clone it, read Form/Type/, and port the option arrays into a Blade component or a laravelcollective-style field builder. The value here is the field semantics, not the code.

Implementation Patterns

Pin and vendor, don't track a branch. No releases means dev-master is a moving target:

"require": { "tardigrades/sexy-field-bundle": "dev-master#<full-sha>" }

Or fork it into packages/ and add a path repository, so you control the Symfony constraint bump when the host app upgrades.

Register narrowly in Symfony. Manual registration in config/bundles.php (Flex will not have a recipe for this):

return [
    // ...
    Tardigrades\SexyFieldBundle\SexyFieldBundle::class => ['dev' => true, 'test' => true],
];

Start in dev/test only. Promotion to all is a deliberate commit, not a default.

Wrap every field type in your own type. Never reference the package's classes directly from controllers or templates. One App\Form\Type\Sexy*Type per package type gives you a single seam to patch, swap or delete:

final class TagsInputType extends AbstractType
{
    public function getParent(): string
    {
        return \Tardigrades\SexyFieldBundle\Form\Type\SomeType::class;
    }
}

If the package later breaks on a Symfony upgrade, you rewrite one wrapper, not fifty form classes.

Opt the form theme in per-template, never globally. If the bundle ships Twig blocks, enable them only where needed:

{% form_theme form 'SexyFieldBundle:Form:fields.html.twig' %}

Confirm the exact path from getPath() and the Resources/views tree before trusting that string — bundle logical names differ between Symfony versions. Global registration in twig.yaml will silently override form_row/form_widget for the entire app and is the most common way this kind of bundle breaks an unrelated page.

Drive behaviour from options, not subclasses. Use the package's configureOptions() defaults and override per-field:

$builder->add('tags', WrappedTagsType::class, [
    'required' => false,
    // use only keys you verified in the package's configureOptions()
]);

Translate to Laravel as a Blade component, one-to-one. Keep the option array shape identical so the mapping stays obvious:

• package field type → resources/views/components/sexy/{name}.blade.php
• buildView() extra vars → component constructor props
• Symfony constraints → Laravel validation rules on the FormRequest
• bundled JS/CSS → copy to public/vendor/sexy-field/ in a small artisan command, and @once the asset include from the component

Smoke-test before integrating. A single test that builds the form, asserts createView() succeeds and renders without a Twig Unknown "..." error catches 80% of the integration failures here:

$view = $this->createForm(WrappedTagsType::class)->createView();
$this->assertSame('tags', $view->children['tags']->vars['name']);

Gotchas and Tips

• Zero-stars risk is the headline. 0 dependents means nobody is filing issues. Assume no maintenance. Budget for owning the code, and put the fork URL in your README so the next developer knows where it came from.
• Symfony-only architecture. Bundle, Extension, CompilerPass, tagged form.type services — none of it has a Laravel analogue. There is no ServiceProvider to discover, and composer require in a Laravel app will either fail on constraints or install dead code.
• The Symfony version cap is usually fatal. Run composer why-not tardigrades/sexy-field-bundle and read the require block. If it caps at Symfony 3/4, porting the field classes is cheaper than trying to satisfy the constraint.
• Form theme overrides leak. Bundle templates that redefine form_row, form_widget or choice_widget affect every form in scope. Always scope with {% form_theme form ... %} on the specific form, and check bin/console debug:twig for what actually got registered.
• Unknown options throw InvalidOptionsException at build time, not render time. When something explodes "randomly," diff your option array against the type's configureOptions() — that's almost always it.
• Debugging entry points: bin/console debug:container --tag=form.type to confirm the types registered; bin/console debug:container --tag=twig.extension for extensions; dump($form->createView()->children['field']->vars) for what the template actually receives.
• Assets are probably manual. If Resources/public/ exists, bin/console assets:install public --symlink (Symfony) or a copy-to-public/vendor step (Laravel port). Nothing publishes them for you.
• Extension points worth knowing: DataTransformer (for value marshalling between your entity and the widget), FormTypeExtension (add options to an existing type without forking), PRE_SUBMIT/POST_SUBMIT event subscribers (dynamic field behaviour), and form theme blocks (markup). Prefer these over editing the vendored source.
• No tests in the repo means no safety net on upgrade. Write your own smoke test before you pin the version, so a Symfony minor bump has something to fail against.
• The honest recommendation: for a Laravel codebase, don't integrate — port. For a Symfony codebase, use it behind wrapper types and a scoped form theme, or skip it if the composer constraints don't fit. At 0.52 confidence with no dependents, the package's day-to-day value is as a source of field ideas, not as a runtime dependency.