DEV Community: Ivan Mykhavko

app() Is Not Dependency Injection: 18 Calls Down to Zero

Ivan Mykhavko — Sun, 25 Oct 2026 22:10:07 +0000

I keep hearing "we use DI everywhere" from Laravel devs whose code is full of app(SomeService::class). The container builds the object, so it feels like DI. It's not. It's Service Locator, and I've said so in code reviews for years.

And still, when I went through the git history of the project I work on, I counted 18 of these calls at the peak. Knowing it's an anti-pattern and not writing it are two different things. This is how that gap closed.

"But We Use DI Everywhere"

Here's what I mean. Both of these get their dependency from the container. The first one is from our codebase in 2024:

// app/Models/User.php, 2024: Service Locator, the class asks for it
public function getCart(): Cart
{
    /** @var CartService $cartService */
    $cartService = app(CartService::class);

    return $cartService->getCartEntity($this);
}

The second one is how a cart action looks on our main branch today:

// app/Actions/Cart/CartIndexAction.php, today: dependency injection, the class receives it
final readonly class CartIndexAction implements Actionable
{
    public function __construct(
        private CartItemDtoFactory $cartItemDtoFactory
    )
    {
    }

    public function handle(CartItemParamDTO $cartItemParamDTO, int $userId, ?int $managerId = null): Collection
    {
        $cartItemDTOs = $this->cartItemDtoFactory->fetchForDisplay($userId, $managerId, $cartItemParamDTO->itemUuids);

        return $cartItemDTOs->values();
    }
}

Two quick definitions, so we argue about the same thing. With dependency injection, a class gets its dependencies from outside, through the constructor or a method parameter, and doesn't care who built them. With Service Locator, the class asks a shared registry for them itself, in the middle of its own code. In Laravel, that registry is the container, and app() is the call.

The container creates the dependency in both cases. What changes is who knows about whom. In the first one, User knows about the container and hides its dependency inside a method body. In the second one, the class has no idea where CartItemDtoFactory comes from, and the constructor tells you everything it needs.

That's the whole cost of Service Locator. The class signature lies about its dependencies, a missing binding fails at runtime instead of at construction, and a constructor that grows too long is a useful warning that app() simply hides.

The Laravel docs lean the same way. They show app() and App::make() for code that has no $app variable at hand, and then, about constructor type-hints:

In practice, this is how most of your objects should be resolved by the container.

One scope note before the numbers. Facades and helpers like config() or Cache:: pull from the container too, and some people call them Service Locator as well. I didn't count them. That's a different debate. This post is only about explicit app(Foo::class)-style resolution of the project's own classes.

What Four Years of Git History Show

I counted calls to app(Foo::class), app()->make(), App::make() and resolve(Foo::class) in app/ on the main branch at a few points in time:

Date	Service Locator calls	PHP files in `app/`
2022-07	5	117
2023-01	12	235
2023-07	18	371
2024-01	18	428
2024-07	16	548
2025-01	11	856
2025-07	3	965
2026-01	1	1052
2026-05	0	1058
2026-10	0	1166

From the 18-call peak down to 0, while app/ grew from 371 to over 1,000 files.

All four spellings lived in the same codebase. Nobody ever decided "we use a Service Locator here". It just happened.

The worst method I found, in a search service from 2024, resolved four services in a row:

// app/Services/Search/SearchResultService.php, 2024
/** @var PriceService $priceService */
$priceService = App::make(PriceService::class);
/** @var CurrencyService $currencyService */
$currencyService = App::make(CurrencyService::class);
// ...
/** @var CartService $cartService */
$cartService = App::make(CartService::class);
/** @var WarehouseService $warehouseService */
$warehouseService = App::make(WarehouseService::class);

Four dependencies, and the constructor mentioned none of them.

A good part of the drop was not refactoring at all. Of the 18, 10 went away only because the whole file was deleted. User::getCart() from the example above was dead too. The cart actions had switched to an injected cart repository long before, and only other dead code still called the model method. It went out with a "Cleanup" commit, together with a few similar calls. The last one needed a real refactoring. Let's be honest: most of these calls lived in old code, and old code gets deleted.

The Last One: A Model That Built Its Own Primary Key

The last call survived until April 2026. It lived in the Order model, which generated its own 8-digit id with a year prefix:

// app/Models/Order.php, until April 2026
public function newUniqueId(): string
{
    $now = Date::now();
    /** @var PrimaryKeyIntegerGenerator $primaryKeyIntegerGenerator */
    $primaryKeyIntegerGenerator = app(PrimaryKeyIntegerGenerator::class);
    $primaryKeyIntegerGenerator
        ->setModel($this)
        ->setLockSeconds(config('limits.order.min_processing_time_lock'))
        ->setPrefix($now->format('y'))
        ->setBuilderAggregate(Order::query()->whereYear('created_at', $now));

    return strval($primaryKeyIntegerGenerator->generate());
}

Eloquent creates models with new, not through the container, so you can't inject anything into a model constructor. And newUniqueId() is a hook Eloquent calls itself, with no arguments. Inside a hook like that, you can only ask for a service: app() or a facade. So if a model needs app(), the logic is probably in the wrong place.

To be fair, app() itself wasn't what blocked testing. In Laravel you can swap a binding with $this->instance() or $this->mock(). The real problem was the order-specific logic (prefix, lock, year scope) living in a model hook. When I wanted to test the edge cases (a locked id, too many attempts), I had to pull that logic out first:

// app/Actions/Order/OrderCreateAction.php, today
final readonly class OrderCreateAction implements Actionable
{
    public function __construct(
        // ...
        private OrderPrimaryKeyGenerator $orderPrimaryKeyGenerator,
        // ...
    )
    {
    }

    public function handle(OrderCreateDTO $orderCreateDTO, int $userId, ?int $managerId = null): Order
    {
        // ...
        $id = $this->orderPrimaryKeyGenerator->generate();

        $orderData['id'] = $id;
        $orderData['number'] = $id;
        // ...
    }
}

The trade-off: the model has $incrementing = false, so an Order::create() that skips the action gets no id from Laravel. In our case both order create actions inject the generator, and the factory sets its own id.

And now the generator gets its own test, no order creation needed:

public function test_order_pk_skips_locked_id_and_tries_next(): void
{
    // Arrange
    $year = Date::now()->format('y');
    $lockedId = intval($year . '000001');
    Cache::lock(Order::class . ':' . $lockedId, 60)->get();

    // Act
    $id = (new OrderPrimaryKeyGenerator())->generate();

    // Assert
    $this->assertSame(intval($year . '000002'), $id);
}

Yes, the generator still uses the Cache and Date facades, config(), and Order::query() inside. So the test still boots the app and touches the database. That's the scope note from above: facades stayed, the hidden app() lookup of our own class went.

The commit that removed the last app() call was titled "Test: Add failing unit tests for OrderPrimaryKeyGenerator". A test pushed it out.

No Lint, No Blocking Review

There was no PHPStan rule, no architecture test, no blocking review.

Over the years I mentioned it to a colleague in code review a few times. More like a note than a rule. At some point I even admitted I use app() myself sometimes and told him to do it his way. My own new calls kept coming for months after that. By git blame, I added more of these calls than he did. So this isn't a story about fixing someone else's code. We both wrote these calls and we both deleted them.

A written rule did appear eventually. "Avoid app(), prefer constructor injection" went into our project guidelines in April 2026, when exactly one call was left. Two weeks later, that one was gone too.

Where You Don't Need app() (And Where It's Fine)

Before reaching for app(), check if Laravel already calls your method through the container. It does in more places than most people think:

handle() in commands and queued jobs
rules() and authorize() in form requests (documented)
after() in form requests (not documented, but it goes through container->call() too)

We once had this in a few form requests (December 2024):

// app/Http/Requests/.../CartItemImportRequest.php, 2024
public function after(): array
{
    /** @var CartValidateImportFileAction $cartValidateImportFileAction */
    $cartValidateImportFileAction = App::make(CartValidateImportFileAction::class);

    return [
        function (Validator $validator) use ($cartValidateImportFileAction): void {
            $cartValidateImportFileAction->handle($validator, $this->file('import_file'));
        },
    ];
}

We ended up dropping that hook for other reasons, so there is no real "after" version. But it never needed App::make(). This is how it could have looked:

// how it could have looked: method injection
public function after(CartValidateImportFileAction $validateImportFile): array
{
    return [
        function (Validator $validator) use ($validateImportFile): void {
            $validateImportFile->handle($validator, $this->file('import_file'));
        },
    ];
}

Heads up: the docs mention dependency injection for rules() and authorize(), not for after(). I checked it on Laravel 12.43.1: the injected class is resolved and the hook runs. I didn't check older versions. One more gotcha: Laravel passes the validator to after() by name, so don't call your injected parameter $validator.

Where app() is OK: service providers, obviously. Code that Laravel builds without the container, like models, when you really can't move the logic out. Lazy resolution of something heavy you only need in one branch. That's a short list. Most of the rest, in my experience, should have been a constructor parameter.

My Rule of Thumb

Not a rule for the team, just what the history taught me:

If a class calls app() for one of your own services, that service belongs in the constructor.
If a model needs app(), move the logic to a service or an action.
If you can't control the constructor, try method injection first. app() comes last.

TL;DR

app(Foo::class) is resolved by the container, but it's still the Service Locator pattern. DI means the dependency arrives through the signature.
In one real project, it went from a peak of 18 calls to 0 while the code roughly tripled. Many calls simply died with old code.
The last one was in a model hook, and writing a test for it pushed it out. The written rule landed when only that one was left.
Form request after() accepts method injection too (undocumented, verified on Laravel 12.43.1).

Laravel docs: Automatic Injection
Laravel docs: Performing Additional Validation on Form Requests
Mark Seemann: Service Locator is an Anti-Pattern
Jimmy Bogard: Service Locator is not an Anti-Pattern (a fair counterpoint)
Adel Faizrakhmanov: Architecture of Complex Web Applications, Dependency Injection chapter
Laravel Actions and Services (my earlier post on where this logic goes)

Author's Note

Thanks for sticking around!
Find me on dev.to, linkedin, or you can check out my work on github.

Laravel, after the happy path.

Schema-Valid Is Not Complete: Strict Output Answered 8 of 30

Ivan Mykhavko — Mon, 19 Oct 2026 08:14:24 +0000

My translation job told me it had translated 8 product names out of 30. The response was valid JSON, it matched my strict schema, and nothing threw. That was the problem.

Structured Outputs promises that the model always follows your JSON Schema. Turns out "follows the schema" and "answered every question" are two different things.

The Problem

In a project I work on, product names come from an ERP feed in Ukrainian, and a queued job translates them with OpenAI. The job sends names in chunks of 30, numbered in the prompt, and asks gpt-4o-mini for a structured answer: response_format with a JSON Schema and strict: true. With strict on, the model can only produce JSON that matches the schema.

This was the response format:

// BEFORE
private function responseFormat(): array
{
    return [
        'type' => 'json_schema',
        'json_schema' => [
            'name' => 'product_translations',
            'strict' => true,
            'schema' => [
                'type' => 'object',
                'additionalProperties' => false,
                'required' => ['translations'],
                'properties' => [
                    'translations' => [
                        'type' => 'array',
                        'items' => [
                            'type' => 'object',
                            'additionalProperties' => false,
                            'required' => ['n', 'en'],
                            'properties' => [
                                'n' => ['type' => 'integer'],
                                'en' => ['type' => 'string'],
                            ],
                        ],
                    ],
                ],
            ],
        ],
    ];
}

Looks safe. Strict mode is on, and every item needs a number and a translation. The prompt also said, in plain words, "return exactly as many items as there are texts".

Then I ran a local bench on 2000 real names before rollout. One chunk of 30 long names came back with 8 translations. I sent that chunk four times: 8 of 30 every time, with the same 267 completion tokens. In a later probe it did come back complete, but only once in 5 attempts.

And the job was happy with it. It wrote 8 rows and logged the other 22 as rejected. No exception, no retry, nothing red. Over the whole bench, 22 names were lost per run this way.

Could a count check with a retry save it? Not really. The same chunk gave the same short answer almost every time, so a retry loop just pays for the same 8 rows again. A count check is still worth having, but as a backstop, not as the fix.

Why Strict Mode Let It Through

Let me be real: strict mode did exactly what it promised. The schema says translations is an array of {n, en} objects. It says nothing about how long that array is. An array of 8 items is valid. So is an empty one.

Strict mode guarantees the shape of the answer. It does not guarantee that every input got an answer. The "return exactly 30 items" rule lived only in the prompt, and the model can ignore the prompt.

Strict mode also can't help when the answer hits the token limit (finish_reason: length) or the model refuses. Then you get cut-off JSON or no JSON at all, so check finish_reason before you parse.

The Fix: One Required Key per Input

The fix is simple: make the schema depend on the input. Instead of a free-length array, the answer is an object with one property per row number. Strict mode makes every property required, so the number of properties is now the number of answers.

// AFTER
private function responseFormat(int $count): array
{
    $keys = array_map(strval(...), range(1, $count));

    return [
        'type' => 'json_schema',
        'json_schema' => [
            'name' => 'product_translations',
            'strict' => true,
            'schema' => [
                'type' => 'object',
                'additionalProperties' => false,
                'required' => $keys,
                'properties' => array_combine(
                    $keys,
                    array_fill(0, $count, ['type' => 'string']),
                ),
            ],
        ],
    ];
}

For a chunk of 3, the schema becomes:

{
  "type": "object",
  "additionalProperties": false,
  "required": ["1", "2", "3"],
  "properties": {
    "1": {"type": "string"},
    "2": {"type": "string"},
    "3": {"type": "string"}
  }
}

Now a short answer is not a valid answer. The model can't skip row 17, because "17" is required, and it can't answer row 17 twice, because an object has only one "17" key.

The call builds the schema from the chunk it sends:

$response = $client->chat()->create([
    'model' => 'gpt-4o-mini',
    'messages' => $messages,
    'response_format' => $this->responseFormat(count($ukTexts)),
]);

Heads up: return early on an empty chunk. range(1, 0) is [1, 0] in PHP, and array_combine() throws. One limit to know: the docs cap a schema at 5000 object properties in total. Fine for chunks of 30, but this pattern doesn't scale to a chunk of 10,000.

The parser reads the row number straight from the key:

public function parse(string $content): array
{
    $decoded = json_decode($content, true);

    if (!is_array($decoded)) {
        return [];
    }

    $result = [];

    foreach ($decoded as $number => $en) {
        if (!is_string($en) || !is_numeric($number) || (int) $number < 1) {
            continue;
        }

        // The prompt numbers from 1, the caller indexes from 0.
        $result[(int) $number - 1] = trim($en);
    }

    return $result;
}

json_decode() turns "1", "2" into integer array keys, so $number arrives as an int. The is_numeric() check only drops non-numeric keys, which is enough when strict mode already rejects any key you didn't list.

What About minItems?

Why not keep the array and add minItems: 30?

When I made this fix, I believed OpenAI rejects minItems in strict mode. That was true in 2024 (there's a community thread about it). It's not true today. The current docs list minItems and maxItems as supported in strict mode, except for fine-tuned models. I also checked it with a live call: gpt-4o-mini, strict, minItems: 30, maxItems: 30. The API accepted it and returned 30 items.

So minItems is a real option now. But it pins only the count. Thirty items with n values 1, 2, 2, 4... are still valid: row 2 has two answers and row 3 has none. Your parser overwrites row 2, loses row 3, and a count check on the response still says 30 of 30.

With a key per row, that answer can't pass: row 17 has exactly one slot, and it is required. What the model puts in that slot is still up to the model. Row 18's translation under "17", or an empty string, passes either schema. That's the job of the quality guard, not the schema.

Results

Same 2000-name sample, same model, same prompt, before and after:

	Free-length array	Key per row
Problem chunk (30 long names)	8/30 on 4 of 4 attempts	30/30 on 4 of 4 attempts
Names lost by the model, per run	22	0
Names translated and accepted	1974	1997
Rejected by the quality guard	4	3

The rejected ones are a different story: those are bad translations caught by a separate guard, and that's fine. The lost ones were never there to check.

TL;DR

strict: true guarantees the shape of the JSON, not that every input got an answer.
A free-length array lets the model answer short and still pass the schema.
Build the schema per request: one required property per input row.
minItems is supported in strict mode today, but it pins only the count: duplicate and missing row numbers still pass.
Keys stop skipped and doubled rows, not wrong content. Keep a finish_reason check and a quality guard behind them.
If a rule lives only in the prompt, assume the model will break it on some chunk.

💡 If your structured output has a list that should match your input, ask yourself: can a shorter answer pass this schema? If yes, assume it will.

Author's Note

Thanks for sticking around!
Find me on dev.to, linkedin, or you can check out my work on github.

Laravel, after the happy path.

Mail::alwaysTo() Guards One Mailer: The Staging Leak It Leaves Open

Ivan Mykhavko — Fri, 09 Oct 2026 21:23:02 +0000

A few weeks ago I saved a link about keeping test emails away from real users. The plan was simple: add Mail::alwaysTo() to our staging setup and stop worrying. The Laravel docs list it for local development, and Laravel News plus at least five other blog posts I found carry it over to staging. None of them mention a limit.

Before shipping it, I opened the framework source to see what that call actually does. Turns out, it guards only one of your mailers.

The Safety Net Everyone Copies

Here is the usual version, adapted from the docs and wrapped in an environment check:

use Illuminate\Support\Facades\Mail;

public function boot(): void
{
    if (! $this->app->isProduction()) {
        Mail::alwaysTo('staging@example.com');
    }
}

Every message sent through it gets its to replaced, and cc and bcc are removed. Looks complete.

The Problem

Now add a second mailer. Say transactional mail goes through the default one and invoices through another:

// config/mail.php
'default' => env('MAIL_MAILER', 'smtp'),

'mailers' => [
    'smtp' => [/* ... */],
    'billing' => ['transport' => 'postmark'],
],

I tested this in a sandbox with Laravel 12.43, both mailers on the array transport, and Mail::alwaysTo('staging@example.com') in place:

Mail::to('client@example.com')->send(new InvoiceMail());
// sent to: staging@example.com

Mail::mailer('billing')->to('client@example.com')->send(new InvoiceMail());
// sent to: client@example.com

Notifications have the same hole. MailMessage lets you pick a mailer too:

public function toMail(object $notifiable): MailMessage
{
    return (new MailMessage)
        ->mailer('billing')
        ->line('Your invoice is ready.');
}
// sent to: the real customer

Even with scrubbed staging data, real addresses slip through: admins, seeded clients, imported leads. Each one gets the invoice.

Pointing MAIL_MAILER at Mailpit or log on staging doesn't close this either. It swaps the default mailer only, so if staging has the real Postmark key, Mail::mailer('billing') still uses it.

Why It Happens

Mail::alwaysTo() is not a global setting. The facade points to MailManager, and MailManager forwards unknown calls to the default mailer only:

// Illuminate\Mail\MailManager
public function __call($method, $parameters)
{
    return $this->mailer()->$method(...$parameters);
}

So alwaysTo is stored on one Mailer instance. When you ask for Mail::mailer('billing'), the manager builds a separate instance in resolve(), and that instance gets its global addresses from config:

foreach (['from', 'reply_to', 'to', 'return_path'] as $type) {
    $this->setGlobalAddress($mailer, $config, $type);
}

setGlobalAddress() reads mail.mailers.billing.to first, then falls back to mail.to. Your alwaysTo call is never part of that.

This isn't new. Issue #44024 described the same thing in 2022 and was closed as a support question. The logic is the same in Laravel 12 and on the 13.x branch.

There is a second way it fails, under Octane. Service providers boot once, but Octane forgets the resolved mailers between requests, so the redirect set in boot() is lost even in a single-mailer app. I didn't run Octane for this one. A Laravel maintainer confirmed it in discussion #53727.

The Fix

Put the redirect where every configured mailer reads it: the config. config/mail.php has no to key by default, but MailManager picks one up if you add it:

// config/mail.php
'to' => [
    'address' => env('MAIL_TO_ADDRESS'),
    'name' => env('MAIL_TO_NAME', 'Staging Inbox'),
],

# .env on staging only
MAIL_TO_ADDRESS=staging@example.com

In the same sandbox, both mailers now sent to staging@example.com. The address is applied each time a mailer is built, so it also survives Mail::forgetMailers(), which is what Octane does between requests. I checked that part with a plain call, not a running Octane server.

When MAIL_TO_ADDRESS is not set, nothing changes, so production is unaffected without any if in a provider. Leave the key out of the production .env entirely. An empty MAIL_TO_ADDRESS= is still a value, and every send then fails with RfcComplianceException.

One trade-off: this fails open. Forget the variable on a new staging box and mail goes out for real. I'd add a guard for that:

public function boot(): void
{
    if ($this->app->environment('staging') && blank(config('mail.to.address'))) {
        throw new RuntimeException('MAIL_TO_ADDRESS must be set on staging.');
    }
}

Heads up: two exceptions. A mailer with its own to key in mail.mailers wins over the global one, even 'to' => null. And a mailer built on the fly with Mail::build([...]) skips global addresses completely.

A Test That Keeps It Fixed

The per-mailer to is the one that bites later. Someone adds a to to one mailer months later, never having read this config. So I'd rather have a test that checks every mailer against the real config. First, give the test environment the address:

<!-- phpunit.xml -->
<env name="MAIL_TO_ADDRESS" value="staging@example.com"/>

use Illuminate\Support\Facades\Mail;
use Tests\TestCase;

final class MailRedirectTest extends TestCase
{
    public function test_every_mailer_sends_to_the_staging_inbox(): void
    {
        // Arrange
        $mailers = array_keys(config('mail.mailers'));

        foreach ($mailers as $name) {
            config(["mail.mailers.{$name}.transport" => 'array']);
        }

        Mail::forgetMailers();

        foreach ($mailers as $name) {
            // Act
            Mail::mailer($name)->raw('ping', fn ($message) => $message->to('client@example.com'));

            // Assert
            $sent = Mail::mailer($name)->getSymfonyTransport()->messages()->last()->getOriginalMessage();

            $this->assertSame('staging@example.com', $sent->getTo()[0]->getAddress(), "Mailer [{$name}] escaped the redirect");
        }
    }
}

It swaps every transport to array, so nothing is actually sent. Mail::forgetMailers() matters here: a mailer resolved before the test keeps its old transport, and with a log default the assertion crashes on LogTransport, which has no messages().

With the nine mailers from the default config (smtp, ses, postmark, resend, sendmail, log, array, failover, roundrobin) it passes. Give billing its own to and it fails with Mailer [billing] escaped the redirect. Delete the to block from config/mail.php and it fails on smtp. Don't use Mail::fake() here: the fake replaces the manager, so it can't tell you anything about redirects.

Final Thoughts

Mail::alwaysTo() is fine on your laptop, with one mailer and no Octane. For staging, where real addresses live in the database, I'd use mail.to in config, a boot guard for the missing variable, and a test that walks every mailer.

Author's Note

Thanks for sticking around!
Find me on dev.to, linkedin, or you can check out my work on github.

Laravel, after the happy path.

hash_equals('', '') Is true: When an Empty Config Opens Basic Auth

Ivan Mykhavko — Fri, 21 Aug 2026 20:10:00 +0000

I wasn't hunting for this. I was reading a Basic Auth middleware in a project I work on, checking something unrelated, and I stopped on one line. The comparison used hash_equals(), which is the right function. The credentials came from config, which is the right place. And if that config was empty, the middleware let anyone in.

The Problem

Here's the shape of it. A small internal API, protected by hand-rolled HTTP Basic Auth instead of the full auth stack, because the caller is another service and there's no user to log in:

<?php

declare(strict_types=1);

namespace App\Http\Middleware;

use Closure;
use Illuminate\Http\Request;
use Symfony\Component\HttpFoundation\Response;

final class EnsureBasicAuth
{
    public function handle(Request $request, Closure $next): Response
    {
        $expectedUsername = config('services.internal_api.username');
        $expectedPassword = config('services.internal_api.password');

        $usernameOk = hash_equals($expectedUsername, (string) $request->getUser());
        $passwordOk = hash_equals($expectedPassword, (string) $request->getPassword());

        if (! $usernameOk || ! $passwordOk) {
            return response('Unauthorized', Response::HTTP_UNAUTHORIZED);
        }

        return $next($request);
    }
}

Watch the method name. In a Laravel codebase $request->getUser() isn't $request->user(). It's Symfony's, and it returns the Basic Auth username as a string, or null when there's no Authorization header at all.

Nothing in that class is a typo. hash_equals() is the function everyone tells you to use, and the user input sits in the second argument, which is the correct order.

Now put a route behind it and send three kinds of request at it, while config/services.php reads those two values from the environment. Both credentials move together here, because they come from the same .env block and a fresh copy of .env.example leaves both blank:

Both credentials	No `Authorization` header	`Basic Og==` (blank user, blank password)	admin + wrong password
empty strings	200	200	401
missing entirely	500	500	500
`admin` / `s3cret`	401	401	401

Look at the top row. An empty credential doesn't lock the door, it removes it, and a request carrying nothing at all gets a 200. Meanwhile the check most of us actually run, "let me try a wrong password", returns a confident 401 and reports that the guard works.

Why hash_equals Says Yes

Three small things line up.

hash_equals('', '') returns true, and that's not a bug. The function compares two strings and two empty strings are equal. What it protects is the timing of the comparison, so an attacker can't learn the secret byte by byte. (It leaks a little even there: a length mismatch returns early, so the length of your secret is visible in the timing. The manual says so.) None of that has anything to do with whether your secret exists.

A request with no Authorization header gives you null from getUser(), and the (string) cast turns null into ''. So an attacker doesn't even need to send Basic Og==. Sending nothing produces the same empty string.

And the env() default never fires. The Laravel docs are exact about this: the second argument to env() "will be returned if no environment variable exists for the given key". A bare INTERNAL_API_USER= line means the key does exist, holding an empty string, so env('INTERNAL_API_USER', 'fallback') hands you '' and not 'fallback'.

That's the state a box is in right after someone copies .env.example over and hasn't filled it in yet.

The 500 Is the Warning, Not the Bug

Now the middle row. Drop those two lines out of .env completely and config() returns null, so hash_equals() gets a null and throws:

TypeError: hash_equals(): Argument #1 ($known_string) must be of type string, null given

Heads up: declare(strict_types=1) has nothing to do with this. hash_equals() checks its argument types itself rather than letting PHP coerce them, so it rejects every non-string in both weak and strict mode, and it names the type it got:

hash_equals(): Argument #1 ($known_string) must be of type string, int given
hash_equals(): Argument #1 ($known_string) must be of type string, true given
hash_equals(): Argument #1 ($known_string) must be of type string, array given

A 500 is an ugly way to refuse a request, but it does refuse it. And that's the trap, because the obvious way to make the noise stop is a cast on the expected value:

// Don't. This is the whole vulnerability in two characters.
$expectedUsername = (string) config('services.internal_api.username');
$expectedPassword = (string) config('services.internal_api.password');

Now null becomes '' before it ever reaches hash_equals(), the exception is gone, and the middle row of that table turns from 500 into 200. Someone tidying up their error tracker just opened the endpoint to the internet.

The Fix

Refuse to compare at all when there's nothing to compare against. Two guards, both above the hash_equals() calls:

public function handle(Request $request, Closure $next): Response
{
    if (! $this->credentialsMatch($request)) {
        return response('Unauthorized', Response::HTTP_UNAUTHORIZED, [
            'WWW-Authenticate' => 'Basic realm="Internal"',
        ]);
    }

    return $next($request);
}

private function credentialsMatch(Request $request): bool
{
    $expectedUsername = config('services.internal_api.username');
    $expectedPassword = config('services.internal_api.password');

    if (! is_string($expectedUsername) || ! is_string($expectedPassword)) {
        return false;
    }

    if ($expectedUsername === '' || $expectedPassword === '') {
        return false;
    }

    $usernameOk = hash_equals($expectedUsername, (string) $request->getUser());
    $passwordOk = hash_equals($expectedPassword, (string) $request->getPassword());

    return $usernameOk && $passwordOk;
}

Both hash_equals() calls run before the && sees anything, so neither comparison gets skipped and the timing stays flat. The WWW-Authenticate header is a small bonus fix: a bare 401 without it isn't valid HTTP.

Three things I'd add around it in production, none of which belong inside the middleware:

Validate the config at deploy time. A misconfigured guard returns 401 to everybody, which is safe but completely silent. You find out when the other service starts alerting. A boot-time assertion, or a .env validation step in the pipeline, tells you first.
Keep it behind TLS and a throttle. Basic Auth is base64, not encryption, and nothing here slows down someone guessing passwords. ->middleware('throttle:10,1') costs nothing.
Read config, never env(), inside a middleware. Turns out this is a second trap: after php artisan config:cache the .env file isn't loaded at all, and env() returns only real system-level environment variables. A value that lives only in .env comes back null on a cached deploy, which drops you straight into the middle row of that table.

The Test

The test that catches this doesn't test the password. It tests the config:

#[Test]
public function it_rejects_everyone_when_the_credentials_are_empty(): void
{
    // Arrange
    config([
        'services.internal_api.username' => '',
        'services.internal_api.password' => '',
    ]);

    // Act & Assert
    $this->get('/internal/health')->assertUnauthorized();
    $this->withBasicAuth('', '')->get('/internal/health')->assertUnauthorized();
}

Add a second one setting both values to null, and a third for the happy path. Against the original middleware, the first two go red and say exactly what the table said:

✓ it allows the configured credentials
⨯ it rejects everyone when the credentials are empty
  Expected response status code [401] but received 200.
⨯ it rejects everyone when the credentials are missing
  Expected response status code [401] but received 500.

Notice which one passed. The happy-path test is green on the broken middleware and green on the fixed one, so a suite that only checks "right credentials in, wrong credentials out" never had a chance here.

TL;DR

hash_equals('', '') is true. Constant-time comparison guards the timing of a comparison, not the existence of a secret.
INTERNAL_API_USER= isn't a missing variable, it's an empty string, and the env() default doesn't fire for it.
No Authorization header means getUser() is null, and one (string) cast on the expected side makes null match it.
If a misconfigured guard throws, don't cast the error away. Put an "is this configured at all" branch above every credential comparison.
Test the unconfigured states. Wrong-password tests pass on broken code.

💡 If your callers are real users in a database, skip all of this and use Laravel's own auth.basic, which can't get into an empty-secret state. Just know it wants a users table, keys on email by default, and starts a session, so it's a poor fit for service-to-service calls.

Author's Note

Thanks for sticking around!
Find me on dev.to, linkedin, or you can check out my work on github.

Laravel, after the happy path.

Hunting Elephants Again: Reviving a Dead Travian Bot with an AI Agent

Ivan Mykhavko — Fri, 17 Jul 2026 15:39:37 +0000

I had a side project rotting in a private repo for three years. Last week I brought it back to life in a weekend, and an AI agent did most of the boring parts.

The project is travian-elephant-finder, a small Node tool for the browser game Travian. On the map, oases are tiles guarded by wild animals. Clear one and you get hero experience and a production bonus. Elephants are the toughest guards, so they give the most hero XP, and if you attack with Cages equipped you capture them as free defenders instead of killing them. So elephant oases are the best targets on the map. Finding them by hand means opening hundreds of tiles one by one. The tool scans the area around your village and hands you a sorted report of where the elephants are.

Yes, automating Travian is against its terms of service. I run this on a throwaway account, for fun, and the post is about the revival workflow, not a pitch to go bot your favorite game.

Not Laravel, but the revival workflow is pure backend and it travels: a dead scrape swapped for a real API, an expensive loop trimmed by a cheap upfront query. The same moves you would make in any codebase, Laravel included.

Why it died

Games change their frontend, and scrapers rot. My login used to grab a bearer token out of an obfuscated inline <script> on the dashboard page:

// the old "auth": scrape a token out of eval(atob('...')) on /dorf1.php
const line = scripts.find((s) => s.includes('eval'));
const atobString = regExp.exec(line)[1].replace('atob(', '').replace(/'/g, '');
const decoded = Buffer.from(atobString, 'base64').toString('binary');
const token = decoded.split('&&')[1].trim(); // fingers crossed

Travian moved to a new JS bundle and that eval() pattern vanished from the page. The scrape returned nothing, the token refresh silently failed, and the bot just looped 401s forever. Classic dead side project: not broken loudly, broken quietly.

What the AI got right

I pointed Claude Code at the repo and described the symptom: 401 loop, token never refreshes. It found the dead scrape, traced how the game's own client logs in, and replaced the whole fragile thing with the real login API:

const loginResponse = await axiosDefaultInstance.post(`${server}/api/v1/auth/login`, {
  name: username,
  password,
});
const { code } = loginResponse.data;
// exchange the code for a JWT session cookie, done

No token scrape, no manual cookie-paste from DevTools. This is the kind of work AI is genuinely good at: mechanical, well-defined, annoying. It also redesigned the ugly HTML report and cleaned up the CLI output, again in minutes.

What I still had to figure out

The agent did not hand me the good ideas. The best win in this rewrite was noticing that Travian publishes a public map.sql dump of every village:

curl -s https://ts5.x1.europe.travian.com/map.sql | head
# INSERT INTO x_world VALUES (...);  -- villages only, no oases

Villages never sit on oases, so any tile in that dump can be skipped before the scan even opens it. On my run that trimmed about 13% of the HTTP requests. The AI wrote the parser cleanly once I decided to use it, but the "wait, I can rule these tiles out for free" moment was mine. Same with the search model: I chose the "one center point, one distance" design that scans a circle around the village; the agent just implemented it.

That is the split I keep seeing. AI removes the friction. You still bring the judgment.

Lessons Learned

Scraping JS-injected values is the first thing to break. If the site has a real API, use it. My token scrape was dead code for who knows how long.
Rule out work before you loop. One map.sql fetch listed every village, so the scan could skip those tiles instead of opening each one. It did not replace the per-tile loop, it pruned it, the same way filtering rows before a loop beats checking each inside it.
Here the AI did the grunt work and I did the thinking. It resurrected the boring 80%. The 20% that made the tool better was still my call.
A weekend is enough now. Projects I would have left dead are worth reviving when the tedious part is cheap.

TL;DR

I brought travian-elephant-finder back from three years dead in a weekend. An AI agent handled the mechanical rewrites (dead scrape to a real login API, report cleanup), but the calls that actually made it better, like skipping village tiles from the public map.sql to trim the scan and picking the search model, were still mine.

Author's Note

Thanks for sticking around!
Find me on dev.to, linkedin, or you can check out my work on github.

Laravel, after the happy path.

bcrypt and Laravel: 72 Bytes, Not 72 Characters

Ivan Mykhavko — Sun, 21 Jun 2026 18:19:06 +0000

I expected bcrypt to silently drop characters past 72. I did not expect it to bake in half an emoji.

That's what happens with a specific password combination I tested. The original password still works. But strip the emoji (a password manager, a different keyboard, a Unicode normalizer) and you're locked out. Your Laravel validator passed it as valid the whole time.

The 72-Byte Rule

bcrypt has a hard input limit of 72 bytes. Not characters - bytes.

When you call password_hash($password, PASSWORD_BCRYPT), PHP silently truncates anything past byte 72. Most developers know this in theory. But for ASCII-only apps, it never bites. 72 ASCII characters is already a very long password, and the silent clip is harmless in practice.

The trouble starts with multi-byte scripts.

How Many Characters Fit?

Character set	Bytes per char	Effective bcrypt limit
ASCII	1	72 chars
Cyrillic	2	36 chars
CJK (Chinese, Japanese, Korean, common block)	3	24 chars
Emoji	4	18 chars

Past the byte limit, a longer password adds no security at all. A 200-character Cyrillic password hashes identically to its own first 36 characters. Byte 73 and beyond simply do not exist from bcrypt's point of view. So "longer always produces a stronger bcrypt hash" is not true.

A Cyrillic user with a 37-character password gets silently truncated at char 36. The hash is still consistent. The user logs in fine, but any variation past character 36 doesn't matter to bcrypt. Annoying from a security standpoint, but it does not break login.

The Split-Byte Trap

The 72-byte limit cuts at a byte boundary, not a character boundary. If a multi-byte character falls on that cut, bcrypt bakes in an incomplete UTF-8 sequence.

// 35 Cyrillic chars = 70 bytes, emoji = 4 bytes, total = 74 bytes
$password = str_repeat('А', 35) . '🔑';
$hash = password_hash($password, PASSWORD_BCRYPT);

password_verify($password, $hash);           // ?
password_verify(str_repeat('А', 35), $hash); // ?
password_verify(str_repeat('А', 36), $hash); // ?

// PHP 8.4, Laravel sandbox:
verify(original 74 bytes):          bool(true)
verify(trimmed 35 Cyrillic, 70 bytes): bool(false)
verify(36 Cyrillic, 72 bytes):      bool(false)

The original full string still verifies. bcrypt truncates it to the same 72 bytes on both sides. But every other attempt fails.

What happened: bcrypt stored 70 Cyrillic bytes plus the first 2 bytes of the 4-byte emoji (F0 9F from the sequence F0 9F 94 91). That's the effective password now. The trailing emoji looks like decoration, but it's load-bearing.

I tested this in my Laravel sandbox across several character sets:

Input	Total bytes	Original verifies?	Cyrillic-only verifies?
36x Cyrillic + extra chars	72+2	yes	yes
24x CJK + extra chars	72+3	yes	yes
18x emoji + extra chars	72+4	yes	yes
35x Cyrillic + 1 emoji	74	yes	no

For most overflow cases both the original and any Cyrillic-only variant work - the clip is harmless. With the split-byte case, only the exact original string works. A user who enters "35 Cyrillic chars" thinking the emoji was decoration is locked out. That happens when a password manager strips the emoji, a keyboard can't type it, or the app normalizes Unicode on input.

What Laravel Does About It

Laravel's Password::max() uses mb_strlen() under the hood. That counts characters, not bytes.

// Looks safe. Is not.
'password' => Password::min(8)->max(72),

A 37-char Cyrillic password: mb_strlen = 37, passes your validator. strlen = 74. bcrypt gets 74 bytes and clips at 72. Depending on where the boundary lands, the user either gets silent truncation or the split-byte lockout.

Laravel 12 added a BCRYPT_LIMIT config option in config/hashing.php:

// config/hashing.php
'bcrypt' => [
    'rounds' => env('BCRYPT_ROUNDS', 12),
    'limit'  => env('BCRYPT_LIMIT', 72),
],

Heads up: BCRYPT_LIMIT was introduced in Laravel 12. On Laravel 11 and below, you need to handle this yourself.

When set, Laravel's bcrypt driver throws an InvalidArgumentException if the password exceeds 72 bytes. That prevents silent truncation. But it does not close the validation gap: Password::max(72) still accepts passwords that exceed 72 bytes, and BCRYPT_LIMIT then throws at hash time. Without explicit exception handling, that bubbles as a 500. Your user submitted a valid form and hits an error.

Fix Options

Validate at the form layer, before hashing. bcrypt is intentionally slow: one unauthenticated request triggers a full key schedule regardless of input length. Without an upper bound, that cost is fixed per request whether the input is 10 bytes or 10 000. Rate limiting is still essential; the byte cap just removes wasted work on input bcrypt would ignore anyway.

Option 1: Validate byte length directly

'password' => [
    'required',
    'string',
    'min:8',
    function ($attribute, $value, $fail) {
        if (strlen($value) > 72) {
            $fail('The password is too long.');
        }
    },
],

strlen() in PHP counts bytes, not characters. This catches both the silent truncation and the split-byte case before hashing happens.

Option 2: Switch to Argon2id

// config/hashing.php
'driver' => 'argon2id',

No 72-byte limit. For existing users registered with bcrypt, rehash on first successful login:

if (Hash::needsRehash($user->password)) {
    $user->update(['password' => Hash::make($plaintext)]);
}

PHP's password_verify() reads the algorithm from the hash directly, so existing bcrypt users can still log in after you change the default driver. Users log in fine throughout.

Option 3: Pre-hash with SHA-256 before bcrypt

OWASP's Password Storage Cheat Sheet covers this pattern. Their recommended form uses HMAC with a server-side pepper:

// Always produces 64 ASCII bytes - fits bcrypt comfortably
$prehashed = hash_hmac('sha256', $password, $pepper);
$stored    = password_hash($prehashed, PASSWORD_BCRYPT);

// Verify:
password_verify(hash_hmac('sha256', $input, $pepper), $stored);

Plain hash('sha256', $password) without a pepper has a known weakness: if bcrypt is cracked, the attacker gets the raw SHA-256 hash and can crack it without bcrypt's cost (password shucking). The HMAC form closes that gap. Either way, this is non-standard and adds complexity to your auth layer.

If you're starting a new app, use Argon2id and skip this entire problem (check defined('PASSWORD_ARGON2ID') first - some shared hosts and older builds lack it). If you're maintaining an existing bcrypt app, add the byte-length validator today and plan a migration to Argon2id when you have the runway.

That user from the intro (the one locked out with a valid password) hit the split-byte case. The fix is one validator rule.

TL;DR

bcrypt truncates at 72 bytes, not characters. Cyrillic caps at 36 chars, CJK at 24, emoji at 18
If the cut falls inside a multi-byte char, the trailing emoji becomes load-bearing: original verifies, anything that strips the emoji does not
Password::max(72) uses mb_strlen (characters, not bytes), so it does not catch this
Laravel 12 BCRYPT_LIMIT=72 throws at hash time but does not block invalid input at the form level
Fix: validate with strlen($password) > 72, switch to Argon2id, or pre-hash with hash_hmac('sha256', ...)

💡 Use strlen() to validate password byte length. mb_strlen() won't catch the dangerous cases.

References

Author's Note

Thanks for sticking around!
Find me on dev.to, linkedin, or check out my work on github.

Laravel, after the happy path.

wayback-video: Turn Any Site's History into a Video

Ivan Mykhavko — Mon, 15 Jun 2026 14:30:08 +0000

Side project outside my usual PHP world, but worth sharing.

I have a habit of Googling old websites just to see what they looked like. GitHub circa 2008. Wikipedia in 2003. The Wayback Machine has it all, but clicking through snapshots one at a time never gives you the full picture of how a site evolved.

So I built wayback-video - a Python CLI tool that takes a URL, pulls its entire Wayback Machine archive, renders each snapshot with a headless browser, and assembles everything into an MP4.

wayback-video https://github.com --scroll --interval year --from 2008

That's it. You get a video showing GitHub's design history from 2008 to today, one full-page scroll per year.

How It Works

The tool runs a 4-phase pipeline:

Fetch. Query the Wayback CDX API for all successful HTML captures of the URL. For a site archived monthly over 20 years, that's thousands of records. The tool collapses captures server-side by timestamp, then deduplicates by content digest locally, and selects a few candidates per time period.

Sample. Group captures by month, quarter, or year. Pick the best representative from each bucket.

Render. Open each archived URL in Playwright using if_ replay mode (a Wayback URL prefix that strips the toolbar). Archived asset URLs are still rewritten to archive copies, so CSS, images, and scripts load from the archive, not the live server. Playwright takes a full-height screenshot.

Then ffmpeg stitches it all into an MP4. Simple concat, crossfade, or scroll-pan.

The Part That Breaks

Rendering archived pages is fine until you hit SPAs. Any SPA that registered a Service Worker - when it was archived, the SW got archived too. When you replay it, the SW registers and starts intercepting requests, but now it points to the live origin, not the archive. The page breaks.

wayback-video blocks Service Workers before the page loads. It also waits for JS to finish rendering after page load (default 2.5s - Playwright's network-idle events don't work reliably against Wayback's proxy, so a fixed wait is the practical fallback). If the resulting page has fewer than 200 characters of body text, it's probably a spinner or an archived 404 - so the tool skips it and tries the next candidate (the next archived snapshot from the same time bucket).

Old static sites render fine. JS-heavy SPAs are hit or miss - depends on what Wayback actually captured.

Deduplication

Not every year looks different. Some sites go through five years without a major redesign. Without dedup, you get the same frame repeated five times in a row.

Two passes run automatically in --scroll mode:

Exact dedup by SHA-256 hash. Byte-identical renders are dropped.
Average hash (aHash) comparison. Consecutive frames with low visual distance get merged into one clip with a combined label like 2011-2014.

The threshold is configurable (--similarity-threshold, default Hamming distance of 10, max 64). Raise it to merge more aggressively, lower it to keep subtle changes.

Modes

Mode	When to reach for it
Default (CDX)	Fixed-viewport screenshots per period
`--scroll`	Full-page height with pan animation (recommended)
`--hybrid year`	Wayback pre-captured PNGs first, Playwright as fallback
`--wayback-screenshot year`	Wayback PNGs only, no browser, fast
`--at-interval year`	One capture per year at a fixed date, via Availability API
`--image`	Logo or image file evolution, no page render

--scroll is what I use by default. Full page height means you actually see the layout, not just the above-the-fold hero. Scroll speed is auto-calculated from page height, so nothing crawls or blurs past.

Get Started

git clone https://github.com/tegos/wayback-video.git
cd wayback-video
pip install -e .
playwright install chromium

# Ubuntu/Debian
sudo apt install ffmpeg

# macOS
brew install ffmpeg

Heads up: playwright install chromium downloads ~130MB of Chromium - required even if you already have Chrome installed.

Then pick a site you're curious about:

# Laravel's homepage through the years
wayback-video https://laravel.com --scroll --interval year --crossfade 0.4

# Wikipedia, month by month, over its first decade
wayback-video https://wikipedia.org --scroll --interval month --from 2001 --to 2010

# Fast mode: Wayback's pre-captured PNGs only, no browser needed
wayback-video https://mozilla.org --wayback-screenshot year --scroll

Requires Python 3.10+ and ffmpeg installed separately.

TL;DR

wayback-video turns any site's Wayback Machine history into an MP4
Archived pages render in if_ mode with Service Workers blocked so SPAs and assets load cleanly from the archive
aHash dedup merges visually identical consecutive years into one labeled clip
--scroll is what I use by default: full-page height, smooth pan animation

👉 github.com/tegos/wayback-video

Author's Note

Thanks for sticking around!
Find me on dev.to, linkedin, or you can check out my work on github.

Laravel, after the happy path.

Composer Update Is Not Safe Anymore

Ivan Mykhavko — Fri, 12 Jun 2026 09:58:10 +0000

Saturday morning. I opened Twitter and saw a tweet about the Laravel-Lang packages being compromised.

My first reaction was simple: "I don't use that package."

Then I opened composer.json on a project I work on and found this in require-dev:

"laravel-lang/lang": "^14.8",
"laravel-lang/publisher": "^16.8",

That changed things.

What Actually Happened

The attack used laravel-lang packages as the distribution channel. And the sneaky part: the main repository branch looked completely clean. No suspicious commits, no new code. The malicious payload was pushed via git tags on forks.

Most developers would not notice anything. Just a routine composer update, same as always.

Once installed, the payload executed at autoload time. That means every php artisan command, queue worker, or web request running that codebase triggered the malware the moment PHP hit require_once __DIR__.'/../vendor/autoload.php' in public/index.php. Silently. No error, no red screen, nothing.

The malware was a credential stealer. It searched the machine for:

.env files from Laravel projects
AWS access keys and session tokens
SSH private keys
GitHub CLI tokens
NPM tokens
Infrastructure secrets

This is not a SQL injection that messes with your database rows. This is a key stealer that runs on your machine and takes everything it finds.

Aikido Security caught it and reported it to Packagist. Packagist removed the affected versions. But if you ran composer update during that window, you were exposed.

Why Supply Chain Attacks Are Different

Classic Laravel security talks about SQL injection, XSS, CSRF. Those are attacks that come from outside users sending malicious input to your application.

Supply chain attacks come from inside your own development process. The attacker does not need to find a vulnerability in your code. They need to compromise one developer account at one package maintainer. Every project depending on that package is now exposed.

With AI tools, these attacks are getting more sophisticated and more frequent. The JavaScript ecosystem has been dealing with hundreds of similar incidents. PHP is catching up, unfortunately.

What I Actually Changed

On a project I work on, we run composer update on a regular schedule. After this incident, I sat down and wrote it all out.

The full workflow now looks like this:

# 1. Run composer update inside Docker
docker compose exec app composer update

# 2. Pin exact versions using jack raise-to-installed
docker compose exec app vendor/bin/jack raise-to-installed --dry-run  # preview first
docker compose exec app vendor/bin/jack raise-to-installed             # apply

# 3. Update lock hash
docker compose exec app composer update --lock

# 4. Commit everything
git add composer.json composer.lock
git commit -m "chore: update dependencies"

rector/jack is a tool by the Rector team that handles version management in composer.json. The raise-to-installed command takes whatever is currently installed and raises the constraints to match exactly. Instead of "guzzlehttp/guzzle": "^7.10", you get "guzzlehttp/guzzle": "^7.11". Each future composer update will only reach what you explicitly allow. This is not standard Composer practice. It trades upgrade convenience for a narrower blast radius on unexpected jumps.

One gotcha we hit: on a Laravel 10 project, bare composer update can fail with an advisory block. The fix is to add this to composer.json config:

"config": {
    "audit": {
        "abandoned": "report"
    },
    "policy": {
        "advisories": {
            "block": false
        }
    }
}

Advisories are reported, not blocking. You still see them and still have to act on them. The update just runs.

Always verify what got bumped before committing. On that project, it runs PHP 8.1, so packages that require 8.2+ cannot be allowed in. After raise-to-installed dry run, check that nothing jumped to a version with a higher PHP floor.

One important caveat: this workflow would not have prevented the Laravel-Lang incident itself. By the time jack raise-to-installed runs, the infected version is already installed. raise-to-installed then pins that infected version as the new baseline. The actual defenses at install time are limited. composer audit helps against known advisories, but not against a malicious package that was compromised minutes ago. Run it anyway. Watch community reports before you update.

composer audit

Before updating, run:

composer audit

It checks installed packages against the PHP Security Advisories Database. On a fresh project, nothing shows up. On an older one, you might see something like:

Found 3 security vulnerability advisories affecting 2 packages:

Package symfony/http-kernel
CVE-2026-XXXXX: ...

Package league/commonmark
CVE-2026-XXXXX: ...

Run it before and after updating. It tells you what you are actually fixing and confirms you resolved the reported issues.

Question Every Dependency

Every dependency is another trust relationship. Before adding one, ask: do I need the whole package, or just one function?

Not everything is replaceable. intervention/image or maatwebsite/excel? No. But have you actually thought about it, or did you just composer require by reflex?

Fewer packages means fewer attack surfaces. Fewer broken upgrades when the next Laravel major drops, too.

Check Social Media Before Updating

Follow Laravel security researchers and package maintainers on social media. Major incidents surface there before formal advisories land. The Laravel-Lang attack is a good example.

What Packagist Is Doing

Composer 2.10 integrated Aikido malware detection directly into Packagist. Every release tag now gets scanned automatically.

Stable version immutability is also shipping: once a version is published, it cannot be silently overwritten. One of the tricks in the Laravel-Lang attack was rewriting existing tags to inject malware, making it look like a version you already trusted.

Minimum release age is coming: new releases sit in a quarantine window before they show up in composer update. Security patches wait too. That's the tradeoff. But zero-day injection risk drops.

The long-term plan is a two-step release flow: tag a release, get an MFA confirmation request. A stolen account alone wouldn't be enough to push a release.

Good progress. The ecosystem is large, though, and none of this ships overnight.

TL;DR

Standard practice:

Commit composer.lock. Always.
Run composer audit before and after updating.
Update specific packages when possible, not everything at once.
Question every new dependency. One class does not need a full package.
Composer 2.10 added Aikido malware scanning and stable version immutability.

Personal workflow additions:

Use jack raise-to-installed after every composer update to pin constraints to installed versions. Not standard practice — trades upgrade convenience for narrower exposure on future unexpected jumps. Does not protect against a malicious release you just pulled.
Verify no package jumped past your PHP version floor after each update.
Follow Laravel security researchers on social media. Incidents surface there before formal advisories.

Supply chain attacks are no longer a JavaScript-only problem. The Laravel-Lang incident showed that PHP ecosystems are not immune. The workflow above does not guarantee safety. But it reduces the surface you're exposed to on the next update.

References:

Author's Note

Thanks for sticking around!
Find me on dev.to, linkedin, or you can check out my work on github.

Laravel, after the happy path.

PHP Generics Already Exist: They're Just Hidden in PHPDoc

Ivan Mykhavko — Tue, 02 Jun 2026 11:26:00 +0000

Every Laravel dev has written PHP generics. You just wrote them inside a comment and pretended it didn't count.

/** @return Collection<CartItemDTO> */

That line is a generic type. PHPStan reads it, your IDE reads it, but PHP itself shrugs and ignores it. A new RFC, Bound-Erased Generic Types, wants to turn those comments into real syntax. Let's start with what a generic even is, then look at why PHP has fought this for a decade.

A 30-Second Theory Refresh

A generic is a type with a hole in it. Instead of writing IntBox, StringBox, and UserBox, you write Box<T> once and decide T later. The formal name is parametric polymorphism.

// Without generics: one class per type, copy-paste forever
final class IntBox { public function get(): int { /* ... */ } }

// With generics: one class, T decided at use site
final class Box<T> { public function get(): T { /* ... */ } }

The idea isn't new. Java, C#, and TypeScript all have it. PHP and JS skipped it for years, which is exactly why static analyzers grew up to fill the gap.

There are two ways to ship generics. Reified keeps the type at runtime, so Box<int> and Box<string> stay distinct (C#). Erased uses it only for static analysis and throws it away before execution (Java, TypeScript). This RFC picks erasure. Hold that thought.

Why It's So Hard to Add to PHP

Generics have been on the PHP internals agenda since January 2014. Multiple RFCs, multiple implementations, none merged. Why?

Runtime type checks are expensive. Reified generics mean PHP must store and verify type arguments on every instance. Nikita Popov built a prototype and hit superlinear type-checking cost and heavy per-instance memory. PHP is request-per-process, so you pay that on every request.
No shared spec. PHPStan, Psalm, Mago, and PhpStorm have spent years guessing at the same @template syntax, each a little differently. There's no official standard to follow, so an edge case that works in one tool can quietly break in another.
A decade of stalls. The 2016 reified RFC sat in draft for ten years. The 2024 reified continuation stalled on cross-file inference. Each attempt paid the syntax cost and shipped no syntax.

The Solution: Erase, Don't Reify

The RFC, by Seifeddine Gmati (author of the Mago analyzer), adds native syntax: class Box<T>, bounds <T : Animal>, defaults <K = string>, variance <+T> / <-T>, and an optional turbofish ::<…>.

The key word is bound-erased. At runtime Box<int> and Box<string> are the same class. The type argument is erased down to its bound (or mixed). Checking happens statically, like Java or TypeScript. Reified was rejected on purpose: as the RFC puts it, "we don't need runtime type checks." Generics are a static-analysis tool, not a runtime one.

So your comment becomes the signature, and old code keeps working. The turbofish is optional everywhere:

// Today: the type parameter lives in a doc block
/**
 * @template T
 */
interface Repository
{
    /** @return Collection<T> */
    public function all(): Collection;
}

// With the RFC: the same intent, but the language reads it
interface Repository<T>
{
    public function all(): Collection<T>;
}

It's Not New: Just Look at Your Own Code

I grepped a Laravel 10 project I work on (PHP 8.1, Larastan level 5). The result: 143 generic-PHPDoc annotations and 0 of my own @template. So the project consumes generics everywhere (mostly Collection<…>) but never declares them. Here's a real action from it:

final class CartIndexAction implements Actionable
{
    /** @return Collection<CartItemDTO> */
    public function handle(CartItemParamDTO $param, int $userId): Collection
    {
        return $this->cartItemService->getForUser($userId, $param->itemUuids)->values();
    }
}

The native return type is just Collection. The useful part, CartItemDTO, lives in a comment. Drop it and autocomplete dies and Larastan stops catching wrong-type bugs. It's worse in repositories, where you babysit the analyzer by hand:

public function getUserCarts(int $userId): EloquentCollection
{
    /** @var EloquentCollection<Cart> $carts */
    $carts = Cart::query()->where('user_id', $userId)->get();

    return $carts;
}

That /** @var */ exists only to feed the analyzer. And it's not just my code: Laravel itself ships generic annotations across its core classes and IDE-helper stubs. Every Collection and query Builder you touch is already generic in the doc blocks. The RFC authors counted 200k+ files on GitHub using @template. Adopting this RFC doesn't introduce generics. They've been here for a decade. It formalizes what's already there.

I Want This in 2026

Heads up: the RFC is still Under Discussion (v0.22), with an open php-src PR that works today. The blocker isn't the code. It's a small group on internals who don't love the erased approach.

We've babysat doc blocks and worked around analyzer quirks for years because generics are worth it. The implementation is ready, and the proposed syntax is already familiar to PHP developers using PHPStan and Psalm. PHP developers already write generics every day. The only question left is whether they keep living in comments, or finally become part of the language. I know which one I want in 2026.

TL;DR

A generic is a type with a hole: Box<T> instead of one class per type. Old idea (Java, C#, TS).
PHP generics already exist in @template / <…> PHPDoc your analyzer reads. 200k+ files on GitHub use them.
Adding them natively is hard: reified runtime checks are expensive, and ~6 analyzers disagree with no shared spec. On the agenda since 2014.
The RFC picks bound erasure: checked statically, erased at runtime, Box<int> ≡ Box<string>, zero runtime cost.
Existing code keeps working; the turbofish ::<…> remains optional.

💡 Watch Brent Roose's video walkthrough and read the RFC before the vote.

Author's Note

Thanks for sticking around!
Find me on dev.to, linkedin, or you can check out my work on github.

Laravel, after the happy path.

Reincarnating a Decade-Old jQuery Project

Ivan Mykhavko — Sun, 17 May 2026 15:57:47 +0000

Cleaning my old drive, I found burger.zip dated 2015. Inside: one of my first paid web gigs, a burger builder for a Swiss client.
Radial menu of ingredients, click one, it flies onto a bun, price ticks up in CHF. jQuery 1.7. I had to give it a second life.

Before (2015, jQuery)	After (2026, TS + GSAP)

What Happened

The original was 1244 lines across five files. jQuery, a 780-line radmenu plugin, hardcoded math, and this stack-height fix:

switch(i){
  case 0: hhh+=20; break;
  case 1: hhh+=5; break;
  case 2: hhh-=25; break;
  case 3: hhh-=20; break;
  case 4: hhh-=15; break;
  case 5: hhh-=12; break;
}
$('#burger_wrap').height($('#burger_wrap').height()+l*12+hhh);

Yes. Past me solved stack height with a hardcoded switch.

The code still worked. Three CDN scripts loaded over http://, which modern browsers now block.
One s made it bootable again. I committed that fix as legacy/, untouched otherwise.

Investigation

Then I rebuilt it next door at modern/. Vite for the build, TypeScript for safety, GSAP for the fly animation. Same UX: ingredients orbit the center, click flies them onto the bun, click in the stack removes them.

The radial picker took 50 lines of trig instead of a 780-line jQuery plugin:

const cx = container.clientWidth / 2;
const cy = container.clientHeight / 2;
const radius = Math.min(cx, cy) - 40;
const step = (Math.PI * 2) / els.length;

els.forEach((el, i) => {
  const a = offset + i * step - Math.PI / 2;
  const x = cx + Math.cos(a) * radius;
  const y = cy + Math.sin(a) * radius;
  el.style.transform = `translate(${x}px, ${y}px)`;
});

The stack-height switch became flex column with negative margin:

#stack { display: flex; flex-direction: column; }
#stack li { margin-top: -44px; }

Making It Feel Real

The first rebuild worked, but it felt flat. I ran three parallel agents: one on bun art, one on ingredients, one on motion.
Result: gradients and sesame seeds on the buns, grill marks on the beef, drip teardrops on the cheese.
Plus a quarter-turn tumble with motion blur on each fly-in, a squash on landing, and a slow idle jiggle once the stack hits three items.
CSS perspective + rotateX(8deg) tilts the burger toward the viewer.

Two things bit me.

GSAP overwrites CSS transforms. I centered the burger with transform: translateY(-50%). The first gsap.to(burgerEl, { y: 3 }) stomped that translate and the burger drifted off the page.
Fix: center without transform.

#burger {
  position: fixed;
  top: 0; bottom: 0;
  margin: auto 0;
  height: max-content;
}

Agents can polish away meaning. My bun-art agent rewrote down.svg with cleaner gradients and richer seeds.
It looked sharper. Flat. The original encoded a side-cut profile: dark crust on top, cream crumb in the middle, brown base. The rewrite lost it.
I reverted to the legacy SVG verbatim and kept the new top bun. The legacy SVG encoded something the polish lost, and no diff would have told me.

TL;DR

Archived the 2015 original verbatim under legacy/, rebuilt next door in TypeScript + GSAP
780-line jQuery.radmenu plugin replaced with ~50 lines of trig
Three parallel agents added bun gradients, ingredient detail, tumble + squash + idle jiggle
GSAP y tweens overwrite CSS transform: translateY(-50%) — center without transform
AI polish stripped the side-cut anatomy from the bottom-bun SVG; reverted to the 2015 hand-drawn art

👉 https://github.com/tegos/burger-reborn

Author's Note

Thanks for sticking around!
Find me on dev.to, linkedin, or you can check out my work on github.

Laravel, after the happy path.

Why telescope:clear Is Slow and How to Reclaim Disk in Seconds

Ivan Mykhavko — Wed, 29 Apr 2026 15:25:28 +0000

A while back I wrote about laravel-telescope-flusher - a tiny package I built to wipe Telescope data without waiting forever. It just hit 1,000 installs on Packagist 🎉, so it felt like the right time to actually back up the original post with real numbers, not just claims.

So I sat down, seeded a million Telescope entries on a fresh MySQL 8.0, and timed the three things you'd reach for: telescope:clear, telescope:prune, and telescope:flush. Spoiler: the gap is bigger than I expected.

Quick recap of why `telescope:clear` is slow

Two things kill it. First, the loop:

// vendor/laravel/telescope/src/Storage/DatabaseEntriesRepository.php
public function clear()
{
    do {
        $deleted = $this->table('telescope_entries')->take($this->chunkSize)->delete();
    } while ($deleted !== 0);
    // ...same for telescope_monitoring
}

$chunkSize = 1000. A million rows = a thousand round-trip DELETE statements, each writing to redo log, undo log, double-write buffer.

Second (and this one I missed in the original post): telescope_entries_tags has a foreign key on entry_uuid with ON DELETE CASCADE. With ~3 tags per entry, every parent delete triggers a cascade delete on the tag table. On a million entries, that's 3 million extra deletes the loop never asked for.

telescope:prune --hours=24 is the same loop with a WHERE filter. Same problem.

And `DELETE` doesn't give you the disk back

I missed this on the first pass. After telescope:clear finishes, information_schema.tables reports the data length as basically zero. Looks done. Then check the actual file:

ls -lah /var/lib/mysql/telescope_test/telescope_*.ibd

The .ibd files are still huge. InnoDB doesn't return space to the OS after DELETE - it only marks pages reusable for future inserts. To actually shrink the file you need OPTIMIZE TABLE (which rebuilds it) or ALTER TABLE ... ENGINE=InnoDB.

telescope:clear does neither. So your dev disk stays full.

The benchmark

Setup: MySQL 8.0 in Docker, default config. Seed: 1,000,000 telescope_entries (~2 KB JSON content each), 3,000,000 rows in telescope_entries_tags, real foreign key with cascade. Bench script lives in bench/ - go run it yourself.

Starting state, identical for both runs:

telescope_entries          rows=1000000   logical=2.33 GB   .ibd=2.4 GB
telescope_entries_tags     rows=3000000   logical=672 MB    .ibd=688 MB
telescope_monitoring       rows=50        logical=16 KB     .ibd=112 KB
TOTAL                      rows=4000050   logical=2.99 GB   .ibd=3.1 GB

Results:

Step	`telescope:clear`	`telescope:flush`
Wall time	9025 s (≈150 min)	1.21 s
Logical size after	128 KB	128 KB
`.ibd` files on disk after	3.1 GB (unchanged)	428 KB

That's roughly 7400× faster and 3 GB of disk you actually get back. Both runs leave info_schema reporting the same size, by the way. That's the trap. Only ls -lah on the .ibd files tells you the truth.

prune --hours=0 benches almost identically to clear (same loop, same FK cascade), so I didn't bother running it to completion. The shape of the result is the same.

What `flush` does differently

The package's whole command is short enough to paste:

DB::getSchemaBuilder()->withoutForeignKeyConstraints(function () {
    DB::table('telescope_entries')->truncate();
    DB::table('telescope_entries_tags')->truncate();
    DB::table('telescope_monitoring')->truncate();
});

if (DB::getDriverName() === 'mysql') {
    DB::statement('OPTIMIZE TABLE telescope_entries');
}

No magic. TRUNCATE is a metadata operation. Instant on InnoDB, no per-row work, no cascade. The withoutForeignKeyConstraints wrapper is needed because TRUNCATE doesn't fire cascades, so you have to disable the FK check yourself. OPTIMIZE TABLE rebuilds the table on innodb_file_per_table (the default for years) and produces a fresh, tiny .ibd.

There's also an App::isLocal() guard - TRUNCATE is irreversible, you really don't want to fat-finger this anywhere except dev.

When to use what

Approach	Use case
`telescope:clear`	Default local cleanup. Works, slow on big tables, leaves disk allocated.
`telescope:prune --hours=24`	Scheduled retention - keep last N hours. Same disk problem, but table size stays bounded over time.
`telescope:flush` (package)	Dev nuke. Telescope ballooned, you want it gone in a second and the disk back.

I don't run Telescope in production, neither should you, so the local-only guard isn't a limitation.

TL;DR

telescope:clear = chunked DELETE LIMIT 1000 + cascading FK on tags. On 1M entries: 2.5 hours.
InnoDB doesn't shrink the .ibd after DELETE. info_schema lies, ls -lah doesn't.
telescope:flush = TRUNCATE + OPTIMIZE TABLE. 1.21 s on the same data, 3 GB → 428 KB on disk.
If your info_schema says the table is empty but df disagrees, it's the InnoDB pages, not your imagination.

Resources

Author's Note

Thanks for sticking around!
Find me on dev.to, linkedin, or you can check out my work on github.

Notes from real-world Laravel.

Laravel whereDate() Silently Kills Your Index

Ivan Mykhavko — Thu, 23 Apr 2026 14:36:27 +0000

whereDate('created_at', $date) looks clean, but on a big table it quietly drops your index and does a full scan.

The Problem

Say you want notifications created on a specific day. The obvious call:

UserNotification::query()
    ->whereDate('created_at', '2026-04-23')
    ->get();

Laravel generates this SQL:

SELECT * FROM user_notifications
WHERE DATE(created_at) = '2026-04-23'

See DATE(created_at)? MySQL has to compute that function for every row before comparing. Your created_at index is useless, EXPLAIN shows a full table scan:

+----+-------------+--------------------+------+---------+
| id | select_type | table              | type | rows    |
+----+-------------+--------------------+------+---------+
|  1 | SIMPLE      | user_notifications | ALL  | 5000000 |
+----+-------------+--------------------+------+---------+

On 5k rows you won't notice. On 5M rows you will.

The Solution

Compare the column directly against a range:

use Illuminate\Support\Facades\Date;

$start = Date::parse('2026-04-23')->startOfDay();
$end = $start->copy()->addDay();

UserNotification::query()
    ->where('created_at', '>=', $start)
    ->where('created_at', '<', $end)
    ->get();

Now the SQL looks like this:

SELECT * FROM user_notifications
WHERE created_at >= '2026-04-23 00:00:00'
  AND created_at <  '2026-04-24 00:00:00'

The column is untouched. MySQL can do a clean range scan on the created_at index:

+----+-------------+--------------------+-------+------+
| id | select_type | table              | type  | rows |
+----+-------------+--------------------+-------+------+
|  1 | SIMPLE      | user_notifications | range | 1200 |
+----+-------------+--------------------+-------+------+

Half-open range (>= start, < next day) is the safer form - endOfDay() ends at 23:59:59.999999, and comparing against 23:59:59 can quietly miss the last second.

Why It Works

This is called sargability - "Search ARGument ABLE". A predicate is sargable when the column appears as-is, without a function wrapping it. The moment you write DATE(col), YEAR(col), or LOWER(col), the optimizer can't use a standard B-tree index on col anymore.

The same trap applies to whereDay(), whereMonth(), whereYear(), and whereTime() all of them wrap the column in a MySQL function. Fine on small lookup tables. Painful on any growing log-style table.

Heads up: PostgreSQL lets you build a functional index (CREATE INDEX ON t ((date(created_at)))), so there whereDate() can still hit an index. MySQL has no real equivalent for this case, generated columns with an index work, but they're extra schema baggage for something a range filter already solves.

Tutorials love whereDate('created_at', today()). I still prefer the range form. It reads the same everywhere, and I never have to wonder whether an index will be used.

TL;DR

whereDate() is convenient but non-sargable on large tables it forces a full scan. Compare created_at against a half-open >= startOfDay() / < startOfDay() + 1 day range and keep the index in play.

💡 Same story for whereMonth(), whereYear(), whereDay(), whereTime(). If the column is wrapped in a function, assume the index is gone.

Author's Note

Thanks for sticking around!
Find me on dev.to, linkedin, or you can check out my work on github.

Notes from real-world Laravel.