Resource Controller registration causes non-resource routes to be ignored

[bluesheep100]

Laravel Version

12.38.1

PHP Version

8.3.27

Database Driver & Version

SQLite 3.37.2

Description

Routes using a resources prefix (e.g. /users for the User model) placed after a Route::resource() call seem to be ignored, but still shown in the list when running php artisan route:list.

Steps To Reproduce

Discovered on v12.36.1, verified on v12.38.1

Tested on a brand new starter kit free application:

• laravel new routetester
• No starter kit
• Pest
• SQLite database

Test case setup:

• Create a resource controller: php artisan make:controller ExampleController -r
• Add return to_route('welcome'); to the index() method

Then add this method to the controller:

public function test()
{
    return to_route('welcome');
}

And the following route definitions to routes/web.php:

Route::resource('examples', ExampleController::class);
Route::get('/examples/test', [ExampleController::class, 'test'])->name('examples.test');

Run php artisan serve and visit localhost:8000/examples, which should display the welcome page.

Visiting localhost:8000/examples/test however, gives a blank white page, with 200 OK as the status code. If the order of the route definitions are switched, the welcome page is displayed.
If using a DELETE request instead of GET, this issue seems to end in a 404 Not Found.

[cosmastech]

Just to confirm, you're saying this has been an issue since at least 12.36.1, right?

[JesterIruka]

You are declaring two similar routes.

GET /examples/{example} (created by the resource method)
GET /examples/test

Declare /examples/test before the Route::resource() and it will be fixed.
This happens in every router I have worked with.

[bluesheep100]

Just to confirm, you're saying this has been an issue since at least 12.36.1, right?

Yes. I originally discovered this at work, in a 12.36.1 application, but since it also uses Vue, Inertia, and many other packages, I created a new application as bare as possible to confirm it, in case it was a controller override, or some package interfering with the route definitions.

I was a little rushed so I forgot to mention that the project I discovered this in also contains numerous instances of this pattern where the issue does NOT occur, and I don't currently have any idea why, which is why this confused me so much.

[bluesheep100]

You are declaring two similar routes.

GET /examples/{example} (created by the resource method) GET /examples/test

Declare /examples/test before the Route::resource() and it will be fixed. This happens in every router I have worked with.

I do know that switching the order fixes the issue, as I wrote above.
However I do think this is a decent idea as to why the issue occurs. I checked the stack trace of the 404 error and it happens In Route:resolveRoute(), (or something similar) which I'd presume means it's attempting to perform implicit model binding or something, despite there being no model to match to. Maybe /examples/test and /example/{example} just conflict. I can probably live with that, but arguably it could use a dedicated error for clarity.

[JesterIruka]

I do know that switching the order fixes the issue, as I wrote above. However I do think this is a decent idea as to why the issue occurs.

Not sure if there is a way to “fix it,” since it's not broken.
The framework is following the declaration order that you defined.
If it is declared first, the priority works, otherwise, it doesn't.

Ideally, you should use Route::whereNumber to match {example} only as \d+ (an incrementing primary key), which will not match /examples/test and will allow it to match the next route.

Also, this has been an “issue” at least since Laravel 6, which is the first version I used.

[JesterIruka]

I was a little rushed so I forgot to mention that the project I discovered this in also contains numerous instances of this pattern where the issue does NOT occur, and I don't currently have any idea why, which is why this confused me so much.

Perhaps you are using the Route::whereNumber or Route::pattern to only match a specific regex?
As I explained above, this will solve the problem, since /examples/test does not match /examples/[0-9]+

[ellnix]

I also agree that this is not technically a problem, however I also think it can be a source of a lot of frustration (I've seen at least one senior dev debugging a "missing" route and not noticing that this is what happened)

I think we could be more conceptually consistent if we throw an error when we come upon an unreachable route, the same way we throw an error if there are two different routes with the same name.

[marius-ciclistu]

Interesting how (overhead) features are complicating devs lifes when they were intended to ease them... Developer convenience...
Laravel's features should be used ONLY after the developer understands what they do behind the scenes.