+1 for include by default and current location of the file.

The only thing that removal of the routes file will do, is make annotations the default practice. If we are to have annotations at all, I think it's foolish to keep the routes file because that will surely lead to fragmentation in the way that Laravel is taught and learned. Laravel needs consistency here!

As has been mentioned, there are advantages to keeping the routes file for some people and if you fall in that camp, remember you can add it right back in there in 5 seconds, no big deal.

So if annotations are going to "be a thing", let's not confuse newcomers for the sake of 5 seconds of your time.

Just put in an artisan command that generates the routes.php

Why do we need an Artisan command to create an empty file?

Let's remove routes.php file. Route annotations seemed convenient to me.

@JeffreyWay - perhaps to make certain it is in the location. And perhaps with a home route in it and / or commented out examples of routes.

// artisan
php artisan routes:make

//nix
touch app/Http/routes.php

//win
type NUL > app\Http\routes.php

Not a lot in it. Of course Artisan could create some default entries, although that info would be in the documentation anyway. Seems a bit of a waste of time though for something you'd only use once at the beginning of a project.

We're over complicating things here all for the sake of a file that takes seconds to create yourself if you require it.

I disagree with the "fragmented" learning. As with just about everything else in Laravel, PHP in general or any other language/framework, there are multiple ways to skin a cat it boils down to preference. Routes file vs. Annotations is one of those preference things. Also remember, that even with Annotations, there will still be a routes file.

I feel like it's better to say "Hey, don't go updating the routes file created by routes:scanned, here's what you can do instead (enter app/Http/routes.php)."

I don't see it as a learning curve or confusing. If the docs say:

"Routes can be defined in one of two ways... Way 1 and then here is Way 2" that's not confusing at all. To not mention it will end up being more confusing and will just bring up more questions, because when someone has a package out there with a routes file, a n00b might be like "what in the world is this routes.php and what do I do with it?".

If someone can't look in the docs and see and understand that, then we have bigger support issues than them figuring out a routes file.

Leave it in, talk about it in the docs... There's no harm in it. If you can't scan packages or extension type systems, then you're going to have to use route files anyway, so might as well document it and show an example in the filesystem.

@dberry I totally understand what you're saying and I agree that it's a case of user preference. BUT, there lies the whole problem, in my eyes at least.

If one tutor prefers the route file and another annotations, that's the classic case of fragmentation.

If one package developer prefers route files... you see where I'm going.

If we are to use annotations, which seems to be the way things are heading (and let's face it, Symfony 2 seems to do fine with them), then we must promote a single (preferred) way to go about it.

If we don't do that, not only will teaching/learning be more difficult, but third party packages will use their preferred method as well.

My argument is purely about consistency and I think removal of the routes file helps to encourage that.

@alenabdula @JeffreyWay I made the reply and then deleted it, apologies if it was confusing, I changed my mind about participating in the discussion, probably should have left it, did not mean to mislead people into thinking the discussion was being moderated. Side note, minor bug: the reply is still visible on my profile because profiles don't appear to respect deleted comments.

I guess the most important question here is whether the route annotations approach is better. If it is, then we should very much encourage people in that direction.

I don't have an incredibly passionate view on this in either direction. However, if you play around with them, it's very difficult to not enjoy the improved workflow.

@citricsquid - Sounds like I need to delete the associated cache, when a reply is deleted. Thanks! Will fix.

@citricsquid thanks for chiming in, you had some great points...

Just wanted to throw this in here for people who are unfamiliar with annotations or those with pre-conceived ideas.

To me anyway, they're not the devils work and you'll find they're even used in PHPUnit itself.

You might be surprised.

http://www.youtube.com/watch?v=TqyWGbQUPGM

Whether that file is there or not by default, there will be tutorials and people out there pushing route files, because not everyone likes annotations. It's an issue where the community will always be split. That's not a bad thing, as long as people respect each side.

I'm personally indifferent, but route files aren't ever going away, so the community will have to embrace it. Whether you take that file out by default or not, and whether Jeffery pushes annotations or not, there will always be two schools of thought and two ways of doing it, so might as well prep for it. Regardless, the questions are coming.

I personally just moved the contents of routes.php into the RoutingServiceProvider.php instead of the requiring of the file.

@JeffreyWay "I guess the most important question here is whether the route annotations approach is better"

Has it been written out anywhere the pros and cons to either direction? Or maybe how it fits into the roadmap of L5?

@alfrednutile - Yeah, if you hunt through this thread, there are some references to the pros/cons.

If we can establish that routing is linked to the controller, then it makes sense for the two to be connected.

+1 for removing routes.php.

My only concern with switching to annotations as the primary way of doing routes is the order of the routes. That can be very important at times. @TaylorOtwell: Is there anyway when using annotations to force a particular order?

Actually nobody cared about the way of routing our app before the appearance of these useless and ugly annotations. Now we have huge philosophical debates about what is the best way to define our routes and which default approach the framework should present.

+1 for keeping routes.php and +1 for removing annotations.

Played a bit with the annotations, not really my favourite feature, but I guess it'll work after getting used to it a bit. As for the poll, like others have said, if annotations are here to stay, the routes.php file should be removed, especially considering routes specified in the routes.php take precedence over routes specified in annotations (for the moment anyway, might get changed).

I have never been fond of annotations (for anything) even in my tests I only use annotations if thats the only option. I like to control everything with code, and using comments makes me feel a little uneasy.

However, Controllers are your HTTP layer of your app so declaring your routes in the controller seems like a good idea to me, and we will get a routes.scanned.php files so we can see if anything has gone askew.

So even though I don't usually like them, I will definitely be giving this a try.

I think the routes.php file serves a single very important purpose - documentation.

I can open any Laravel application, go to routes.php, and see in a single file how that application interacts with HTTP - it's all laid out right there. If we remove this file, there is no more high-level overview unless we use the CLI command, which is often way less convenient.

Plus, what if we don't want to use annotations? We'll just have to recreate a routes.php file somewhere.

@thepsion5, you'll still be able to do that by going to the /storage/framework/

Also, yeah doing the artisan route:list will show all registered routes from annotations and route files.

No matter what, some people will still use the routes.php files, for whatever reason. They may not like annotations, they may not be able to get it to work with a plugin system or package, or any number of other reasons.

I could see not having it there if 1) it wouldn't work like that anymore and was just a backwards-compatibility issue or 2) annotations were a best-practice, but neither of those are the case. So might as well document it and provide the demo default routes file because you know the questions are coming.

I don't see "confusing new users" as an issue, regardless of what you do that will be an issue.

Not leaving it in because tuts will be done about it is really a non-issue, because even if you take it out, there will still be tuts done using the route file.

I see annotations as just another feature, it's there if you want to use it, if not then you don't have to.

+1 keep it for noobs (but not for long) like me please.

Been playing with the route annotations feature to formulate a better opinion on this topic and I see no reason why newcomers would be confused by them. Having routes.php and annotations has a good chance of confusing newcomers so my vote is definitely to remove routes.php. Don't remove the ability to create and use a routes.php file though; it still has it's benefits.

Personally I find the routes file to be much more legible than looking through a bunch of comments. Haven't messed with annotations that much to be honest so what is the big benefit of that approach?

@andmm I thought the same thing but gave annotations a quick spin today and it is nice to have the route defined next to the method that will handle it.

You should definitely let users decide which of both methods they want to use. I may repeat what some dudes already said but each projects is different and everyone one works differently. Laravel is known to be a flexible framework so let it be our choice by letting both.