laravel new myapp and artisan make:auth

Hi,

I'm trying to understand the rational of the following in the way that new Laravel apps are generated. Particularly the way the app code related to user registration, login, etc is generated.

When I create a new app with laravel new myapp, it creates many files including

app/Http/Controllers/Auth/AuthController.php
app/Http/Controllers/Auth/PasswordController.php
database/migrations/2014_10_12_000000_create_users_table.php
database/migrations/2014_10_12_100000_create_password_resets_table.php
app/User.php

The above files all seem like only a portion of a bigger system for user, registration, login, logout, password reset, etc.

In order to have the full system, I can run php artisan make:auth. This command modifies

app/Http/routes.php
resources/views/welcome.blade.php

and it creates

app/Http/Controllers/HomeController.php
resources/views/auth/emails/password.blade.php
resources/views/auth/login.blade.php
resources/views/auth/passwords/email.blade.php
resources/views/auth/passwords/reset.blade.php
resources/views/auth/register.blade.php
resources/views/home.blade.php
resources/views/layouts/app.blade.php

What the above means for the developer:

Currently, a developer who wants an "empty" app with nothing related to users, registration, etc needs to do the following

$ laravel new myapp
$ cd myapp
$ rm -rf app/Http/Controllers/Auth  database/migrations/*.php  app/User.php

Currently, a developer who wants an app with the full user, registration, etc system needs to do the following.

$ laravel new myapp
$ cd myapp
$ php artisan make:auth

So my question can be worded two ways

Why does laravel new myapp create any portion of the solution? Why doesn't it just create an "empty" app with nothing related to users, registration, etc and then leave the creation of all those files to php artisan make:auth? In this way, a developer who wants an app having nothing to do with users could run just laravel new myapp. A developer who wants an app with users could run laravel new myapp && cd myapp && php artisan make:auth or perhaps something like laravel new myapp --with-users.

or the other way to word my question is

Why doesn't laravel new myapp create the entire solution and then php artisan make:auth would not be necessary? (This is not handy for the developer wanting an "empty" app as they would have a lot to delete to get to the empty app.)

Thanks for sharing your insight.

Peter

sutherland

10 years ago

Level 28

Most apps will have some sort of user system, so providing logic out of the box is a convenience. Frameworks are by definition a partial solution that eliminates the need to recode common things.

The php artisan make:auth command is different from the included bits, because it relates to views and not logic. While the back end code that handles users could be the same on most applications, the front end of the site will almost always look different. I think make:auth is just included as a convenience for beginners or people building a small app very quickly.

For the few situations where you don't need the logic portion of a user system, I don't think it's that inconvenient to delete 5 files.

petermichaux

10 years ago

Level 1

Thanks for your thoughts. Your reasons may be exactly why but, even so, the default solution seems like an odd subset of what a full app needs and oddly organized to me.

For example,

There is password reset functionality included that sends out an email with a link; however, upon registration, no email is sent out to confirm the email address. Email confirmation is very common functionality. Since the sending email line has been crossed for password reset, it is surprising the confirmation functionality is not included.

There is no function to update the user's name, email address, and password. Updating these things in a "settings" page is very common functionality. When the email address is changed, send another confirmation email like suggested above for registration.

The solution is not RESTful. Registration is about creating a user. "POST /users" would be the RESTful request and imply there would be a UserController. This is also where the user settings update functionality would be. Also if one considers "login" to be a noun, then a LoginController would be the RESTful way to do login an logout.

So not only does the partial solution seem like an inconsistently chosen subset of general functionality, it also seems that the controllers are not optimally organized (i.e. not RESTful.)

I realize I can delete the 5 files and build up the features around registration, login, logout, etc but if there are others who think the ideas that I'm suggesting would improve the built-in solution then I'd like to continue the discussion and, if fruitful, help make it happen.

mehany

10 years ago

Level 13

@petermichaux I get your point, but i think this is being addressed with Spark . There is also a history of complaint about this very topic, what is currently implemented , I am guessing, seem to be the ultimate solution.

1 like

Please or to participate in this conversation.