psalm-psr-container-plugin
psalm-psr-container-plugin copied to clipboard
Is this package equivalent to a Psalm stub?
See https://github.com/laminas/laminas-inputfilter/blob/11080cf5a67fd2368d31b50e28403fb21cbf2f14/.stub.php
Copying it here for reference:
<?php
declare(strict_types=1);
namespace Psr\Container {
interface ContainerInterface
{
/** @param string|class-string $name */
public function has(string $name): bool;
/**
* @template T of object
* @psalm-param string|class-string<T> $name
* @psalm-return ($name is class-string ? T : mixed)
*/
public function get(string $name): object;
}
}
Usage:
<?php
class Thing {
public function doStuff(): void
{
}
}
/** @psalm-var ContainerInterface $container */
$value = $container->get(Thing::class);
$value->doStuff();
See https://psalm.dev/r/027e9ad09e
Is this package comparable to that? What differences does it bring to that approach, and is a stub sufficient?
Ref: https://github.com/laminas/laminas-inputfilter/pull/53#discussion_r891112567
I think it should be comparable. Best way to be sure is to replace the checker by your stub and run the integration suite :)
Heh, we just introduced it, so no difference: this is mostly to understand if such a stub makes the plugin superfluous :D
Maybe one difference I see is that the checker is able to check for plain string. But I don't think that you'll care about it.
One drawback to using a stub is that PHPStorm picks it up and marks everywhere you use a ContainerInterface with a multiple implementation warning, not only in the library hosting the stub, but also anywhere you install the library as a dependency.
Instead of .stub.php, call it .php.stub and you are good ;-)
Good idea! Or export-ignore it in .gitattributes