DEV Community: wadakatu

Lumen (Laravel) v10 to v11: Contextual Binding Changes and Solutions.

wadakatu — Mon, 14 Apr 2025 02:06:10 +0000

Introduction

When upgrading from Lumen v10 to v11, have you ever been confused by unexpected behavior?

I encountered this issue myself when the changes to Contextual Binding caused previously functional code to stop working.

In this article, I will explain the changes to Contextual Binding with detailed sample code. We’ll look at how it worked in v10, the issues that arise in v11, and how to fix them step by step.

Reference: If you’d like to learn more about the basics of Contextual Binding, please refer to the official Laravel documentation.

Background of the Changes

【Key Changes】

Lumen v10: `when` method-based Contextual Binding applied across the entire DI chain (including indirect dependencies).

Lumen v11: `when` method-based Contextual Binding applies only when directly injected into the specified class.

In Lumen v10, the when method allowed Contextual Binding to propagate across the entire dependency injection (DI) chain.

In other words, a concrete class specified for one class's dependency was also reflected in subsequent layers of the DI chain.

However, as of v11, this behavior has changed. The when method now applies only to cases where the specified class is directly injected.

As a result, code that previously worked might stop functioning as intended.

Dependency Diagram

Here’s a diagram showing the dependencies discussed in this article:

Behavior in v10:
CreditController ──depends→ MoneyService ──depends→ PaymentInterface
     │                                                 ↑
     └────────────when().needs()───────────────────────┘
     (The PaymentInterface binding is correctly applied from CreditController)

Behavior in v11:
CreditController ──depends→ MoneyService ──depends→ PaymentInterface
     │                       │                         ↑
     └─when().needs()─╳      └─when().needs()──────────┘
     (The binding only applies to direct dependencies)

Let’s explore specific cases where this issue arises, along with code examples.

Example Code in v10

First, let’s look at example code that worked correctly in Lumen v10.

Configuration in AppServiceProvider

$this->app->bind(PaymentInterface::class, function ($app) {
    return new class implements PaymentInterface {
        public function paymentMethod(): string
        {
            return 'default';
        }
    };
});

$this->app
    ->when(CreditController::class)
    ->needs(PaymentInterface::class)
    ->give(function () {
        return new class implements PaymentInterface {
            public function paymentMethod(): string
            {
                return 'credit card';
            }
        };
    });

Here, PaymentInterface is configured to switch its concrete class based on CreditController.

CreditController

class CreditController extends Controller
{
    public function __construct(private MoneyService $moneyService)
    {
    }

    public function index(): string
    {
        return $this->moneyService->paymentMethod();
    }
}

CreditController injects MoneyService, which internally calls the paymentMethod of PaymentInterface.

MoneyService

class MoneyService
{
    public function __construct(private PaymentInterface $paymentInterface)
    {
    }

    public function paymentMethod(): string
    {
        return $this->paymentInterface->paymentMethod();
    }
}

MoneyService is a class that depends on PaymentInterface.

Execution Result

When this code is executed in Lumen v10, calling the index method of CreditController correctly returns 'credit card'.

Issues in v11

What happens if we run the same code in Lumen v11?

Cause of the Issue

CreditController injects MoneyService, which in turn injects PaymentInterface.

However, in v11, the when method applies only when directly injecting into the specified class. Therefore, even though CreditController is the basis of the configuration, the PaymentInterface passed to MoneyService remains the default, and 'default' is returned.

Execution Result

Calling CreditController returns 'default' instead of the expected 'credit card'.

Example of a Failing Test

No explicit error message appears, but the return value differs from expectations. For example, the following test will fail:

// Test code
public function testCreditControllerReturnsCorrectPaymentMethod()
{
    $response = $this->get('/credit');
    $this->assertEquals('credit card', $response->getContent());
    // Fails in v11 - 'default' is returned
}

In real-world environments, this discrepancy can cause features to break, requiring time-consuming debugging.

Fixed Code Example (v11-Compatible)

How can we make this code work correctly in Lumen v11?

The fix is simple: change the basis of the when method to MoneyService.

Configuration in AppServiceProvider

$this->app->bind(PaymentInterface::class, function ($app) {
    return new class implements PaymentInterface {
        public function paymentMethod(): string
        {
            return 'default';
        }
    };
});

$this->app
    ->when(CreditController::class) 
    ->needs(MoneyService::class)
    ->give(function () {
        $creditCardInterface = new class implements PaymentInterface {
            public function paymentMethod(): string
            {
                return 'credit card';
            }
        };
        return new MoneyService($creditCardInterface);
    });

Key Fix

`needs(PaymentInterface::class)` → `needs(MoneyService::class)`

Consider the DI chain, and specify the class that directly requires the interface.

The key here is changing the basis of the needs method from PaymentInterface to MoneyService.

This ensures that the correctly configured PaymentInterface is injected into MoneyService.

CreditController

class CreditController extends Controller
{
    public function __construct(private MoneyService $moneyService)
    {
    }

    public function index(): string
    {
        return $this->moneyService->paymentMethod();
    }
}

MoneyService

class MoneyService
{
    public function __construct(private PaymentInterface $paymentInterface)
    {
    }

    public function paymentMethod(): string
    {
        return $this->paymentInterface->paymentMethod();
    }
}

Execution Result

With this fixed code, calling the index method of CreditController correctly returns 'credit card'.

Conclusion

In summary, Lumen v11 enforces stricter scoping for Contextual Binding.

As a result, when using the when method, you need to carefully specify the correct class within the DI chain.

If you’ve encountered this behavior during an upgrade, please share your experience in the comments! If you know of alternative solutions or related documentation, feel free to share those as well :)

References

How to Handle Excessive Warning Messages When Running `pecl install grpc`

wadakatu — Wed, 25 Dec 2024 17:42:14 +0000

Overwhelming Warning Messages Can Be a Nuisance

When running pecl install grpc, you might encounter an avalanche of warning messages like these:

#7 67.72 /tmp/pear/temp/grpc/src/core/lib/promise/detail/promise_factory.h:174:5: warning: 'always_inline' function might not be inlinable [-Wattributes]

#7 352.5 /tmp/pear/temp/grpc/src/core/lib/event_engine/forkable.h:61:34: warning: 'unused' attribute ignored [-Wattributes]

There can be hundreds of these warnings, flooding your logs. This has been especially problematic during deployment, where CI/CD pipelines would exceed log limits, causing errors and halting the process.

The Root Cause

Searching for the warning messages online points to GCC, the GNU Compiler Collection.

It turns out these warnings are generated by the compiler when building gRPC's source code. Since the warnings originate from gRPC’s source code, it’s not feasible for users to fix the source code directly to suppress the warnings.

The Solution

Fortunately, GCC provides several options to suppress warning messages, which you can pass to the compiler during the build process:

Warning Options in GCC Documentation

However, there’s no straightforward way to pass these options directly when running pecl install grpc. If you know of one, please let me know—I’ll celebrate with tears of joy! 🥹

So, what now?

The answer came to me from a StackOverflow thread: Instead of letting pecl install handle everything, you can break the process into smaller steps and pass the options during the compilation phase.

Reference: StackOverflow

Since gRPC is written in C++, we can use environment variables like CFLAGS and CXXFLAGS to specify options that suppress the warnings during compilation:

Gentoo Wiki on GCC Optimization

Implementation

Let’s assume gRPC is being installed in a Dockerfile.

Before

RUN pecl install grpc

After

RUN pecl download grpc \
  && tar xzf $(ls grpc-*.tgz | head -n 1) \
  && cd $(ls -d grpc-*/ | head -n 1) \
  && phpize \
  && ./configure --with-php-config=/usr/local/bin/php-config \
  && make -e CFLAGS="-Wno-attributes -Wno-unused-parameter -Wno-deprecated-declarations -Wno-return-type" CXXFLAGS="-Wno-attributes -Wno-unused-parameter -Wno-deprecated-declarations -Wno-return-type" \
  && make install

The after commands mimic what pecl install does internally, but with more control. Breaking down the process revealed just how much pecl install handles behind the scenes—impressive!

The warnings appeared during the make phase, so I passed the suppression options via the CFLAGS and CXXFLAGS environment variables:

make -e CFLAGS="-Wno-attributes -Wno-unused-parameter -Wno-deprecated-declarations -Wno-return-type" CXXFLAGS="-Wno-attributes -Wno-unused-parameter -Wno-deprecated-declarations -Wno-return-type"

How to Identify Suppression Options

To determine which suppression options to use, look at the end of the warning messages. You’ll often see hints like [-Wattributes] or [-Wunused-parameter]. Add no to the beginning of these, e.g., -Wno-attributes or -Wno-unused-parameter, to suppress them.

For more details, refer to the official documentation:

Warning Options in GCC Documentation

Conclusion

With this approach, I successfully escaped the swamp of gRPC warning messages. However, this didn’t fully resolve the CI/CD log limit issue, which I’ll address in a future post.

If this article helps even one person escape the gRPC warning message swamp, I’ll be delighted! 🙌

Laravel 9, NO LTS Support!?

wadakatu — Tue, 22 Feb 2022 15:36:00 +0000

Latest LTS finally!!

Laravel 9 was finally released on February 22nd, 2022.

At first, we are thrilled with LTS (Long Term Support) of Laravel 9.

However, Mr.Otwell (The author of Laravel) decided to postpone the LTS.

Why Postponed?

You can find out the reason why the LTS is postponed on Mr.Otwell Tweet.

In short, a pull request on Symfony Repository causes the postponement of the LTS.

LTS Again?

The answer is "Maybe or Maybe not".

In my opinion, if the PR were rejected, There would be high probability that the LTS comes back.

What do you think about it?
Feel free to leave your thought on discussion.

Update! PHP 8.1 needed from Symfony 6.1

The PR was merged yesterday on Symfony.

Therefore, PHP 8.1 will be the minimum requirement for Symfony 6.1.

Read this article for more information.
https://symfony.com/blog/symfony-6-1-will-require-php-8-1

In Laravel, they have already merged a PR which changes the minimum PHP Version From 8.0 to 8.1 for Laravel 10.

[Laravel 8.x] Refactor Factory Call with One Command

wadakatu — Thu, 03 Feb 2022 11:01:03 +0000

Factory call changed

In Laravel 8.x, the style of factory call was changed from helper to static method.

//Laravel 7.x or earlier
factory(User::class)->make()

//Laravel 8.x
User::factory()->make()

It takes plenty of times to fetch this change into your application if you do by yourself.

Don't worry. I made a package to refactor all of them with Just One Command.

Laravel-Factory-Refactor

https://packagist.org/packages/wadakatu/laravel-factory-refactor

This package will help you to refactor the style of factory call from helper to static method for Laravel 8.x.

How to Use

1. Installation

You can install the package via composer:

composer require wadakatu/laravel-factory-refactor --dev

2. Run Artisan Command

php artisan refactor:factory

3. Voila, Refactor Completed !

//Before
factory(User::class)->make();
factory(App\Models\User::class)->make();
factory(User::class, 10)->make();
factory(App\Models\User::class, 10)->make();

//After
User::factory()->make();
App\Models\User::factory()->make();
User::factory()->count(10)->make();
App\Models\User::factory()->count(10)->make();

In conclusion

'Laravel-Factory-Refactor' is my first package ever in my life.

From now on, I am going to do my best to update this package to make it better.
I hope you are going to like it.

Moreover, I am looking forward to getting stars in Github⭐️

https://github.com/wadakatu/laravel-factory-refactor

Thank you.