-
-
Notifications
You must be signed in to change notification settings - Fork 401
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: add new view-string type #654
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi,
Thank you! This sounds interesting. Although it adds more dynamic analysis to the codebase, which I don't quite like, it's ok I guess.
About the name of the new type. What about view-string
? It's clear that it represents a view in a string form. Just a suggestion.
Unrelated question: Why didn't StyleCI send a PR to fix the issues? 🤔 |
Thank you! LGTM! Error in Travis seems unrelated to this. I'll fix that later. |
@Daanra Example:
Output:
Did I miss something? |
Your code would work on lower levels of PHPStan, but on the maximum level it will throw an error because it's not 100% sure that it's a This should work: public function renderView(string $view): View
{
/** @phpstan-var view-string $bladeView */
$bladeView = 'pages.' . $view;
return view($bladeView);
} |
It works. Thanks |
This feature saved me a lot of time today. Thanks! |
@Daanra I think this is an awesome feature. However, the error message is very cryptic. It took me half an hour to figure out why I get this message in the first place.
It turns out that I renamed by the view and that's why I get this error, so that is good. However, the error doesn't describe that the view is not found. Why don't we show a message like |
@bobbybouwmann I agree with you that the error message is not clear at all. The error message is generated by PHPStan's own type checking rules and it's not trivial to alter this message. It's an unfortunate downside to using custom Types in such a scenario. An alternative would be to define our own rules to perform the type checking (similar to #673), this would give us complete control over the error message, but requires quite a bit of implementation work. |
I agree with you too! |
Maybe adding it to the no-one-reads-docs will not help :) |
@Daanra Maybe renaming the type would already help. Something like |
That is a really bad idea. PHPStan is not the most user-friendly product, a bit esoteric. |
But @phpstan is my favorite software! |
Changes
This merge request introduces a new custom type to Larastan:
blade-view
.A
blade-view
is any string that passes theview()->exists($string)
test. I have updated the stubs to use this new type as well, such that one can no longer run into errors when trying to render a view that does not exist.I'm not quite happy with the
blade-view
name. A CSS file will also pass theview()->exists()
test, so I think the 'blade-' part is a bit misleading. However, simplyview
seems a bit ambiguous. I'm not sure what the best name for it is.EDIT: Renamed
blade-view
toview-string
.