Reform Bundle Laravel Package

Getting Started

• Install and pin. composer require ruwork/reform-bundle, then immediately pin the resolved version and commit composer.lock. The latest tagged release is now 0.2.0 (previously 0.1.x from 2018-07-09); the package is still archived, so treat it as vendored code, not a live dependency. Note that on a 0.x line Composer treats minor bumps as potentially breaking — ^0.1 will not resolve 0.2.0, and ^0.2 permits future 0.2.x surprises. Pin exactly (0.2.0), not a range.
• Where to look first. In this order: README.md (usually the only docs), DependencyInjection/Configuration.php (the real API of the bundle — the config tree is the only authoritative description of options), DependencyInjection/ReformExtension.php (what services get registered), then Form/ and Resources/views/Form/ (the day-to-day surface). As of 0.2.0 there is a new file to read closely: Resources/views/Form/reform_bootstrap_4_layout.html.twig — the entire delta of this release.
• Register the bundle. If there is no extra.symfony block in its composer.json, Flex will not auto-register it. Add Ruwork\ReformBundle\ReformBundle::class => ['all' => true] to config/bundles.php (or new Ruwork\ReformBundle\ReformBundle() in a legacy AppKernel).
• Confirm what it actually provides. Run bin/console debug:container | grep -i reform, bin/console debug:form, and bin/console debug:config reform. This tells you in seconds whether the contribution is form types, type extensions, Twig themes, or services — often faster than reading 2018-era source.
• First use case (updated). Two shapes now. (1) Form type extensions applied automatically to existing form types — verify with debug:form App\Form\FooType. (2) The Bootstrap 4 form theme. Add reform_bootstrap_4_layout.html.twig to twig.form_themes, or apply it per-form with {% form_theme form 'reform_bootstrap_4_layout.html.twig' %}, then render a form and diff the markup against plain bootstrap_4_layout.html.twig to see what the bundle actually changes. That diff is the fastest way to understand the release.

Implementation Patterns

• Let the tag do the work. Symfony auto-wires form type extensions via the form.type_extension tag. Confirm the tag is declared in Resources/config/services.xml or via autoconfigure; if you need to override the extension, decorate the service rather than editing vendor code.
• Adopt the Bootstrap 4 theme deliberately, scoped first. Do not drop reform_bootstrap_4_layout.html.twig into global twig.form_themes on day one. Register it on a single form ({% form_theme form ... %}) or a single template, compare output, then promote it globally once you know it does not fight your existing theme stack.
• Know the theme's parent. The name strongly implies it layers on Symfony's own bootstrap_4_layout.html.twig (Twig Bridge / symfony/form), e.g. via {% use %}. Check the file header for {% use ... %} and {% block ... %} overrides: whether it extends or replaces Bootstrap 4 rendering determines whether you must also register bootstrap_4_layout.html.twig and keep symfony/twig-bridge at a compatible version. The 2018-era parent theme has changed shape since; block names may no longer exist.
• Publish and adjust configuration. Copy the bundle's default config into config/packages/reform.yaml (or app/config/config.yml for pre-Flex apps) using the node names from Configuration.php. Only override keys you can see in the tree — there are no docs to fall back on.
• Override templates at app level. Copy reform_bootstrap_4_layout.html.twig to templates/bundles/ReformBundle/Form/reform_bootstrap_4_layout.html.twig and edit there — the least invasive way to tweak rendering without forking. Note the path includes the Form/ segment, matching Resources/views/Form/.
• Fortify abandoned code. Either (a) fork via composer.json repositories: [{type: vcs, url: …}], or (b) copy the bundle into src/ReformBundle, drop the vendor requirement, and register it locally. Option (b) is usually cheaper for a 0-star, 0-dependent package — and with 0.2.0 adding exactly one Twig file, copying just that template into templates/ and skipping the bundle entirely is a serious option.
• Isolate behind your own boundary. Wrap the bundle's form types/extensions in your own App\Form\… types or a decorator, and keep a thin templates/form/reform_theme.html.twig that does {% use 'reform_bootstrap_4_layout.html.twig' %} so swapping the source later is a one-line change.
• Smoke-test the integration. Add a kernel-boot test plus a form-build test ($this->createForm(...)->createView()) — for unmaintained bundles, this catches signature breaks on Symfony upgrades. Add a rendered-HTML assertion on the form view now that a theme ships, otherwise a silently-missing/renamed block goes unnoticed.
• Decorator pattern for behavior changes. Use #[AsDecorator] or a compiler pass to intercept the bundle's services instead of editing them; this survives re-installs and keeps the diff to vendor code at zero.

Gotchas and Tips

• 0.2.0 is a 0.x minor bump. Semver-wise this may contain breaking changes, and Composer will not upgrade you across it from ^0.1. Read the release as "one new template, unknown compatibility": diff the bundle tree between 0.1.x and 0.2.0 (composer diff, or install both in a scratch app) to confirm the theme is the only change and nothing in Form/ or DependencyInjection/ moved.
• Archived and unmaintained. No security advisories, no patches, no Symfony 5/6/7 compatibility work. Run composer audit and pin the exact version. The 0.2.0 tag should not be read as a sign of renewed maintenance.
• Bootstrap 4 is itself EOL-adjacent. If your app is on Bootstrap 5, this theme's markup (custom-control/input-group/form-row classes) will be wrong. Either override the theme's blocks wholesale or skip it — Bootstrap 5 form theming is better served by Symfony's built-in bootstrap_5_layout.html.twig.
• Theme ordering matters. Entries in twig.form_themes are searched in order; a bundle theme registered via Flex/config can be shadowed by another bundle's (EasyAdmin, etc.). Verify with bin/console debug:twig --filter=reform and by checking twig.form_themes in debug:config twig, not by assuming the file is reachable because it is installed.
• Symfony version drift. 2018-era code typically targets Symfony 3.4/4.x. Expect breakage on Symfony 5+ around FormTypeInterface signatures, ChoiceLoaderInterface, ContainerAware* base classes, TreeBuilder/Configuration APIs, and — now relevant — Twig form theme block names and {% use %} semantics. Use composer why-not symfony/framework-bundle to see what is actually blocking an upgrade.
• PHP 8 fallout. Old code may rely on dynamic properties, each(), or missing return types. Enable E_ALL, check for #[\ReturnTypeWillChange] needs, and lint the bundle's PHP with the same version as your app before trusting it.
• Silent no-ops from private services. If the bundle's services are private and untagged, behavior appears "missing" with no error. Use debug:container --tag=form.type_extension and lint:container to confirm registration, and check _defaults: { public: false } in the bundle's service config. Templates fail quietly in the same way — a typo'd theme name is a Twig\Error\LoaderError at render time, not at boot.
• Configuration is the only documentation. Node names, required flags, and defaults live solely in Configuration.php. After changing YAML, verify with bin/console debug:config reform rather than assuming the key was accepted; unknown keys are rejected only if the tree is strict. The new template adds no config surface — if a release note is a file, there is nothing to configure.
• Extension points to prefer. In order of safety: Twig form theme overrides → form type extensions → service decorators → compiler passes → direct vendor edits. Never edit the vendor directory; it will be lost on the next composer update.
• Migration posture. Given zero dependents and zero stars, budget for replacement. Treat this bundle as a temporary adapter: native Symfony form types, Symfony's own Bootstrap 4/5 layout, symfony/ux components, or a small internal helper usually cover the same ground with maintenance guarantees. The 0.2.0 template is a candidate to copy into your own templates/ and disown.