Parse_url does not support relative urls.

Caution
This function may not give correct results for relative or invalid URLs, and the results may not even match common behavior of HTTP clients. If URLs from untrusted input need to be parsed, extra validation is required, e.g. by using filter_var() with the FILTER_VALIDATE_URL filter.

Yes, I can see that being a problem. I'll check on it some time.

Can I run the static analysis locally? Could only find PHPUnit as a dependency.

Yes, just get phpstan. For example using phive.

I'm not quite sure how a relative URL would apply to the use cases of the \Codeception\Util\Uri metods?

Don't force push please. It makes reviewing harder!

I'm not quite sure how a relative URL would apply to the use cases of the \Codeception\Util\Uri metods?

From the webdriver module:

private function filterNodesByHref(string $url, array $nodes): array
    {
        //current uri can be relative, merging it with configured base url gives absolute url
        $absoluteCurrentUrl = Uri::mergeUrls($this->_getUrl(), $this->_getCurrentUri());
        $expectedUrl = Uri::mergeUrls($absoluteCurrentUrl, $url);
        return array_filter(
            $nodes,
            function (WebDriverElement $e) use ($expectedUrl, $absoluteCurrentUrl): bool {
                $elementHref = Uri::mergeUrls($absoluteCurrentUrl, $e->getAttribute('href') ?? '');
                return $elementHref === $expectedUrl;
            }
        );
    }

Thank you! I've checked the use-cases from the webdriver snippet and those seem to be covered by the unit tests.

The comment for $absoluteCurrentUrl tells that the "current uri" might be relative, it goes in the 2nd argument to mergeUrls(), which was never parsed by Guzzle code anyway.

But I must say, I'm very new to Codeception and it's highly possible I'm missing some very important context. Either way, I'm leaning towards using the PHAR version of Codeception instead.