+1 for routes.php against annotations system. I like having all the routes in one file/location.

I would say leave the file in place for people who are not used to the framework. I usually do some tests within that file and execute. So in a way, it comes out handy for some of us and would also be of great help to beginners who are just taking up the framework.

Please keep the routes file. Location isn't crazy important to me but it would be really sad to see it go.

Laravel started as a simple framework with a Sinatra-style routing system that didn't even support controllers. Then we got controller support. Now we are talking about abandoning the Sinatra-style approach altogether.

It sounds like a fairly small change but I think it's a really significant change that cuts ties from the origins of the framework :/ I'm all for progression but I don't know if anyone ever complained about the routing in 4.*. I thought it was awesome!

+1 to keep the routes file and current position is ok

And heres my 2 cents worth of opinion around the debate for the mix:

It kinda feels like route annotations are being forced onto the community and that doesnt feel so good.

Overall I'm not against the option per se. By all means introduce it - but perhaps as a secondary option to start with.

I see very few people in favour

I see small (insignificant even) "benefits" being expounded as tho they were massive game changers - which from my pov they arent

here's a few quotes from this and other threads with my thoughts:

"@JeffreyWay: It won't be confusing at all"

How can camouflaging routes as comments not be considered confusing?

And saying doc blocks arent comments is hair splitting. even if they arent comments, they are not annotations either At current state of PHP doc blocks arent intended for code, my ide ignores them and wont validate them, highlight them, or debug them - and the ide issues alone seem to me to be a major downside.

"@JeffreyWay: There will be a cached routes file that you can refer to"

There already is a routes file - routes.php

"@JeffreyWay: No it won't. You'll debug it in the exact same way, as if you were manually writing them in your routes.php file"

How can I debug a comment? as in step through a route defined in a doc block?

"@thepsion5: Personally, I don't like the idea of putting real application logic in comments. I'd much, much rather have the option of using an array configuration of some kind"

I entirely agree. I dont disagree to provide some means of including routes within the controller - if its deemed neccessary because there is some clear and very well defined advantage - but doing it with comments...? really it just seems wrong.

just because you can, doesnt mean you should

I really like the routes.php file as a way to get a quick overview of the application. But if people like annotations, it's great that the option is there for them!

I completely agree @londoh - I have been reading the posts over the last few days.

[Warning - this post might read as a bit shouty, but it's well intentioned I promise, I welcome feedback on anything I have overlooked :) ]

I have a simple API at work - a Route::group() with a prefix for version, with a Route::group() within that to authenticate some of the Route:resource() entries. This is about as complex as it will ever get, perhaps an extra resource every few months, but I doubt it will ever top 30. It's self-documenting, requires no compiling if anyone else clones the repository. If you attempt to edit it, the IDE/linting will pick up immediately if you made a mistake.

Annotations might have a place for some people - if you need routing to cater for linking with many other companies (e.g. a courier company integrating with suppliers) then I can absolutely see the need to have that level of fine-grained control as no-doubt they will all require different filters/formats/headers/authentication.

The annotations are not namespaced and nobody has yet provided any answer to my previous post regarding API documentation using tools such as Swagger, which is a suitable strategy to document an API http://zircote.com/swagger-php/annotations.html#resource - using annotations and Swagger I would end up with two very similar sections of docblock.

I'm sure some people will find it useful - if you have 200+ routes, it will be a heaven sent feature. However I'm still not convinced it's for the majority:

• IDE provides no auto-complete for it.
• IDE provides no validation for it.
• Toggling comments on/off in an IDE hides the behaviour of the code (this is very different to other items like @codeCoverageIgnore @dataProvider in tool like PHPunit, which is only documentation, not execution related.
• Requires compiling before knowing it's valid and adds debugging overhead.
• If using API documentation tools you will have two almost-identical docblock statements.

If my employer asked which we should choose I would say routes.php at the moment, otherwise time to develop, test, read, comprehend and write the code goes up for current and future developers added to the team. As we all know: time equals money for us and our employers/clients.

As developers we always like the novel and clever solutions (it's what attracted us to the industry, right?), however, experience (both positive and negative) teaches us that the most comprehensive solution is not always the most appropriate solution. Even if I knew 100% that our API was going to expand to support 15 external companies I would start with routes.php - because if I get 50% of the way through developing it and realise I need to change the behaviour across the board, it will be very painful to re-write all those doc-blocks (especially if I have to maintain some PSR-2 compliant indentation!).

By all means - keep annotations. By all means put a beautifully indented comment at the start of routes.php suggesting it as a logical path - but don't force it as default and let us work with progressive enhancement and keep the easy learning curve that has made Laravel popular in place :-)

My code worked fine before I used the repository pattern, and now it works better since I realised I needed it, and then subsequently started using it. Problem first, solution second!

@gregrobson "I'm sure some people will find it useful - if you have 200+ routes, it will be a heaven sent feature."

Howcome 200 route definitions distributed over twenty controller files can be a benefit ? All the routes in one file, you can mass edit them.

+1 for include by default.

@pmall - ah, I should really have said "200 routes with varying filters/formats/headers/authentication requirements".

Then I can see it being advantageous when looking at a method to know what has been applied to it.

If you have a straightforward GET /api/ControllerName maps to ControllerName::index() (i.e. standard REST implementation) then it should be intuitive to know what code is called when.

What about keeping the routes.php file. Having an option in the app config file to use annotations or not, and have the scanned annotations be put in the main routes.php file?

I've not used reflection before, but for the people who don't like that they are comments, can't they just be done like how blade @ symbols are used? Just have reflection wrap them in doc blocks when parsed? That way the IDE won't hide them and maybe there's a chance for someone to add mods to the IDE's to let the be analysed as code?

Can you do this with annotations without duplicating the prefix in every controller?

Route::group(['prefix' => 'api/v1'], function() {
    Route::resource('comments', 'CommentsController');
    Route::resource('articles', 'ArticlesController');
    Route::resource('users', 'UsersController');
});

So far it's sounding to me like annotations require duplication, and it's because the dependency is backwards.

@adamwatham - Likely, there will be a way to declare the prefix on a parent class, that then trickles down.

Yeah true that could work. Forcing an inheritance hierarchy just to use annotations feels like reaching a bit though :/ When we preach composition over inheritance, using inheritance as a trick to get some route prefixes instead of for polymorphic behaviour feels a little wrong.

I actually like the @View stuff someone was sharing on Twitter earlier, so I'm not opposed to annotations as a concept really. I just don't know if routing the is right place to use it.

When I'm creating a route, I'm not thinking of it as configuration for a controller action at all, which is why I guess it feels so wrong to me. I don't think of the URI as metadata for the controller action, I think of the controller action as metadata for the route.

In the case of the @View idea, it makes sense because what view the action returns is actually the controller action's business. What route points at the controller action isn't really the controller action's problem at all :/ I dunno.

I would honestly rather something that scans my routes file and adds comments to my controller actions to tell me what the URI is than vice versa :)

When you're creating a route, I'd imagine that, every single time, you associate that route with a controller....and then switch over to that controller...and then write your logic. Now, that process has been simplified drastically. Maybe it takes a little time to get comfortable with. Most new things do.

I think there's too much focus on negativity, rather than considering how this will make your lives easier.

1. Have instant visual cues for the URIs that are associated with controller methods.
2. Automatically register routes with less typing. (A lot less.)
3. Declared controllers are automatically scanned in your local environment. There's nothing for you to do.
4. Less file switching.
5. If you wish, a nicely formatted routes.scanned.php is available to review. Otherwise, php artisan route:list.
6. It's laughably simple to add middleware.
7. There are also annotations for events (which are awesome). So this keeps things consistent.
8. Laravel has and has always been forward-thinking. This reflects that, in my opinion.

As a little exercise, take the routing and middleware references from the AuthController that comes with Laravel, and translate that to your routes.php file. Take a look at what you end up with, and decide if that's better than the annotations approach. It might be eye-opening. It was for me, when I saw it.

I think it should stay , location is fine but would be better under app folder. Annotations are great addition to the framework. I will prob use them both on all projects since they both have their strong points.

well looks like routes.php is removed as of latest update to laravel/laravel

Yep.

Before people freak out, you can require it back in from your RouteServiceProvider.

Yeah, easy to un-comment it out and include your own routes.php file.

But, now it seems that we have to manually list all the Controllers with annotations in them in order for them to be scanned by route:scan?

/**
     * The controllers to scan for route annotations.
     *
     * @var array
     */
    protected $scan = [
        'App\Http\Controllers\HomeController',
        'App\Http\Controllers\Auth\AuthController',
        'App\Http\Controllers\Auth\PasswordController',
    ];

And we have to list them using their FQCN :( Is that intended behavior? I liked it before when we could just run route:scan and it'll automatically scan all your controllers.

A little less magical, but the upside is that you can now control the scan order. You update that file once per controller (if it uses route annotations). Not a biggie.

:(

Uncommenting one line brings it back.

require app_path('Http/routes.php');

Everyone wins in this scenario.

For now :/ Just feels like we're on the path to the "old" way no longer being supported.

But why FQCNs for controllers? less magic...?

Everyone wins if nothing changes and route annotations get released as a package too.

@vJacob - Does it really matter? Duplicate the line, and update the controller name.

its just my OCD, carrying on...

Route annotations is a good thing, now you can define all routes directly in a controller! Yii doesn't have routes file at all and they are not declaring every route.

(offtopic)

@heihachi88 from when I last looked at Yii I saw they had a very rigid route to controller mapping, which is why they don't have a particular routes file. One of the many reasons why I'm using Laravel now.

I'd rather be involved in this discussion than use Yii any day :)

If you uncomment the routes file you might want to wrap it with the namespace method if your wiring up your routes to controllers.

$this->namespaced('App\Http\Controllers', function ($router) {
    require app_path('Http/routes.php');
});