Problem with route name after update to 1.24.3

[MatasElectronics]

Fortify Version

1.24.3

Laravel Version

11.29.0

PHP Version

8.2.24

Database Driver & Version

No response

Description

After upgrading to version 1.24.3 we've gotten an error when trying to cache our routes:

 LogicException

 Unable to prepare route [login] for serialization. Another route has already been assigned name [login].

The problem is with this PR #571

On our application we've always had views turned off, because we had our own login view already. We have this view named login (just as Fortify has always done). And it has worked perfectly.
But with this PR, now the POST route for logging in is also called login. And that causes this undesirable behavior.

Maybe the PR can be amended by giving the POST route another name, like login.store or something?

Steps To Reproduce

1. Create a new Laravel project.
2. Install Laravel Fortify.
3. Disable views in the Fortify config.
4. Create your own login view and give it the name login.
5. Run php artisan route:cache and you see the error.

[cima-alfa]

I already responded to this in the PR (#571 (comment))

I believe that the naming convention used in fortify should remain the same as with views turned on (both GET and POST routes are named the same).

In my project I just simply named all my front (NextJS) routes with the front prefix, such as front.login.

Although I do understand that in existing projects this might be an annoyance, I still think the naming should remain the same whether views are disabled or not.

[MatasElectronics]

I do not agree. A route name should be unique, and in the current situation, depending on a small config value, it either points to a route returning a view, or to a route to perform the actual login. I'd rather see the POST route is just named no matter what, it shouldn't depend on a "views" config value.

Also, I wouldn't expect a patch release to break our app...

[cima-alfa]

To be fair, as far as I know both GET and POST routes has always used the same name in fortify for login, register and a few other routes. I wouldn't use names on my custom routes that might collide with official laravel route names, but I agree that this solution at this point might cause issues for existing projects.

If needed and everyone agrees, I can go ahead and submit another PR that just simply uses unique names for affected routes.

[sergey-yabloncev]

Faced the same problem after the update

[cima-alfa]

Let's see, if I submit a new PR with unique names for affected routes, that shouldn't break any functionality for users with views enabled and use the GET route name to send POST requests to that route, right? Ultimately, the URL should still be the same.

Edit:
Also, as far as I know, this was a very minor update that doesn't really change any other functionality. It might be better to stay on previous version for now if this affects you.