Cookie Laravel Package

Product Decisions This Supports

• Security hardening of the cookie layer as a shippable increment. delight-im/cookie wraps PHP's native cookie primitives behind a small, readable API and, critically, exposes SameSite attributes on PHP versions where the language runtime did not yet support them. That makes it a low-effort lever for reducing CSRF and cross-site request exposure without a broader auth rewrite.
• Build vs. buy (buy, in this case, is "adopt"). The build alternative is a 100–200 line internal cookie helper that every team writes slightly differently and nobody tests for attribute correctness. Adopting an MIT-licensed, single-class dependency collapses that into a code-review-sized decision rather than a sprint.
• Roadmap input for compliance and consent work. Cookie attribute control (Secure, HttpOnly, SameSite, Path, Domain, expiry) is a prerequisite for GDPR/ePrivacy consent flows and for browser third-party-cookie deprecation readiness. If consent or tracking-adjacent features are on the roadmap, this is a concrete, cheap enabler.
• Use cases it unblocks or simplifies: session identifier handling in non-framework or legacy PHP entry points, preference and locale persistence, feature-flag and experiment bucket assignment at the edge, "remember me" tokens (paired with your own signing/encryption), and consent-state storage.
• De-scoping signal. Because the library is deliberately narrow, it is not a session manager, not an encryption layer, and not a consent platform. Choosing it implicitly commits the team to owning those adjacent concerns — a useful forcing function to write down who owns token signing and consent records.

When to Consider This Package

Adopt when:

• You are on plain PHP or a micro-framework without a first-class cookie abstraction, and cookie handling is currently scattered across setcookie() calls with inconsistent flags.
• You need SameSite support on an older PHP runtime (pre-7.3) and cannot upgrade the runtime on the roadmap timeline.
• You want a small, auditable, zero-dependency surface — one class, MIT license, no autoloading gymnastics, easy to vendor or fork if the upstream goes quiet.
• Your cookie needs are primitive-level: set, read, exists, delete, with explicit attribute control. You are not asking the library to manage sessions, encryption, or signing.
• You are doing a targeted security cleanup and want a defensible, reviewable diff rather than a homegrown helper.

Look elsewhere when:

• You are on Laravel or Symfony. Laravel's Cookie facade plus EncryptCookies middleware and Symfony's HttpFoundation cookie objects already cover this ground, are maintained with the framework, and integrate with the response pipeline. Adding a parallel cookie library here creates two sources of truth for cookie policy — a real bug class.
• You need signed or encrypted cookies. This package is a transport wrapper, not a crypto layer; pairing it with hand-rolled HMAC is where teams get hurt.
• You need PSR-7 / PSR-15 interoperability, middleware integration, or cookie jars for HTTP clients — use a PSR-7 implementation's cookie support instead.
• You need consent management, cookie categorization, or script gating — that is a product/legal platform concern, not a utility library.
• Maintenance risk is unacceptable for your context. Low star count and zero dependent packages mean limited community scrutiny and no downstream canary. For a security-adjacent primitive in a high-value surface, either vendor and pin it with your own tests, or write the 150 lines yourself so the review burden stays internal.

How to Pitch It (Stakeholders)

To executives: This is a small, free, permissively licensed PHP utility that lets us set browser cookies correctly and securely — including modern cross-site protections — with roughly a day of integration work rather than a sprint of custom code. It directly supports our security posture and any consent/privacy work already on the roadmap, at effectively zero licensing cost. The trade-off is maintenance risk: it is a small open-source project, so we would pin the version, vendor it into our codebase, and cover it with our own tests. If we are already on Laravel or Symfony, we should use the framework's built-in cookie handling instead and skip this entirely.

To engineering: Single-class, zero-dependency, MIT. Gives us consistent cookie attribute handling (Secure, HttpOnly, SameSite, Path, Domain, expiry) and backfills SameSite on older PHP runtimes. It is explicitly not a session manager, signer, or encryptor — we own token signing and consent state. Recommendation: adopt only in non-framework PHP entry points, vendor and pin it, and add a thin internal wrapper so we can swap the implementation later without touching call sites.