- What does busayo/laravel-yearly actually do?
- It is a novelty Laravel 5 micro-package whose stated purpose is keeping your copyright year current in templates. Functionally it is a thin wrapper around PHP's date functions, most likely exposed as a Blade directive and/or helper registered through a service provider. The entire value is roughly equivalent to writing {{ date('Y') }} or a range like 2015–{{ date('Y') }}. Despite the blurb mentioning year-based queries and annual date ranges, the documented purpose is the copyright year, so verify the source before assuming any model or query helpers exist.
- Does busayo/laravel-yearly support Laravel 6, 7, 8, 9, 10 or 11?
- No. The last release was 2015-10-24 and targets Laravel 5.x and the PHP 5.x era. Composer constraints will almost certainly conflict with illuminate/support on Laravel 6 and later, so installation fails dependency resolution before any code runs. Treat Laravel 5.x as the only context where a direct install is even coherent, and even there it adds more manifest surface than it removes work.
- How do I install busayo/laravel-yearly?
- On a legacy Laravel 5 application you would run composer require busayo/laravel-yearly and register the package service provider in config/app.php. On any modern Laravel or PHP 8.x application the install will fail dependency resolution, so do not attempt to force it with constraint overrides. The better move is to skip installation entirely and implement the equivalent behaviour in your own application code.
- Is busayo/laravel-yearly still maintained?
- No release has been published in roughly a decade, and there is no evidence of ongoing maintenance, issue triage, or a supported branch. An unmaintained dependency is a supply-chain and audit finding: it accumulates PHP deprecation warnings, fails static analysis gates, and creates noise in composer outdated and vulnerability scanning. The realistic failure mode is not an incident but a recurring why-is-this-here conversation during upgrades and security reviews.
- Does busayo/laravel-yearly have tests, CI, or a versioned compatibility matrix?
- There is no evidence of a test suite, continuous integration, or a versioned compatibility matrix in the repository. That means upgrade safety is unknown and there is no signal to tell you which Laravel or PHP versions were ever verified. For a two-line concern, that missing safety net is harder to justify than writing and testing the behaviour yourself. Any replacement you write can carry a trivial unit test asserting the rendered year and range format.
- What is the best alternative to busayo/laravel-yearly in a modern Laravel app?
- Define the behaviour once in your own application: a Blade directive or view composer that renders date('Y'), optionally combined with a configured founding year to produce a range such as 2015–2026. That is around ten lines you own, with no dependency graph entry, no abandoned-package audit finding, and no Composer conflicts. If several internal applications need it, publish it as a small shared internal package rather than pulling in a third-party novelty.
- How do I remove busayo/laravel-yearly from a legacy Laravel application?
- Remove it from composer.json with composer remove busayo/laravel-yearly and delete the service provider entry from config/app.php. Replace any existing usages with {{ date('Y') }} or your own directive, then confirm the rendered output is byte-identical before closing the change. Also grep for cached views so stale compiled Blade templates do not mask the removal. Migrate away from the need for the package rather than toward it.
- How does busayo/laravel-yearly handle timezones at the New Year boundary?
- This is not documented, and it inherits whatever PHP's date('Y') returns under your application or server timezone. If your business timezone differs from the server timezone, the copyright year can roll over early or late around midnight on 31 December. Test the boundary explicitly, or pin the call to an explicit timezone such as your configured business timezone. A package that only wraps date() gives you no additional protection here.
- Is it safe to use busayo/laravel-yearly in production?
- Its blast radius is low: one service provider, one likely Blade directive, no database, no queues, and no external services, so it cannot exfiltrate data or touch persistence. The risk is hygiene rather than runtime, but a knowingly humorous, decade-old package in a production dependency manifest is difficult to defend to security and compliance reviewers. Treat it as a pattern reference and implement the equivalent behaviour in-house instead.
- How do I write my own Blade directive to keep the copyright year current?
- In your AppServiceProvider boot method, register a directive such as Blade::directive('copyright', fn () => "<?php echo date('Y'); ?>"); and use @copyright in your footer. For a range, read a founding year from config and render it only when it differs from the current year, so the output is dynamic and the format is defined in one place. Add a small test asserting the rendered string for both the single-year and range cases. That gives you the package's entire value with none of its dependency cost.