Type Bundle Laravel Package

Getting Started

Verify before you install. This is an archived, single-star package with zero dependents and no release since December 2015. Treat the repository itself as the only documentation — there is no maintained docs site, no test suite you can point at as a contract, and no upgrade path. Before writing any code, read composer.json and the Form/Type/ directory from a pinned commit rather than from a version constraint.

Minimal steps:

1. Confirm your Symfony version. The description says Symfony 2.3, which is long EOL. If you are on anything modern (Symfony 3+ / 4+ / 5+), the bundle will not autoload correctly — it predates PSR-4 conventions and the AbstractType signature requirements that landed in 2.8/3.0. Check whether the types implement setDefaultOptions or configureOptions; that single detail tells you which Symfony generation it targets.
2. Pin the commit. Use an explicit commit hash in composer.json, not dev-master, since the repo is archived and the tag history stops at 2015-12-29.
3. Register the bundle in AppKernel::registerBundles() — look at the bundle class name in the repo root; it will be Vince\TypeBundle\VinceTypeBundle or similar depending on the psr-0/psr-4 namespace declaration in composer.json.
4. Read the types first. Open every file in Form/Type/. There are likely only a handful. For each, note the getName() (Symfony 2.x style) or getBlockPrefix() return value — that string is what you will pass to ->add() in your forms and what the Twig theme file, if any, keys off.

First use case: the most likely payoff is a single form type you would otherwise hand-roll. Start by wiring one bundled type into one existing form:

$builder->add('field', \Vince\TypeBundle\Form\Type\SomeType::class);

Render it, confirm the widget output matches what you expect, and only then decide whether the rest of the bundle is worth adopting.

Implementation Patterns

Use them as leaf types, not as a framework. A form-type bundle from this era is a grab bag of AbstractType subclasses plus maybe a Twig theme and a DI extension. The healthy pattern is to consume one or two of those types inside your own AbstractType subclasses, so your forms stay portable if you later need to drop the bundle.

class CheckoutType extends AbstractType
{
    public function buildForm(FormBuilderInterface $builder, array $options)
    {
        $builder
            ->add('address', AddressType::class)          // yours
            ->add('phone',   \Vince\TypeBundle\Form\Type\PhoneType::class); // theirs
    }
}

Compose with CollectionType. If the bundle ships anything reusable, it is most valuable as the inner entry_type of a collection, where it saves you writing the same repeated sub-form per project:

$builder->add('contacts', CollectionType::class, [
    'entry_type'    => \Vince\TypeBundle\Form\Type\ContactType::class,
    'allow_add'     => true,
    'allow_delete'  => true,
    'by_reference'  => false,
]);

Reuse the bundle's Twig theme if present. If there is a Resources/views/Form/*.html.twig, add it to your Twig config's form_themes list rather than copying blocks into your own templates — the widget markup and the getBlockPrefix() values are coupled, and a partial copy will silently render unstyled or default-rendered fields.

Treat it as a code donor, not a dependency. Given the archive status, the highest-value workflow is: copy the Form/Type file you need into your own bundle, rewrite it against your Symfony version's configureOptions(OptionsResolver $resolver) signature, and delete the composer dependency. This is a 30-minute job per type and removes the entire maintenance risk. If the type is trivial (a MoneyType wrapper, a DateTimeType variant, an ImageType), this is almost always the right call.

Wrap the dependency behind your own type. If you must keep the dependency, expose it through your own AbstractType so call sites reference your class, not the vendor's. When you eventually replace the internals, only the wrapper changes.

Gotchas and Tips

Assume it does not work with your Symfony. The single biggest pitfall: code written for 2.3 uses setDefaultOptions(OptionsResolverInterface $resolver), which was deprecated in 2.6 and removed in 3.0. You will get a fatal error or a silently ignored options array. Grep the types for setDefaultOptions and getName() before anything else — those two markers date the code precisely.

Zero signal means zero safety net. One star and no dependents means there is no StackOverflow corpus, no downstream code to compare against, and no issue history that reflects real usage. Any bug you hit is yours alone. Budget for reading the source rather than searching for answers.

Autoloading is the usual first failure. Pre-2016 bundles commonly declare "autoload": { "psr-0": { "Vince\\TypeBundle": "" } } with the source at the repository root. If composer require succeeds but the class is not found, check that psr-0 mapping and the actual directory nesting before you start editing namespaces.

Bundle registration can be required even for pure form types. If there is a DependencyInjection/Extension that registers a form theme or a FormExtension, forgetting registerBundles() produces working forms with wrong rendering — a confusing failure mode because nothing errors.

Do not inherit the options resolver. If a bundled type hardcodes its options, do not subclass it to add more; you inherit the 2.3 signatures. Copy the type instead.

Extension points are limited to what you can see. With no Form/Type/Extension directory or tagged form extensions, the only integration surface is the AbstractType API plus the Twig theme. There is no event subscriber, no compiler pass of substance, and no configuration tree to lean on. Do not design around a hook that does not exist.

Archived means no security patches. Even for form types, this matters if the bundled code touches file uploads or anything that reads user input into paths. Review those types line by line rather than trusting them.

Recommendation for the record: for a new project, skip the dependency and vendor the one or two types you actually need. The package's only durable value is as a reference implementation of Symfony 2.3-era form patterns — read it as documentation, not as a library.