Nocks Laravel Package

Getting Started

This release (4.1.0) is a compatibility release: PHP 8 support. There are no new features, no deprecations, and no documented breaking changes, so existing 4.x integrations should continue to work after a routine upgrade.

First steps for a developer picking this up:

1. Confirm your runtime meets the new floor before touching anything:

   php -v          # must be 8.0+
   composer why-not php 8.0
   

2. Upgrade the constraint and let Composer resolve:

   composer require <vendor>/<package>:^4.1 --update-with-dependencies
   

3. Check Laravel package auto-discovery picked up the service provider:

   php artisan about          # Laravel 9+
   php artisan package:discover
   

4. Publish anything the package ships (config, migrations, assets) and diff against what you already have committed:

   php artisan vendor:publish --provider="<Vendor>\<Package>\<Package>ServiceProvider"
   

5. Run the host app's test suite plus any package-provided tests before deploying.

Where to look first: the package README's installation block and any CHANGELOG.md entry for 4.1.0. Because the only change is PHP 8 support, the highest-value first read is the composer.json require block — that tells you the real PHP and illuminate/* constraints you now have to satisfy.

First use case: wire the package into a single, low-risk code path (one controller or one queued job) and verify behaviour end-to-end on PHP 8 before rolling it across the app. Since this release changes the runtime, not the API, a smoke test on one integration point is usually sufficient evidence that the upgrade is safe.

Implementation Patterns

Because 4.1.0 is a platform-support release, day-to-day patterns are unchanged from earlier 4.x versions. The practical work is in how you sequence the upgrade and how you keep package boundaries clean.

Upgrade in a branch, not on main. Bump the constraint, run composer update <vendor>/<package> --with-dependencies, commit the lockfile diff, and review it. A PHP 8 support release frequently pulls transitive dependency bumps (Symfony components, illuminate/*) that are the real source of behaviour changes.

Resolve the container, don't instantiate. Continue binding through the service container or a facade so that config and driver swaps stay in one place:

// Prefer injection over app() in application code
public function __construct(private PackageContract $package) {}

If the package exposes a facade, use Facade::shouldReceive(...) in tests rather than hitting the real implementation.

Keep configuration in config/. Publish the config file once, commit it, and read values via config('package.key'). Avoid calling env() outside the config file — that breaks under php artisan config:cache, which matters more now that you may be deploying onto newer PHP 8 runtimes with opcache preloading.

Isolate the integration behind your own adapter. Wrap package calls in a thin application-level service. When the next major version lands, you change one class instead of grepping the codebase. This is cheap insurance and the single most useful pattern for any third-party Laravel package.

Exercise it in a queued context. If the package does any I/O, run it through a real queue worker on PHP 8 (php artisan queue:work --once) rather than only in HTTP requests — PHP 8 changes around error handling and type coercion surface more readily in long-running processes.

Pin in CI. Add a matrix entry so the PHP 8 path is actually tested:

php: ['7.4', '8.0', '8.1']

Gotchas and Tips

• PHP 8 support is not the same as Laravel version support. The release note says nothing about illuminate/* constraints. Verify the package's supported Laravel versions explicitly before assuming 4.1.0 works with your framework version.
• Other packages may still block PHP 8. Run composer why-not php 8.0 early; the failure is usually a sibling dependency, not this package.
• Watch for PHP 8 behaviour shifts in your own code, not the package's: named arguments breaking on renamed parameters, stricter TypeError on internal function signatures, and changes to string-to-number comparison (0 == "foo" is now false). These show up as test failures after the bump even though the package "just added support".
• Don't blindly composer update. Use --with-dependencies scoped to this package so unrelated dependencies don't drift in the same commit.
• Clear caches after upgrading, especially if you use config:cache or route:cache in deploy scripts — stale cached config referencing old package paths is a classic post-upgrade failure.
• Republish-and-diff, don't overwrite. If the package ships a config file, publish to a temp path and diff, so you don't lose local customisations.
• Extension points: the package's service provider bindings/singletons array and any published config are the intended override surfaces. Prefer container rebinding over forking the package.
• Debugging: php artisan tinker plus app()->make(...) to confirm the binding resolves, and composer show <vendor>/<package> to confirm the installed version is genuinely 4.1.0 and not a held-back 4.0.x.
• Lockfile hygiene: commit composer.lock. A PHP-version bump combined with an uncommitted lockfile is how "works on my machine" incidents start.
• Upgrade note for the assessment itself: 4.1.0 is additive and non-breaking. No deprecations were announced, so no migration work is implied beyond the PHP runtime itself. Revisit this assessment at the next major (5.x) release, where API changes would be expected.