Birthday Bundle Laravel Package

Technical Evaluation

Verdict up front: this is not a Laravel package. happyr/birthday-bundle is a Symfony bundle (type: symfony-bundle) with Twig extensions, DI service definitions, and Doctrine ORM repositories. Laravel has no bundle kernel, no Twig, no Doctrine bundle, and no extra.laravel.providers discovery. The stack-fit score is effectively zero, so any TPM decision framed as "adopt or not" collapses into "port or not."

Architecture fit. The domain is framework-neutral in concept and roughly 200–400 LOC across three concerns: a contract for entities exposing a birthday date, a manager that answers "whose birthday is today / within N days," and a view helper that renders a widget. The packaging is Symfony 2/3-era and does not transfer. What a TPM should extract is the scoping pattern, not the artifact: birthday field on the user model, a date-window query, a presentation partial.

Technical risk — high. Last release 2017-11-14 puts it in the PHP 7.0/7.1 and Symfony 2.8/3.x window, with Doctrine ~2.5. It will not resolve cleanly on PHP 8.2+ or Laravel 10/11 without forking composer.json and --ignore-platform-reqs. Add 0 stars, 0 dependents, and no issue corpus, and you have a supply-chain liability with a bus factor of zero. Nothing in the package answers the questions that actually matter for this feature: timezone of the "today" boundary, Feb 29 policy, consent over birth-year visibility, i18n of date formats, or notification channel.

Leverage for a TPM. Realistically this package supports three product decisions and nothing else:

• Build-vs-buy shortcut check. Use it as a calibration point for what a minimal birthday widget costs — a senior engineer reproduces the equivalent in well under a day, with tests and our own conventions. That is the honest denominator.
• Feature scoping. Treat the repo as a reference spec for the surface area (date field, window query, view partial) and the edge cases the package omits — those edge cases are the actual estimate.
• Risk-register input. Log "no release in ~8 years, zero downstream consumers" as a precedent for dependency gating.

Key questions for the requestor:

• Do we need passive display only, or timezone-aware windows, upcoming-N-days, and scheduled notifications? The latter puts this entirely outside the package's scope.
• Is birthday stored as a full date (PII) or a month/day pair? What is the retention and access policy?
• Does the UI need age or birth year (privacy escalation), or display name only?
• Is a maintained-dependency / security-scan gate in force? If so, the evaluation ends here.

Integration Approach

Stack fit. No shared abstractions beyond PSR interfaces. Twig becomes Blade; Doctrine annotations become Eloquent casts; bundle DI YAML becomes a service provider plus config/birthday.php.

Migration path — port, do not depend. Vendor the repository as a read-only reference and build a first-party acme/birthday package behind an interface so it can be swapped if the spike fails.

Compatibility. Target PHP ^8.1, Laravel ^10|^11, zero Symfony dependencies, no doctrine/dbal. Use Carbon for date math and timezone conversion. Avoid MONTH(birthday)=? AND DAY(birthday)=? predicates — they defeat indexes; persist a birthday_month_day generated column indexed alongside a tenant key.

Sequencing for the TPM to schedule:

1. Requirements and privacy sign-off: name-only vs. age, timezone semantics, Feb 29 policy. This is a decision gate, not an engineering task — assign an owner.
2. One-day timeboxed spike port behind an interface.
3. Shadow-run output against any existing manual query for a week before wiring the UI.
4. Ship the Blade component behind a per-user, per-local-day fragment cache.
5. Add index and query-count assertions in CI.
6. Delete the vendored reference; the code is now ours.

If reuse is mandated. Forking to bump constraints and abstract out Doctrine is more work than the rewrite and leaves us owning a fork of a dead project. Document that trade-off explicitly for the approver rather than absorbing it silently in the sprint.

Operational Impact

Maintenance. Upstream is dormant, so every future PHP or Laravel upgrade becomes our problem. A first-party port is a few hundred lines with a named owner and tests — a few hours per quarter. A fork is a permanently owned artifact written in unfamiliar idioms; materially worse.

Support. No vendor, no issue triage, no security advisories, no Stack Overflow corpus. Onboarding is read-the-source. Because birthdays are personal data, our security team owns the surface regardless of provenance — the package choice removes none of that obligation.

Scaling. The widget is cheap; a naive query is not. At six-figure user counts, month/day extraction predicates force a scan per request. Mitigate with the generated indexed column plus a per-user, per-day fragment cache keyed to local midnight. Watch N+1 if the manager returns full entities and the partial touches relations — select only id and display name.

Failure modes to design against:

• Timezone drift — server UTC vs. user locale produces wrong-day birthdays; anchor comparisons to the viewer's timezone.
• Leap year — Feb 29 must have a declared policy (Feb 28 vs. Mar 1); decide once, test it, document it.
• Cache staleness — a TTL that spills past midnight serves yesterday's list; expire on the local-date boundary.
• Privacy leakage — never render birth years or expose another user's DOB beyond display name.

Ramp-up. Low for the port (small, well-understood domain); moderate for the privacy/compliance review. A mid-level Laravel developer ships it in 1–3 days; add half a day for tests and a day for sign-off.

Recommendation: do not adopt as a dependency. Use it strictly as a design reference and port the concept in-house. Zero stars, zero dependents, and a 2017 release with no PHP 8 support is a decisive signal — the cost of owning a dead Symfony bundle exceeds the cost of writing the ~300 lines ourselves.