Privacy Cookie Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. borrow for consent UX. The package is a banner-only implementation: a CSS file, a JS file, and a Twig-driven Symfony bundle that renders a privacy notice. That scope is small enough that "build" is genuinely viable, so the real decision this artifact informs is whether consent deserves a dedicated owner on the roadmap at all.
• Compliance scoping. It surfaces the minimum viable compliance story (inform, link to policy, remember dismissal) and — by what it omits — the gap list: no granular consent categories, no per-vendor controls, no consent log or audit trail, no revocation flow, no server-side enforcement of blocked scripts.
• Roadmap prioritization for legacy Symfony estates. For any portfolio still running Symfony 2.6–3.x, this is a candidate stopgap to close a visible GDPR/ePrivacy gap in days rather than a sprint. For Laravel or Symfony 4+ properties, it is not a candidate at all and should not consume roadmap capacity.
• Technology-fit gate. The package targets Symfony, not Laravel. There is no service provider, no Laravel view/asset integration, and no maintained compatibility. Recording this prevents an engineer from burning a spike on a dead end and redirects the effort to a maintained consent SDK.
• Reference design, not a dependency. The README's asset-injection pattern (publish CSS/JS into web/bundles/..., optionally wire through Assetic) is a reasonable shape to copy. A PM can use it to brief a 1–2 day internal build without taking the maintenance liability.
• Risk register input. Archived status, last release 2019-05-13, two stars, zero dependents, and a NOASSERTION license together form a concrete "do not adopt" entry — useful when a stakeholder asks why the team isn't just pulling in a package that "already does this."

When to Consider This Package

Consider it only when all of the following hold:

• The application is Symfony 2.6 through 3.x. Outside that range the bundle's kernel registration and Assetic instructions no longer apply.
• The compliance requirement is notice-and-link only — a banner, a policy link, and a stored dismissal. No consent categories, no opt-in gating of analytics or marketing tags.
• The team accepts an unmaintained, archived dependency with no security patching and no vendor support, and can vendor/fork the ~2 asset files rather than depend on Packagist resolution.
• The change must ship in days, and a compliance-driven deadline outweighs long-term code hygiene.
• Legal counsel has signed off on the banner copy and behavior, since the package ships no configurable text beyond basic bundle config.

Look elsewhere — and plan to — in every other case:

• Laravel or any non-Symfony stack. No integration path exists; this is the most common disqualifier.
• Symfony 4+/5+/6+. The bundle predates the Symfony Flex/recipes era and the kernel-bundle wiring shown is obsolete.
• Any requirement for granular consent, consent receipts, audit logs, data-subject requests, or IAB TCF. This package does none of it, and retrofitting those onto a static banner is more work than starting from a maintained CMP.
• Multi-language or brand-variant banners, or banners driven by a CMS.
• Anything customer-facing at scale, where an unpatched third-party asset is an unacceptable supply-chain surface.
• A NOASSERTION license you cannot clear. Treat as legally unresolved until counsel confirms terms; do not ship to production on an unclear license.

How to Pitch It (Stakeholders)

To executives: This is a five-year-old, archived Symfony plugin that displays a cookie banner. It is not a consent management platform and it is not usable in our Laravel or modern Symfony applications. Its value to us is as a reference pattern and a scoping tool, not a purchase: it shows that a basic notice-and-link banner is a small, well-understood build, and it makes concrete the list of things we do need — consent categories, a record of what each user agreed to, and the ability to block tags until they agree. Recommendation: do not adopt the dependency; fund a small internal build or a maintained CMP, and treat the archived package as a design reference only. Estimated saving versus a commercial CMP is real but bounded, and the compliance and maintenance risk of the archived code outweighs it.

To engineering: Scope is two static assets plus a template hook — low complexity, low integration surface. Constraints are hard: Symfony 2.6–3.x only, archived since 2019, effectively unmaintained (2 stars, 0 dependents), and an unclear license. If you want the pattern, fork the CSS/JS and render the banner from our own view layer; do not add it to composer.json. If compliance needs are broader than a dismissal cookie, this is the wrong starting point and we should evaluate a maintained consent SDK instead.