busayo/laravel-yearly
A lightweight Laravel package for working with yearly cycles and annual date logic. It offers helpers for year-based queries, annual date ranges, and recurring yearly events, making calendar-year data easier to handle in your models and application.
busayo/laravel-yearly is a novelty micro-package whose stated purpose is to keep a copyright year current in a Laravel application. Functionally it is a thin wrapper around PHP's date functions, most likely exposed as a Blade directive and/or helper and registered through a Laravel 5 service provider. The entire value proposition is roughly equivalent to writing {{ date('Y') }} in a template, or rendering a range such as 2015–{{ date('Y') }}.
Architecture fit. The package's footprint is minimal and non-invasive: one service provider, likely one Blade directive, no database, no queues, no config surface of consequence, no external services. Architecturally it will not conflict with anything, which is precisely why it is easy to dismiss — it contributes almost no architectural value while still occupying a slot in the dependency graph. For a TPM, the relevant framing is not "does it fit" (it does, trivially) but "does it justify a third-party dependency for a two-line concern."
Integration feasibility. Mechanically high, practically low. The last release is 2015-10-24, targeting Laravel 5.x and the PHP 5.x era. Composer constraints will almost certainly conflict with illuminate/support on Laravel 6 and later, and installation on a current Laravel application will fail dependency resolution before any code is evaluated. Even where it installs, there is no evidence of a test suite, CI, or versioned compatibility matrix.
Technical risk. Low blast radius, high hygiene risk. There is no meaningful runtime or security surface — the package cannot exfiltrate data or touch persistence — but an unmaintained dependency is still a supply-chain and audit finding. Abandoned packages accumulate PHP deprecation warnings, fail static analysis gates, and create noise in composer outdated and vulnerability scanning. The realistic failure is not an incident; it is a recurring "why is this here" conversation during upgrades and audits.
Key questions.
Assessment. Treat this as a pattern reference, not a dependency. The correct engineering decision is to implement the equivalent behavior directly — a Blade directive or view composer that renders date('Y'), optionally with a configured founding year for a range — and to own those ten lines. The package is a legitimate conversation piece and a reminder that copyright notices go stale; it is not a component to standardize on.
Stack fit. Effectively Laravel 5.x only. Any application on Laravel 6 through 11, or on PHP 8.x, should assume incompatibility until proven otherwise. If the estate still contains a legacy Laravel 5 application, that is the only context in which a direct install is even coherent — and even there, the package adds more manifest surface than it removes work.
Migration path. Do not migrate toward the package; migrate away from the need for it.
current_year and, if desired, a copyright_years value derived from a configured founding year.{{ date('Y') }} scatter-shot usage with the single directive so the format is defined once.composer.json, delete the service provider entry, and confirm the rendered output is byte-identical before closing the change.Compatibility. Composer will be the first gate: expect illuminate/support constraint conflicts on any modern framework version. PHP 8 compatibility is untested but the underlying code is simple enough that the risk is deprecation warnings rather than fatal errors. Blade directive registration APIs have been stable, so a fork would likely work, but forking an abandoned novelty package is a worse outcome than reimplementing it.
Sequencing. This is a same-day, low-ceremony change and should be sequenced as hygiene work inside a routine dependency-cleanup or upgrade cycle, not as a standalone initiative. Order of operations: inventory usages, implement the internal directive, cut over, remove the dependency, verify rendered output in all locales and timezones, then let the next audit confirm the manifest is clean. If someone insists on retaining the package for legacy reasons, pin the exact version, vendor it, and document the exception with an owner and a removal date — but the cheaper and more defensible path is replacement.
Maintenance. Zero upstream maintenance; all maintenance becomes ours the moment we install it. That is an unfavorable trade for a feature this small. The internal replacement is stable by construction — date('Y') does not have a roadmap.
Support. No vendor, no support channel, no security policy, effectively a single-author project with no recent activity. Any defect becomes an internal ticket against code we did not write and cannot easily escalate.
Scaling. Not a consideration. Runtime cost is negligible at any request volume. The package does not touch I/O, caching, or persistence, so it will not be a bottleneck under load.
Failure modes.
composer update on modern Laravel — the most likely and most visible failure.Ramp-up. Minutes for any Laravel developer. There is essentially nothing to learn, which is also the argument against adopting it: a dependency should earn its place by encapsulating something non-obvious. This one encapsulates a single built-in function.
TPM recommendation. Decline adoption. Replace with an internal directive, remove the dependency from any legacy application where it exists, and document the decision so the same question does not resurface at the next audit. The underlying observation — that copyright notices go stale — is valid and worth solving; the package is not the vehicle for solving it.
How can I help you explore Laravel packages today?