You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Inb4 people scream "but what about the Artisan facade".
Yes, the Artisan facade exists, and some tests in this library do use the Artisan facade to test some behavior, but given how closely this library works with the dependent code, just using the Artisan facade is not enough to test this library 100%. Specifically, testing actual concurrency requires the artisan file (and by extension, the entire Laravel framework) to exist, so that this library can correctly start the async runners.
However, this artisan file is surprisingly difficult to setup correctly, and it is very tedious to track and mirror the Laravel changes to the artisan file in this repo. Previous attempts to mock artisan this way revealed that the file changed structure just from the Laravel 10 to Laravel 11 update; who knows if something similar would happen when Laravel 11 -> Laravel 12?
Initial plans are to create separate repos that each contain a minimal Laravel app with the intended test cases written into the /tests directory of each app.
The text was updated successfully, but these errors were encountered:
Now that I rethink about it, when looking at e.g. https://laravelversions.com/en , there is usually only 1 Laravel version that is in active support, as in: it has bug-fix support. As of now, only Laravel 11 is supported in this sense.
Also, consider that the Laravel artisan console command structure is pretty well-defined now, and should see no major breaking changes in terms of the cli signature. The problematic part is the underlying code, which we don't actually modify; we are just "borrowing" the artisan code, so to speak.
Then, is it really that important to demonstrate this library works in Laravel 10? Perhaps not.
This should save us a lot of hassle of managing countless repos just for the sole purpose of testing this library.
Yeah, let's just ignore previous Laravel versions that has different artisan file setups. When you look at it, this artisan file is basically unchanged for many years until Laravel 11 updated it, so going forward I do not see this version of the artisan file becoming irrelevant too quickly. It is safe to use this mock for the coming years.
Inb4 people scream "but what about the
Artisan
facade".Yes, the
Artisan
facade exists, and some tests in this library do use theArtisan
facade to test some behavior, but given how closely this library works with the dependent code, just using theArtisan
facade is not enough to test this library 100%. Specifically, testing actual concurrency requires theartisan
file (and by extension, the entire Laravel framework) to exist, so that this library can correctly start the async runners.However, this
artisan
file is surprisingly difficult to setup correctly, and it is very tedious to track and mirror the Laravel changes to theartisan
file in this repo. Previous attempts to mockartisan
this way revealed that the file changed structure just from the Laravel 10 to Laravel 11 update; who knows if something similar would happen when Laravel 11 -> Laravel 12?Initial plans are to create separate repos that each contain a minimal Laravel app with the intended test cases written into the
/tests
directory of each app.The text was updated successfully, but these errors were encountered: