Providing intellisense when resolving via the container

[nadinengland]

Often I find myself writing the following in order to get type information in my editor:

public function method()
{
    $service = app(App\Services\Service::class);
    // $service is mixed

    /** @var \App\Services\Service */
    $service = app(App\Services\Service::class);
    // $service is \App\Services\Service
    ...
}

Obviously, ideally I use Laravel's normal convention of dependency inject using PHP argument types to make this easier, like the container resolving during method calls (e.g. a handle() method a job, or a controller action etc.) but sometimes, I just call app(...) so I've found myself adding this helper (simplified for brevity):

/**
 * @template T
 * @param class-string<T> $abstract
 * @return T
function make($abstract) {
    return app($abstract);
}

...

public function method()
{
    $service = make(App\Services\Service::class);
    // $service is \App\Services\Service
    ...
}

What's stopped us changing \Illuminate\Container\Container::make() from adding PHPDoc @template T to support this behaviour?

My guess might be conformance with the Psr contract?

[sanfair]

The app() helper provides more than just class name binding.

Spoiler

framework/src/Illuminate/Foundation/helpers.php

Lines 108 to 124 in 07e12d3

	if (! function_exists('app')) {
	/**
	* Get the available container instance.
	*
	* @param string|null $abstract
	* @param array $parameters
	* @return \Illuminate\Contracts\Foundation\Application|\Illuminate\Foundation\Application|mixed
	*/
	function app($abstract = null, array $parameters = [])
	{
	if (is_null($abstract)) {
	return Container::getInstance();
	}
	return Container::getInstance()->make($abstract, $parameters);
	}
	}

In PHPStan, you can have conditional return types that infer the correct type based on input types.
I am unsure, but a similar thing exists in the Psalm. (conditional types)

You can also pass the registered alias as a parameter for the abstract. For example, check the code for the config() helper:

Spoiler

framework/src/Illuminate/Foundation/helpers.php

Lines 266 to 277 in 07e12d3

	function config($key = null, $default = null)
	{
	if (is_null($key)) {
	return app('config');
	}
	if (is_array($key)) {
	return app('config')->set($key);
	}
	return app('config')->get($key, $default);
	}

I don't think there is a way to type the app() helper for named services and have a correct return type for them.

If you're just looking to enhance intellisense for your IDE, you can check existing community solutions.
There is a way to generate meta files that, for example, PHPStorm can understand. There might be similar solutions for other IDEs.
This will return the correct type even when you access the service by alias.

Regarding the @template annotation.
This annotation came from static analyzers to provide support for generics in PHP. It is not part of PSR-19, which is commonly used for phpDoc, even if it is still in a draft status.
I think that, at the moment, the laravel/framework does not use any kind of syntax to improve code for static analyzers of any kind.
But there is a larastan/larastan extension for PHPStan that is maintained by Can Vural, Nuno Maduro, and Viktor Szépe.

[nadinengland]

@sanfair really appreciate the answer, and makes total sense - I wasn't aware @template was not core PHPDoc syntax.

I'm happy to keep this little function in my projects for my needs. I'm not really looking full static analytics just better intellisense in my IDE, but thank you for the suggestions of larastan 👍

[nadinengland]

Just following up on this as I stumbled across usage of @template quite heavily in the Laravel codebase. I should have checked in the first instance!

Specifically, laravel/framework v10.48.10 has about 160ish references to it that I can see. v11 still uses it too: https://github.com/laravel/framework/blob/11.x/src/Illuminate/Support/helpers.php#L498

I still believe the core answer given that my use case is only a fraction of app() scope is understandable. But clearly laravel is supporting this feature, so a make method could be handy.

Hope this helps others who stumble across this.

[henzeb]

There is the 'resolve' helper function ...