Zodiac Bundle Laravel Package

Technical Evaluation

Architecture fit: Mismatch by construction, and that's the first thing to log. lunetics/zodiac-bundle is a Symfony2 bundle, not a Laravel package: a Bundle class, a DI extension, YAML/XML service definitions, and a Twig_Extension registering a |zodiac filter and zodiac(date) method. Laravel has no bundle system, no Twig, and no equivalent extension surface (ServiceProvider + Blade component/directive is the nearest analogue). Essentially 100% of the framework-facing code is dead weight in a Laravel app. The reusable payload is a 12-row cusp table plus ~12 range comparisons — roughly 40–80 LOC including tests.

Integration feasibility: Trivial only via reimplementation, not installation. There is no composer require path to a working feature; the realistic effort is a half-day to one day to build a first-party enum + resolver + boundary tests. That is materially cheaper than the procurement work of vetting, exception-approving, and owning an abandoned dependency.

Technical risk: High if adopted as-is, negligible if harvested.

• Symfony 2.x is long end-of-life (2.8 security support ended 2019); Twig 1.x APIs (Twig_Extension, Twig_SimpleFilter) were removed in Twig 2/3, so the extension class fatals on any modern stack. rcrowe/twigbridge does not rescue this.
• Composer constraints almost certainly pin symfony/* ^2.x and twig/twig ~1.x, which hard-conflict with Laravel 10/11 (pinning symfony/* to ^6.4/^7). Expect resolution failure before any code-level concern surfaces — composer why-not settles it in minutes.
• 7 stars / 0 dependents means no upstream pressure, no CVE response, no bus factor. Any defect becomes ours permanently.
• Correctness risk concentrates on cusp boundaries, where conventions vary by source and tradition. There is no evidence the package documents its table, handles user timezones, or localizes sign names — all of which matter more than the filtering mechanism.

Key questions:

1. Which boundary table/tradition does the product require, and who signs off on it?
2. Is localization in scope (ES/FR/DE/JA sign names)? Hardcoded English is a silent UX failure.
3. Is the requirement a sun sign (local date math) or horoscope content (third-party API, caching, licensing)? These are different projects with different vendors — and this package is irrelevant to the second.
4. What are the license terms for vendoring the mapping table if we copy it?
5. Is the sign persisted on the profile or computed on read? Persistence turns boundary definitions into a future migration hazard.
6. Do we have regional disclosure/consumer-protection obligations around pseudo-scientific claims? The package offers no help, and no dependency will.

Decision framing for stakeholders: this is a build-vs-buy call where "buy" means a permanent dependency-policy exception in exchange for zero leverage. The package's real value is as a reference spec and a boundary-case checklist — it tells us how small this feature actually is.

Integration Approach

Stack fit: Zero at the package level. Laravel's stack is Blade + Eloquent + Carbon; this bundle targets Twig 1 + Symfony2 DI. Nothing transfers except the sign table and the comparison logic.

Recommended path — harvest, don't install:

• ZodiacSign PHP enum / value object (name, slug, symbol, start/end month-day).
• ZodiacResolver interface + implementation, bound in a ServiceProvider.
• Surface via a Blade directive/component (@zodiac($date)) and, if needed, a thin facade — mirroring the package's ergonomics without the Twig baggage.
• Resolve against an explicit local date using CarbonImmutable, never a UTC timestamp.
• If a dependency audit insists on attribution, vendor the cusp table into our own class with the MIT notice and drop every line of framework glue.

Migration path: Do not composer require. There is no incremental "install, then replace" path worth taking — the install step buys a dead autoload entry and a dependency conflict. Copy the cutoff table from the Twig extension verbatim (parity with whatever spec our product references), carry the boundary assertions from Tests/ into our own PHPUnit dataset, and ignore DependencyInjection/ entirely.

Compatibility: Assume hard conflicts on symfony/* and twig/twig, plus PHP 8.x deprecations from Twig 1-era code. If anyone insists on validating that, do it on a throwaway branch, not in the main application.

Sequencing:

1. Lock the requirement and locale matrix with product; confirm it is sun-sign math, not horoscope content.
2. Implement enum + resolver; write boundary tests at ±1 day for all 12 signs, plus leap day (Feb 29) and the Dec 31 / Jan 1 wrap.
3. Add Blade/API surfacing and edge validation (reject null/malformed dates with a typed error, not a default sign).
4. Only then layer content (horoscope copy or provider API) if that is the real ask.
5. Persist the slug, never a localized display name.

Operational Impact

Maintenance: Reimplementation yields a ~60-line, fully-owned module with no upstream risk and no vendor review burden. Adoption yields a permanent exception in dependency policy and security scanning, plus an orphaned bundle nobody will ever patch — for a feature we could own outright in an afternoon.

Support: Effectively none. Seven stars, zero dependents, no maintainer signal, no release cadence. Every defect is our escalation path with no upstream to lean on. This is the single strongest argument against adoption.

Scaling: The resolver is O(1) pure computation with no I/O, so it is operationally invisible at any realistic volume. Scaling only becomes a real conversation if the feature grows into horoscope content — at which point cache by sign + local date + locale and treat the content provider, not this logic, as the bottleneck.

Failure modes:

• Wrong sign on cusp dates — highly visible trust failure in a personality/horoscope surface.
• Timezone drift flipping a sign across midnight; normalize to the user's local date before resolving.
• Leap-day and year-end wrap mishandling.
• Null or malformed dates from API payloads silently defaulting to a sign.
• Untranslated sign names in non-EN locales.
• Compliance/disclosure exposure if astrology is presented as more than decorative.

Ramp-up: Negligible either way. Any Laravel developer reimplements this with tests in under a day; attempting the bundle would likely burn comparable time on dependency conflicts alone, with nothing shippable to show for it.

Recommendation: Reject adoption; harvest the logic into a first-party, tested service and revisit only if the platform standardizes on Symfony — or if the underlying requirement turns out to be a horoscope content API, in which case this package is irrelevant either way.