Link Button Bundle Laravel Package

Product Decisions This Supports

• Build-vs-buy on trivial UI primitives. A "cancel" control that submits no data and simply navigates away is a styling concern, not a domain concern. This package is a candidate only if it removes a repeated, annoying pattern across many forms.
• Form UX consistency on roadmap items. If a roadmap theme is "reduce friction in multi-step or destructive-action flows" (edit forms, wizards, confirmation screens), a standard, consistently-styled cancel/back affordance is a small but real contributor to task abandonment rates.
• Not a Laravel decision. Despite the broader PHP framing, this is a Symfony bundle tied to the Symfony Form component and its templating/theme layer. It has no place in a Laravel roadmap. Treat it as relevant only if the codebase is Symfony and on a compatible major version.
• Use cases it nominally covers: a Cancel/Back button inside a <form> that must render as an anchor rather than a submit button; keeping cancel actions inside the form theme so styling and layout stay uniform; avoiding a controller action purely to bounce the user back.
• It should not drive a build-vs-buy decision. See below — the "buy" side of this decision is close to free to build in-house, which collapses the analysis.

When to Consider This Package

Consider it only if all of the following hold:

• The stack is Symfony, not Laravel, and on an actively supported Symfony major version.
• You have already audited the source: the bundle's footprint is small enough to read end-to-end in an afternoon, and you accept owning it.
• Your form theme is already the natural owner of button rendering, and you want cancel links to inherit the same CSS/class/token treatment as submit buttons without hand-writing Twig partials per form.
• You can fork it internally and vendor it (or copy the ~one class into your app) rather than depending on upstream releases.

Look elsewhere — or just build it — if any of these are true, which they are here:

• Signals point to abandonment. Zero stars, zero dependents, no visible maintenance surface. There is no community to catch a breakage, no upgrade path, and no security response. Adopting it means accepting unowned risk for a cosmetic gain.
• The problem is smaller than the dependency. A cancel link is a line of Twig (<a href="{{ path(...) }}" class="btn btn-secondary">Cancel</a>) or a custom form type with a block_prefix. Adding a third-party composer dependency, a bundle registration, and an upgrade obligation to save that line is a net negative.
• Framework coverage is uncertain. Confirm against your Symfony version whether form theming or a native type already gives you this; if a first-party path exists, the third-party path is strictly worse.
• Composer hygiene or SBOM constraints apply. An unmaintained package with no dependents is a recurring finding in dependency reviews and a distraction in audits.
• You need anything beyond rendering — validation suppression, CSRF exemptions, accessibility guarantees. A package this small will not have solved those for you.

Net PM recommendation: do not adopt as a dependency. Spend thirty minutes writing the equivalent internally, or contribute the pattern to your shared form theme. The decision is not "is this package good?" but "is this package better than the four lines of template it replaces?" — and at zero maintained signal, it is not.

How to Pitch It (Stakeholders)

For executives (30 seconds): An open-source snippet that renders a form's "Cancel" button as a link instead of a submit button. It is a Symfony-only component, so it is out of scope for our Laravel work. More importantly, it is a single-purpose, unmaintained project with no adoption — the risk of depending on it exceeds the value. Our recommendation is to not add it; the same behavior is a few lines of our own template code, which we already control, test, and upgrade. No cost, no vendor risk, no roadmap impact.

For engineering: This is a micro-bundle that wraps the "cancel is a link, not a submit" pattern into a Symfony form type. It is technically straightforward and the idea is sound, but the package is unmaintained (no stars, no dependents, no release cadence) and is only usable in Symfony. Proposal: replicate the pattern in our own form theme or a small in-house form type — roughly an hour of work including tests — so we get the consistent cancel/back affordance without a third-party dependency, without a bundle registration, and without an upgrade liability on every Symfony bump. If we later find we need richer behavior (per-form theme overrides, accessibility attributes, multi-step navigation), we will own that code and can extend it deliberately.