We should have more tests.
https://github.com/nunomaduro/larastan/blob/master/tests/Type/data/view-exists.php

So, are you saying it isn't working as expected?

Larastan checks view calls with 1 string only.
https://github.com/nunomaduro/larastan/blob/11bdd132565d37e808e4ac985a580b492c2d8887/src/Types/ViewStringType.php#L31-L36

Could you try with return view('this-view-does-not-exist');?

I do not understand how it works. I'm just a janitor 🧹

Could you try with return view('this-view-does-not-exist');?

Same result 😕

While working on my implementation on route-name-string in #1734, I ran into a similar problem when trying to re-use the same logic as implemented by the ViewStringType.

In ViewStringType.php only the accepts method is overriden. The acceptsWithReason method which seems to be the 'new' way of implementing custom types is still using the implementation from StringType, which contains the following statement:

        public function acceptsWithReason(Type $type, bool $strictTypes): AcceptsResult
	{
		if ($type instanceof self) {
			return AcceptsResult::createYes();
		}

		// ...

Components such as the RuleLevelHelper, which is e.g. used to check whether the argument type of a function call is accepted by the parameter type, only call acceptsWithReason. Therefore when checking if the string argument passed to view('non-existing-view'), ViewStringType::acceptsWithReason is called, which delegates to StringType::acceptsWithReason. Since the argument to view is a string, the check $type instanceof self yields true, so now every string is also accepted by parameters declared as view-string, leading to the problems described in this issue.

A possible solution is to implement the logic that currently lives in ViewString::accepts in a new overridden ViewString::acceptsWithReason, moving all TrinaryLogic to AcceptanceResult and delegate ViewString::accepts to ViewString::acceptsWithReason()->result, similar to how it is done in StringType::accepts.

I believe this was fixed in newer releases. Thank you!