-
Notifications
You must be signed in to change notification settings - Fork 11.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[8.x] Change loadRoutesFrom to accept group $attributes #34866
Conversation
this breaks with mll-lab/laravel-graphql-playground i expect the response is going to be to fix that library but just letting people know :( |
Do they have an override of the changed method? |
i havent actually looked at their code yet but i think they are overriding the method, i tried to run composer update in a project im working on and got an error of "[2020-10-20 16:49:45] local.ERROR: Declaration of MLL\GraphQLPlayground\GraphQLPlaygroundServiceProvider::loadRoutesFrom($path): void should be compatible with Illuminate\Support\ServiceProvider::loadRoutesFrom($path, array $attributes = Array) {"exception":"[object] (ErrorException(code: 0): Declaration of MLL\GraphQLPlayground\GraphQLPlaygroundServiceProvider::loadRoutesFrom($path): void should be compatible with Illuminate\Support\ServiceProvider::loadRoutesFrom($path, array $attributes = Array) at /app/vendor/mll-lab/laravel-graphql-playground/src/GraphQLPlaygroundServiceProvider.php:49)" |
@rs-sliske is right, I already submitted a PR for it here mll-lab/laravel-graphql-playground#46 But this changes breaks more than someone might actually thought of. For example nuwave/lighthouse also suffers from this change. Making a PR for it right now. |
Yeah, this error is due to override, but the fix for it is also very quick and easy I think. |
Of course its quick and easy, but it also sets back a lot of developers in their time after upgrading to this version. I am not aware that I had any problems after upgrading Laravel in any minor revision in the past. |
I think this change relates to package maintainers and not typical web app developers, and because something like travis normally emails them and warns package maintainers of failing builds, it does not take a lot of time for maintainers to do the quick fix, and the web app developers must not see any breakage after they upgrade. (since they also upgrade the installed packages.) |
This reverts commit e719250.
I think that understanding the reason that many package maintainers have overridden this method can be insightful. |
@imanghafoori1 from the other GitHub repostiories referencing this PR, one use case is to check if the underlying app is a Laravel or a Lumen app. References: |
We've reverted this PR. |
@driesvints |
I don't recommend that as this seems to break too much (including Lumen). |
When we define routes it is often needed to include a couple of middleware groups (especially
web
orapi
) on the loaded routes in the files.This PR makes it possible to refactor out the
Route::group
call in the manually loaded route files and make them flatter while maintaining the proper route-caching.Plus, it brings the
$route
object back and makes it consistent with default route files.Route::group($attr, $path);
directly in the boot method (instead ofloadRoutesFrom
) requires knowledge of how the route caching is done in that particular version of laravel or they will not get cached.Performance hit:
On production, it should have zero-hit on performance, since the routes are cached.
Before
After:
Backward-compatibility:
This is mostly backward compatible except for method signature issues, which arise when overriding methods in subclasses, which is very rare.
illuminate\support
package.