CI is red on main: larastan 3.12.2 rejects the package's own view names as not view-string

[wit3]

What happens

composer test:types fails on main at ca2a86c, with no change to the source, in all ten places the package renders one of its own views:

 ------ ---------------------------------------------------------------------
  Line   Filament/Widgets/FindingsList.php
  40     Parameter #1 $view of static method Illuminate\View\Factory::make()
         expects view-string, string given.
 ------ ---------------------------------------------------------------------

The same ten, in Filament/Widgets/{FindingsList,HealthTimeline,RunningVacuums}.php and Http/Controllers/{Console,Dashboard,History,Internals,Learn,Lesson,Table}Controller.php. [ERROR] Found 10 errors, exit 1 — which takes down the six postgres: 17 legs of the Tests workflow, the ones that run the full gate. The three SQL-only legs (PG 14/15/16) stay green, so the failure reads as if it were about one of those versions.

Why now

Nothing in the repository changed. larastan/larastan resolves to 3.12.2, published after the last green run on main (2026-09-09), and the CI installs dependencies unlocked. Its tightened view-string requires the argument to name a view the analyser can resolve, and a package's views are registered under the vacuum:: namespace at runtime by VacuumServiceProvider, so a literal like 'vacuum::dashboard' cannot be resolved statically and stays a plain string.

Reproducing

git checkout main && composer update && composer test:types

Note

I ran into this on #26, where it is the only thing red — I mention it there too so the two are not confused. That PR's own change is one line in IndexResource plus a test, neither of which this touches.

I have not sent a fix because the right one is a judgement call that is yours: teaching larastan where the package's views live, or ignoring the pattern in phpstan.neon.dist, or pinning larastan in the workflow. Happy to send whichever you prefer.

[Heyosseus]

This turned out to be on our side rather than larastan's, and the fix is none of the three options , good instinct on all of them though, and the report had everything needed to chase it.

ViewStringType resolves a literal by calling view()->exists() inside an application larastan boots itself through Testbench, and Testbench takes its provider list from a root testbench.yaml. This repo didn't have one. So the analysis application never registered VacuumServiceProvider, never ran loadViewsFrom(DIR.'/../resources/views', 'vacuum'), and had no vacuum:: namespace to resolve against. 3.12.2 only added the Factory::make() stub that finally asked the question.

Fixed in #28 by adding that file. Verified against the exact resolution CI produces : larastan 3.12.2, Laravel 13, Filament 5, where it goes from Found 10 errors to No errors, and re-checked on the Filament 4 legs since booting the provider inside the analysis application is new behaviour. Worth noting a deliberately misspelt vacuum::nope still errors, which is why this beat ignoreErrors: we kept the check instead of silencing it.

Thanks for both issues and the PR. All three were accurate and saved a lot of digging.