Will this still work in Laravel 5.7

[jmichaelterenin]

I'm including code in my queue job that has multiple closures, and it would be drastic/significant work to change all the logic. Is requiring the package in Laravel 5.7 all that is necessary, or is there something more that needs to be done, as I am getting the expected:
Serialization of 'Closure' is not allowed: line 138 of C:\xampp\htdocs\explore\vendor\laravel\framework\src\Illuminate\Queue\Queue.php

Including the code would be beyond the scope of this question, as I am reading in other issues how Laravel has removed super closure from it's dependencies, and I just need to know if this is still a relevant package.

I kinda assume that it is, so my next question after hours of trying to figure out what closure it's balking at is: is there some way to figure out what closure it's complaining about?

Thank you and happy holidays

[GrahamCampbell]

Thanks for the question. For some background, Laravel 4.0.8-5.3.31 used to use this library to enable serializing closures as part of the mail system, but this feature was removed in Laravel 5.4.0, to allow for removing php-parser from the core framework dependencies. So, the old closure serialization mechanism in Laravel no longer will work.

So, in Laravel 5.4, a new mail paradigm was introduced, removing the need for this package. Laravel has never supported queuing up closures actually, not until very recently at least. In Laravel 5.7.7, a way of serializing closures for queuing was introduced using a different library: laravel/framework#25777.

So, as for your question, "Is requiring the package in Laravel 5.7 all that is necessary". The answer is no. This library doesn't mess with PHP's serialization primatives. See the readme for an example of how to use the library (https://github.com/jeremeamia/super_closure). If you want to get a good idea of how this stuff all works, I'd recommend taking a look at the source of this library, and the opis (https://github.com/opis/closure) library, and also the source of the Laravel queuing code. Luckily, the source code for this package, and opis is pretty small, so it's possible to flick through it all in one go.

Laravel's queue and mail components are a bit more meaty, and it's not really realistic to read all the code (https://github.com/illuminate/queue/tree/5.7, https://github.com/illuminate/mail/tree/5.7). Essentially, the key points are understanding how the service providers work, and then noticing that https://github.com/illuminate/queue/blob/5.7/CallQueuedClosure.php is the object that's actually pushed onto the queue instead of an actual closure, when someone asks to serialize a closure for queuing. I'd recommend looking at https://github.com/laravel/framework/blob/5.7/src/Illuminate/Queue/SerializableClosure.php too, and how all the traits work from both these files. Finally, anyone not using the global dispatch method (https://github.com/laravel/framework/blob/v5.7.19/src/Illuminate/Foundation/helpers.php#L386-L401) will need to manually package up their closure in this manner.

I'm including code in my queue job that has multiple closures, and it would be drastic/significant work to change all the logic.

Not using closures may be less work than you imagine. There are some easy refactors you can make to avoid this problem, such as using invokable classes. If you're using closures to do complex bindings and other features of closures not common to callable, you will actually find that unfortunately, when the are unserialized again, all your object references are broken. There's no way to recover them unfortunately.