Laravel Nova News Laravel Package

Getting Started

This release (1.1.0) is a maintenance release only — no new features, no API changes, no deprecations. The only change that affects you as a consumer is a raised platform requirement:

• PHP: ^8.1 → ^8.2

Everything else in the changelog (Orchestra Testbench 8.x, PHPUnit 10, Pest 2, pest-plugin-faker 2, Pint 1.13) is a dev dependency and only matters if you contribute to the package itself or run its test suite in CI.

Minimal steps to get productive:

1. Confirm your runtime floor before upgrading: php -v must report 8.2+. On 8.1 you simply cannot install 1.1.0 — Composer will refuse. If you're still on 8.1, pin "made-foryou/laravel-nova-news": "1.0.5" and plan the PHP bump separately.
2. Install/upgrade: composer require made-foryou/laravel-nova-news:^1.1.
3. Publish and migrate (if you haven't already): php artisan vendor:publish for the package's config/migration tags, then php artisan migrate.
4. Where to look first: the package's service provider in src/ (it is what registers the Nova resources/cards into your sidebar), the published config/ file for any tunables, and database/migrations for the news/content schema.
5. First use case: install → publish → migrate → open Nova → create a news item from the sidebar → confirm it renders where your frontend reads it. That end-to-end loop is the fastest way to validate the install.

Implementation Patterns

Upgrade path. 1.1.0 is a safe bump if you already meet PHP 8.2. Treat it as: bump PHP in CI first, run your test suite, then bump the package. Doing both in one PR makes failures hard to attribute.

Day-to-day usage. The package is a Nova-side concern — you'll mostly interact with it through Nova resources rather than application code. Typical workflow:

• Content editors create/edit news items through the Nova UI; you rarely write code against the models.
• If you need the records on the frontend, resolve the package's model(s) (check src/Models) or add your own read layer over the underlying table rather than depending on package internals.
• Keep customisations in published config and Nova resource overrides (Nova::resources([...]) / extending the resource class) so upgrades stay cheap.

CI alignment. Since the package now runs Pest 2 / PHPUnit 10 in its own pipeline, mirror that in your repo if you vendor or fork it — PHPUnit 9-era config (phpunit.xml schema, @covers annotations vs attributes) will not carry over cleanly.

Hosting on Laravel Vapor / containerised setups. The PHP 8.2 floor means your build image's base tag matters more than your local machine. Bump the Dockerfile/runtime version alongside the Composer constraint, otherwise deploys fail at composer install and not locally.

Gotchas and Tips

• This is a minor version with a breaking platform constraint. Semver-wise ^8.1 → ^8.2 is a BC break for anyone on 8.1, but it shipped as 1.1.0. Read the constraint, don't assume the version number. If you have downstream packages pinned to PHP 8.1, composer update will surface a conflict wall — solve it at the PHP level, not by downgrading randomly.
• Composer can silently keep you on 1.0.x. If composer require reports "nothing to install", check composer why-not made-foryou/laravel-nova-news 1.1.0 — it's almost always the PHP constraint or a Nova version conflict.
• Dev dependency bumps are not visible to you. Testbench 8 / Pest 2 changes will never affect your app unless you run the package's tests or copy its test scaffolding. Don't spend time on them during the upgrade.
• Run the migrations check. After upgrading, php artisan migrate:status to confirm nothing new shipped unexpectedly — dependency-only releases occasionally carry schema drift from the base branch.
• Debugging rendering issues: Nova resources failing to appear are usually a provider registration or nova.php / NovaServiceProvider ordering problem, not the package version. Check php artisan about and your Nova service provider before blaming the release.
• Extension points to prefer: published config, view overrides via vendor:publish --tag=views, and subclassing Nova resources. Avoid editing vendor/ — a patch release will erase it.
• Pin for reproducibility. If you don't need the PHP 8.2 toolchain churn, "1.0.5" is a perfectly defensible pin; if you do upgrade, commit composer.lock so the whole team lands on the same resolution.