The generate.php in this PR is really a quick and dirty implementation of a generator and it should not be looked too closely: the final implementation would be re-done almost entirely (though the idea would be kept).

What I want to suggest you for discussion is the Webmozart\Assert\Extra class.

In the final implementation I suggest to rename the currently existing Webmozart\Assert\Assert to Webmozart\Assert\Base, and then Webmozart\Assert\Extra to Webmozart\Assert\Assert so that it was all transparent for the users.

The final implementation would come with a test that checks that the currently generated version and committed version is identical to the one that would have been generated now should you run php generate.php.

The current implementation generates 47 functions out of the list of all allX or nullOrX functions, and 9 are not supported probably due to possible psalm bugs (need investigation). You can see list of those in the $temporaryUnsupported variable.

Thoughts?

/cc @Ocramius

hey there!

I was thinking about the simplest way to assert exceptions are thrown and thought it was currently missing.

Do you think it's a viable solution? If so, I'll add some tests.

current usage:

Assert::throws(function() {
    $this->products->findOrThrow('some-id'), new \LogicException);
}, \LogicException::class);

It will only check the exception type right now, not comparing the message.

Related:

• [x] https://github.com/vimeo/psalm/issues/2449
• [x] https://github.com/vimeo/psalm/issues/2450
• [x] https://github.com/vimeo/psalm/issues/2451
• [x] https://github.com/vimeo/psalm/issues/2452
• [x] https://github.com/vimeo/psalm/issues/2456

Fixes #213

Needs:

• [x] https://github.com/vimeo/psalm/pull/5050 (and update vimeo/psalm conflict)
• [x] ~~https://github.com/vimeo/psalm/issues/5051~~ worked around by removing @mixin
• [x] ~~https://github.com/vimeo/psalm/issues/5052~~ (skipped - suppressed for now, IMO not a blocker)
• [x] ~~https://github.com/vimeo/psalm/issues/5310~~ (not fixed - reported regression in upstream, then locked dependency here)
• [x] upgrade vimeo/psalm, update vimeo/psalm conflict constraint

Fixes #213 Fixes #214 Fixes #97 Fixes #229

Given now https://github.com/webmozarts/assert/commit/1838a0fb31b481772481fc7e300e587d3380ac56 only php>=7.2 is supported, how about switching to native type hints for arguments and return values where possible?

As discussed with @Nyholm, this is a WIP patch containing happy-path scenarios (some of which are marked as .disabled, will talk to @muglug about those) that ensure the added type declarations work as expected.

The idea is that after a @psalm-assert int $value, the caller of Assert::integer($value) can assume $value to be int.

This is equivalent to the behavior of https://github.com/phpstan/phpstan-webmozart-assert, but the declarations are now closer to the source, and that makes for easier usage from the ecosystem (support by phpstan and phpstorm may come soon ;-) )

As for the prefixed annotation format: that is required to not trip over tools like doctrine/annotations.

Other similar patches, for reference (since this is quite new stuff):

• https://github.com/doctrine/collections/pull/177
• https://github.com/Ocramius/ProxyManager/pull/465
• https://github.com/sebastianbergmann/phpunit/pull/3708

Currently, when one is used to assertions in PHPUnit (first argument "expected", second "actual"), it's easy to get the assertions in this library wrong (first argument "actual", second "expected"). What do you think about flipping the arguments and releasing a 2.0?

Hi,

I'm looking for a way to raise custom exceptions per assertion.. Looking at the code, it currently seems only possible to override Assert::reportInvalidArgument for all assertions.. The only way I see around this is to add an optional argument to every assertion, allowing to pass a custom exception class.. Would you be open for a PR to support this? Or do you see another way to achieve what I'm after?

All PHP versions < 7.2 are end of life and should no longer be used. It is harmful to support these outdated versions in the future.

Why?

• PHPUnit cannot be upgraded to 8 and above
• Newer language features cannot be adopted resulting in bloated or less readable code
• Users should not be encouraged to build technical debt

Hi !

Further extending of #19 to allow report a problem in different ways via extending the class, while default behaviour is not changed.

Use case - I have a library used with a lot of messy, invalid input from it's users that needs to be fixed by the users of library. When I do the assertions that raising the exceptions - it will crash their app. So far even if their input is not perfect, it works somehow (not in the best way, but at least some functionality is working due to autoconverting).

The goal is to be strict and raise an exception when user of lib will pass invalid input. But as a middle step I want to make extra release which will just warn him (like triggering a warning instead of breaking the flow with exception). Currently one can't override the library to do anything else than raising an exception. With this change it would become possible.

What do you think @webmozart ?

I would like to do something like that:

Assert::allKeyPathsExists($collection, [
    'page',
    'pages',
    'total',
    'limit',
    '_embedded.items',
    '_links.self',
    '_links.first',
    '_links.last'
]);

// or 
Assert::keyPathExists($collection, '_links.last.href');

Currently I have something like that:

use Webmozart\Assert\Assert as BaseAssert;

/**
 * Class Assert
 * @package AppBundle\Test
 */
class Assert extends BaseAssert
{
    /**
     * @param array $value
     * @param string $keyPath
     * @param string|null $message
     * @throws
     */
    public static function keyPathExists($value, $keyPath, $message = null)
    {
        $pointer  =& $value;
        $keys     = explode('.', $keyPath);
        $position = [];
        $message  = $message ?: 'expected key-path "%s" to exist. Failed at position "%2$s".';

        foreach ($keys as $key) {
            $position[] = $key;
            static::keyExists($pointer, $key, sprintf($message, $keyPath, implode('.', $position)));
            $pointer =& $pointer[$key];
        }
    }

    /**
     * @param array $value
     * @param array $keyPaths
     * @param string|null $message
     */
    public static function allKeyPathsExists($value, array $keyPaths, $message = null)
    {
        foreach ($keyPaths as $keyPath) {
            static::keyPathExists($value, $keyPath, $message);
        }
    }
}

Which works. I did also a different implementation using __callStatic and adding a prefix apply which could take a subject (value) and apply an assertion with different sets of arguments (and if needed messages).

I'v noticed, what I actually need is the possibilities to also apply such path tests to type-checks like integer or string.

So actually what is needed is some sort of __callStatic to operate over a path of array-keys or object-properties. Without that writing assertions pains. The example above delivered understandable error messages and the customization concept in this project is good, so I think you would not get some super generic (not understandable) messages, if scaled the way I did in the example.

The API could looks like this:

// 1. array subject of test, 2. array keyPaths to test, 3-n. assertion-arguments
Assert::arrayEveryKeyExists(array $subject, array $subjectKeyPaths)
Assert::arrayEveryInteger(array $subject, array $subjectKeyPaths);
Assert::arrayEveryIsInstance(array $subject, array $subjectKeyPaths, SomeClass::class);
// or Assert::arrayAllKeyExists, Assert::arrayAllInteger but the readability is worker here.

In tests/static-analysis/assert-isAOf.php there is the following mehod:

function allIsAOf($value)
{
    Assert::allIsAOf($value, Serializable::class);

    return $value;
}

however no such method exists in the Assert class.

I've faced the fact that it is required to create temporary variables to validate values:

$firstName = getParam('firstName');
$lastName = getParam('lastName');
Assert::notNull($firstName);
Assert::notNull($lastName);

createCustomer(
    $firstName,
    $lastName
);

We can rid of temporary variables if the assertion function returns a valid value:

createCustomer(
    Assert::notNull(getParam('firstName')),
    Assert::notNull(getParam('lastName'))
);

For some of the assertion functions, we can simply return the valid value. The changes should be BC-safe.

Possible implementation: https://github.com/webmozarts/assert/pull/281 Psalm support demonstration: https://psalm.dev/r/c3a23fe473

References:

1. Similar Java implementation: https://commons.apache.org/proper/commons-lang/javadocs/api-3.1/org/apache/commons/lang3/Validate.html#notNull(T)

This PR fixes #275, the first commit upgrades pslam so that psalm can be run from a subdirectory again. And the second commit fixes all currently occurring errors.

class_implements accepts either an object or a class-string, but the PHPDoc for the assert function is wrong and limits its functionality to a class-string only. I'm not entirely sure if this was on purpose, the README just mentions "Check that a class implements an interface", but it would work with either an instance of a class or a class-string and the assertion is under the "object" category.

See also https://phpstan.org/r/c72bb8af-4f27-462b-85f6-e2d3b81b9786 where this is tested in PHPStan (which just got support for PHPDoc-based type narrowing, this is not released yet)

Refs: https://github.com/phpstan/phpstan-webmozart-assert/pull/144#issuecomment-1268122389

I could not cleanly run psalm locally without unrelated errors, let's see what happens on CI 🤞