Cookies Bundle Laravel Package

Product Decisions This Supports

• Informs the cookie/consent layer design, not a purchase. The bundle's core idea — cookies as injectable Symfony services instead of $_COOKIE reads scattered through controllers — remains a legitimate architectural decision for any product with personalization, locale/currency preference, A/B bucketing, referral attribution, cart persistence, or consent state. Adopt the pattern; the package is not the decision. The 1.0.0 tag adds nothing to this: no consent gate, no SameSite/Secure/HttpOnly policy surface, no cookie inventory.
• Build-vs-buy input for a preference/settings store. Surface area is still small (a typed cookie model plus a DI registration). The build-vs-buy answer stays firmly "build" — the integration cost with any modern Symfony or Laravel version exceeds the cost of writing the wrapper.
• Version-pinning / upgrade decision. The 0.x → 1.0.0 jump is a semver declaration, not a feature release. The notes assert that 0.1 and master already worked and that 1.0.0 is a stability stamp — there is no changelog, no breaking-change list, and no compatibility statement for modern Symfony or PHP. For anyone already on 0.x or master, treat 1.0.0 as a label change and diff before bumping; for anyone new, it does not reduce integration work by a single day.
• A cleaner vendoring/fork point (genuine, small upside). If a legacy Symfony team has already decided to adopt the pattern via this artifact, a tagged 1.0.0 is a more defensible pin than a floating dev-master. That is a fork-management convenience, not a reason to adopt.
• Feature scoping for consent and privacy work. Unchanged: this package provides no controls for GDPR/CCPA, cookie-banner gating, or data-retention policy. It does not support those roadmap items and a 1.0.0 tag does not change that.
• Risk register entry — evidence corrected, conclusion unchanged. The prior assessment said "single release, last release June 2016." That is no longer accurate and should be restated as: stable 1.0.0 tag exists; no changelog discipline; no stated security or maintenance process; no evidence of ongoing compatibility work. The dependency risk is the same, but the recorded rationale must reflect current facts so the entry stays credible when re-challenged.
• Clarifies stack fit. This is a Symfony bundle, not a Laravel package. For a Laravel roadmap it supports no decision beyond "use Illuminate\Cookie\CookieJar / the Cookie facade."

When to Consider This Package

Consider it only if all of the following hold:

• You are maintaining a legacy Symfony 2.x/3.x application.
• You already standardize on ONGR bundles and value consistency over currency.
• You need a trivial typed cookie wrapper and accept that you will own and patch the fork; a 1.0.0 tag is a stability statement from the author, not a support commitment.
• You are pinning to a tag rather than a branch, and you have reviewed the actual diff between 0.x/master and 1.0.0 — the release notes claim 0.1 "works very nicely," which is an assertion rather than a changelog.
• MIT licensing is acceptable (it is — no copyleft exposure).

Look elsewhere if any of these are true:

• Laravel, Lumen, or any non-Symfony framework. Wrong ecosystem; the bundle registers Symfony DI services and will not function.
• Symfony 4/5/6/7 or PHP ≥ 7.2. The 1.0.0 release notes announce a version number, not compatibility work; pre-2016 code predates SameSite, modern autowiring, and typed properties. Assume the same porting effort as before.
• Any product with a consent or privacy obligation. You cannot rely on 2016-era defaults for Secure, HttpOnly, or SameSite, and no security-release process has been described.
• Any team without spare capacity to vendor a dependency with a single maintainer and no changelog. A 1.0.0 tag does not create community pressure to fix what you find.

Preferred substitutes: Symfony HttpFoundation request cookies plus the Cookie value object wrapped in your own ~50–100 line service (one day of work, fully testable); or Laravel's Cookie facade behind a thin repository class.

How to Pitch It (Stakeholders)

To executives: Still a no-go, and the new 1.0.0 tag does not change it. The release notes announce a major version number and nothing else — no changelog, no feature list, no compatibility or security statement. This remains a small Symfony-only cookie wrapper with a single maintainer, solving a problem our engineers can implement in about a day with full control and no long-term ownership liability. A "1.0.0" label is a promise about API stability, not about maintenance or security patching; treating it as rehabilitation would be reading more into the tag than the author wrote. Licensing is fine (MIT), so the only real cost is risk — and a stable tag does make the fork-and-pin fallback tidier if a legacy team has already committed. Recommendation is unchanged: do not adopt as a dependency.

To engineering: The pattern is right, the artifact is still dead — it just now has a version number. Cookies-as-injectable-services gives us testability and one place to enforce consent, SameSite, and encryption; copy that design into our own small cookie repository: on Symfony, wrap HttpFoundation cookies and register one service; on Laravel, wrap the Cookie facade. Two concrete actions from this release: (1) if anyone has 0.x or dev-master vendored anywhere, pin to 1.0.0 after diffing, since the "everything works nicely" claim is not a changelog; (2) update the risk-register entry, which currently cites "no release since 2016" and is now factually stale — replace that line with "single maintainer, no changelog, no stated security process," which is the real objection. Also re-flag the brief's framing: this is a Symfony bundle, so it remains irrelevant to our Laravel work. Recommendation: reject the dependency, adopt the pattern.