Flux js and css routes crash after artisan optimize

[vorban]

Flux version

v1.1.0

Livewire version

v3.5.17

What is the problem?

The AssetManager.php declares routes to flux's assets, via callback: AssetManager.php#L43:

The callback contains a __DIR__.

When deploying through vapor (vapor deploy production) without a CI/CD pipeline, the artisan optimize command is run in the context of the local machine. This is usually not a problem, except if a route is an inlined callback, in which case the callback is fully serialized. See the ./bootstrap/cache/routes-v7.php file:

[
 // ...
'uri' => 'flux/flux.css',
      'action' => 
      array (
        'uses' => 'O:55:"Laravel\\SerializableClosure\\UnsignedSerializableClosure":1:{s:12:"serializable";O:46:"Laravel\\SerializableClosure\\Serializers\\Native":5:{s:3:"use";a:0:{}s:8:"function";s:420:"function () {
            return \\Flux\\Flux::pro()
                ? $this->pretendResponseIsFile(\'/Users/vorban/repositories/github/my-repository/vendor/livewire/flux/src\'.\'/../../flux-pro/dist/flux.css\', \'text/css\')
                : $this->pretendResponseIsFile(\'/Users/vorban/repositories/github/my-repository/vendor/livewire/flux/src\'.\'/../../flux/dist/flux-lite.css\', \'text/css\');
        }";s:5:"scope";s:17:"Flux\\AssetManager";s:4:"this";O:17:"Flux\\AssetManager":0:{}s:4:"self";s:32:"00000000000004ee0000000000000000";}}',
        'as' => 'generated::D5bVtasSPym8w366',
      ),
// ...
]

The important part is \'/Users/vorban/repositories/github/my-repository/vendor/livewire... -> this is an absolute path on my machine.

After a successful deployment, we get HTTP 500 on the flux routes:

{
    "exception": {
        "class": "ErrorException",
        "message": "filemtime(): stat failed for /Users/vorban/repositories/my-repository/.vapor/build/app/vendor/livewire/flux/src/../../flux-pro/dist/flux.min.js",
        "code": 0,
        "file": "/var/task/vendor/livewire/flux/src/AssetManager.php:128"
    },
    "aws_request_id": "redacted"
}

We can bypass this issue by omitting artisan optimize from the vapor build commands.

Code snippets

No snippet required. Install flux, and run php artisan route:cache or php artisan optimize. Observe the route cache file.

How do you expect it to work?

We'd expect flux routes to have the same behaviour, with or without artisan optimize, regardless of the context of execution.

Declaring a regular controller to handle the routing could be a potential fix (although I haven't had the time to test this myself), as there would be no callback to serialize.

Please confirm (incomplete submissions will not be addressed)

• I have provided easy and step-by-step instructions to reproduce the bug.
• I have provided code samples as text and NOT images.
• I understand my bug report will be closed if I haven't met the criteria above.

[jeffchown]

@vorban I believe this related to a known Livewire issue - when views are cached it can cause problems.
See: livewire/livewire#8068

[vorban]

@jeffchown mmh I've looked at the linked PR and it doesn't seem related to me.

I'm talking about route caching here - not views. Looking at the code, it's a different mechanism at hand.
The linked PR subject is the fact that livewire needs to "mark" blade statements with comments, and those comments are removed by the view caching of Laravel. Looking at the comments, this seems to be a complex problem to solve.

My issue is concerned with the caching of Flux's routes. Because the routes where written with inlined callbacks (or anonymous functions) the cache serializes them through PHP reflection, effectively hardwiring an absolute path at the time of execution. The proposed solution is a simple rewrite of the callbacks as named functions, basically an actual controller. Seems much easier to solve.

[jeffchown]

@vorban Thanks for the further explanation. I have to admit, as soon as I saw artisan optimize my mind went to that other issue as it seemed like it could have other side-effects.

Could it be the same issue with any Flux/Livewire cached routes? e.g. Maybe they need to be compiled/composed at execution by Livewire/Flux and when cached that can't happen?

If that is it, it's definitely not ideal as it would, at least for now, indicate we have to avoid both view:cache and route:cache in production under certain circumstances

As I haven't done a deep dive into the related code, this is strictly me thinking out loud as to the possibilities.