Unable to use `use` statements in a blade template that is included

[owenvoke]

I thought I'd just add an issue so that this doesn't get lost, however I'm currently looking into it a bit. 👍🏻

See https://github.com/owenvoke/phpstan-blade-rule/pull/3 for a fixture that demonstrates this issue.

When using the @include() directive with a file that contains use statements, in standard Blade it compiles to separate files, whereas (AFAICT) this package compiles to a single file which is checked (correct me if I'm wrong). But this causes the use statements to fail as they are in the global scope. Resulting in a PHP syntax error.

The error that will be output is:

PhpParser\Error: Syntax error, unexpected T_USE on line 5

---

Looks like it's because the use statement is embedded inside a function block when it's compiled. 🤔 e.g.

<?php
(function ()  {
    use Illuminate\Support\Facades\URL;

    URL::current();
});

[canvural]

Hi,

Sorry for the super late answer 😅

Yes, we put every @include into one file. Because of the shared variables etc. between the parent and include. There might be a solution that creates multiple files and analyses them, but now I think it'd mean complete rewrite of the project.

So for now I think we can extract use statements from included files and put them to the top of the file. I'll try to work on that 👍🏽

[olivernybroe]

Hey @canvural is there anything we can do to help you out with this one? 😃

[owenvoke]

Hey @canvural, sorry to bump this. But do let us know if we can help in any way on this. 👍🏻 🙂

[canvural]

Hi @olivernybroe , @owenvoke

Sorry I wasn't able to comment or fix this. I was dealing with some personal issues + had some holidays, and lots of work after holidays.

Like I said, we might be able to solve this by extracting the use statements from the included files, and put them into the top of the generated file.

But first, the CI needs some fixing. reveal/template-phpstan-compiler dependency is no longer exists. I think it got merged into revealphp/reveal repo. We use only small subset of that package anyway here. So the best solution would be to just create our own classes here.

If any of these two things sounds like something you can do, I'd appreciate it a lot! (I am expecting a reduced workload around November, so I'll give this package some more love!)