If your Laravel app already runs on PHP 8.3 (or you are about to bump the runtime), several of the new php 8.3 features make your code measurably safer and clearer without touching a single line of framework glue. I am not talking about micro-benchmarks; I mean catching a renamed parent method at load time instead of in production, or rejecting a 2 MB webhook body without ever building the decoded array. Most teams upgrade the version constraint, ship it, and never use any of the new language semantics. That is leaving the best part on the table. Here is what I actually reach for in real Laravel code, with before and after for each.
Why typed class constants stop a whole class of bugs
Before 8.3, a class constant had no declared type. Nothing stopped a child class from redeclaring it as a string when the parent meant an int, and nothing documented the intent for the next developer. In a Laravel codebase full of config constants and enum-adjacent values, that ambiguity is exactly where subtle bugs live. Typed constants let you pin the type, and an incompatible override fails loudly at load time rather than silently coercing later.
<?php
namespace App\Support;
use App\Enums\PaymentStatus;
class PaymentConfig
{
// Before 8.3: just `const TTL = 3600;` with no guarantee of type.
public const int TTL = 3600;
public const string DRIVER = 'redis';
public const PaymentStatus DEFAULT_STATUS = PaymentStatus::Pending;
}Now if a subclass tries to override `TTL` with an incompatible type, PHP refuses to even load the class with: `Fatal error: Type of Sub::TTL must be compatible with PaymentConfig::TTL of type int`. That is the kind of mistake you want surfaced in CI, not in a Tinker session three weeks later. It pairs well with the discipline I describe in my SOLID principles in PHP with real examples write-up, where explicit contracts beat clever implicit ones every time.
How do you check a webhook payload without decoding it?
This is the 8.3 addition I reach for most when handling inbound webhooks. The old pattern was `json_decode()` followed by a `json_last_error()` check just to answer one question: is this even valid JSON? That allocates the entire decoded structure in memory before you have decided whether to trust it. `json_validate()` answers the question without building the array, so it uses less memory on large bodies, which matters when a provider retries a 1-2 MB payload you are going to reject anyway.
<?php
namespace App\Http\Controllers;
use Illuminate\Http\Request;
use Illuminate\Http\Response;
class StripeWebhookController extends Controller
{
public function __invoke(Request $request): Response
{
$raw = $request->getContent();
// Before: decode the whole thing just to check validity.
// $data = json_decode($raw, true);
// if (json_last_error() !== JSON_ERROR_NONE) { abort(400); }
// 8.3: validate first, decode only once you have committed to it.
if (! json_validate($raw)) {
abort(400, 'Malformed JSON payload');
}
$event = json_decode($raw, true, flags: JSON_THROW_ON_ERROR);
// ... handle $event ...
return response()->noContent();
}
}One honest caveat: if you are going to decode the body anyway, wrapping `json_decode` in a try/catch with `JSON_THROW_ON_ERROR` is enough, and `json_validate` then adds a redundant parse. The win is real when you reject a meaningful fraction of payloads early (spammy or oversized bodies) and want to avoid the decode allocation entirely. If you centralise your providers behind one endpoint, this slots in cleanly with the approach in my centralized payment webhooks controller post.
What does the #[\Override] attribute actually catch?
Here is the scenario that bites people. You extend a base class and override one of its methods. Later the parent renames or removes that method, and your override quietly becomes an orphan that nobody calls; the parent's default takes over and behaviour drifts. The `#[\Override]` attribute tells PHP that the method MUST be overriding a real parent method. If no matching parent method exists, you get a fatal error at load time. One important nuance for Laravel: it only works against methods the parent actually declares. It is perfect for your own abstract base classes and for genuinely inherited framework methods, but it does NOT apply to convention methods like a Notification's `toMail()` or `via()`, because the base `Illuminate\Notifications\Notification` class never declares those, the channel system calls them dynamically. Add `#[\Override]` there and PHP fatals immediately, which is itself a useful signal that you were never overriding anything.
<?php
namespace App\Repositories;
use App\Models\User;
abstract class UserRepository
{
abstract public function findActive(int $id): ?User;
}
class EloquentUserRepository extends UserRepository
{
#[\Override]
public function findActive(int $id): ?User
{
return User::query()->whereKey($id)->where('active', true)->first();
}
}If a refactor renames the abstract `findActive`, or you fat-finger it as `findActtive`, PHP stops with: `Fatal error: ...EloquentUserRepository::findActtive() has #[\Override] attribute, but no matching parent method exists`. I add it to every method I intend as an override of a class I extend, especially my own abstract service and repository bases. It is the cheapest insurance against a quiet refactor regression.
Where do readonly classes and dynamic constant fetch fit?
8.1 gave us readonly properties; 8.2 gave us readonly classes. 8.3 rounds out the ergonomics so value objects stop being boilerplate. A `readonly class` marks every property readonly in one keyword, which is what you want for the immutable DTOs and money or value objects that should never mutate after construction.
<?php
namespace App\ValueObjects;
readonly class Money
{
public function __construct(
public int $amount, // store cents, never floats
public string $currency,
) {}
public function add(Money $other): self
{
// Immutable: return a new instance instead of mutating.
return new self($this->amount + $other->amount, $this->currency);
}
}8.3 also adds dynamic class constant fetch, so you can resolve a constant by a runtime expression: `PaymentConfig::{$key}` where `$key` is a variable. Before, that required `constant(PaymentConfig::class . '::' . $key)`, which is stringly typed and easy to get wrong. The new syntax reads like normal code. These immutable value objects also make your service layer far easier to test, which is the whole point of writing testable service classes in Laravel.
- Typed class constants: pin `const int`, `const string`, or an enum type so incompatible overrides fail at load time.
- json_validate(): check inbound JSON without the decode allocation, ideal for large or frequently rejected webhook bodies.
- #[\Override]: guarantee a method really overrides a declared parent method, catching refactor drift and typos (not convention methods like toMail).
- readonly class: one keyword for fully immutable value objects and DTOs.
- Dynamic constant fetch: `PaymentConfig::{$name}` instead of brittle `constant()` string concatenation.
- Randomizer additions: `getBytesFromString()`, `getFloat()`, and `nextFloat()` for correct, unbiased randomness.
What is new in the Randomizer engine?
The `\Random\Randomizer` object engine landed in 8.2, and 8.3 fills the obvious gaps. `getBytesFromString()` builds a random string from a known alphabet, which is exactly what you want for a short, unambiguous reference code on an order or invoice. `getFloat()` gives a uniformly distributed float in a range without the classic `mt_rand() / mt_getrandmax()` bias, and `nextFloat()` returns a value in [0, 1).
<?php
namespace App\Support;
use Random\Randomizer;
final class ReferenceCode
{
public static function generate(int $length = 8): string
{
// Unambiguous alphabet: no 0/O or 1/I to confuse customers.
$alphabet = 'ABCDEFGHJKLMNPQRSTUVWXYZ23456789';
return (new Randomizer())->getBytesFromString($alphabet, $length);
}
}Upgrading the PHP version is the boring part; using what the new version gives you is where the payoff lives.
Should you wait for 8.4 property hooks?
If you are planning the runtime bump on a real codebase, do the PHP version upgrade and the framework upgrade as separate, reviewable steps. The compatibility checklist in my Laravel 11 to 12 upgrade guide covers that sequencing. And yes, PHP 8.4 already shipped property hooks and asymmetric visibility, which finally let you compute or guard a property without a full getter/setter pair. That is genuinely worth planning for, but it is not a reason to skip 8.3. Everything above works today, requires no new dependencies, and most of it is a five-minute change per file.
None of these features rewrite how you build Laravel apps, and that is the point. They remove small, recurring footguns: the untyped constant a junior overrides wrong, the renamed parent method nobody noticed, the webhook decode that blows memory under load. Adopt them incrementally as you touch each file: add `#[\Override]` to your abstract-class overrides, type your config constants, and reach for `json_validate()` the next time you write a webhook controller. The cost is near zero and the bugs you prevent are the annoying, hard-to-reproduce kind. That is the best trade in software.
