Artisan make:class to make a regular PHP class

[ronnorthrip]

So what do y'all think about a command like make:class to make a plain php class?
Also where would the resulting output go to by default?
Models?

[browner12]

What is the benefit over just making a class manually?

I'll tell you based off of historical PRs, something like this would have a very low chance of getting merged.

[ronnorthrip]

The benefit is simplicity, good dev ex and consistency (think of all the other make commands).

[ronnorthrip]

Plus there's lots of people out there who I respect who make new models and then strip out the filling to make it into a php class, so this would be faster than than.

[ronnorthrip]

Also considering make:trait and make:contract

[browner12]

any IDE worth their salt can do this just as fast. if you want any hope of this getting merged you'd need an incredibly compelling case for the benefits. and just saying

simplicity, good dev ex and consistency

are not going to cut it.

[ronnorthrip]

I think devex and consistency ALONE are worth it.
Devex is about details - I can't imagine the master of the 3-line-comment would not find that worthy

[browner12]

best of luck to you.

[ronnorthrip]

I appreciate your thoughts on this! You're right about wanting to offer something MORE useful.

[browner12]

To be clear, I don't want these commands added.

[ronnorthrip]

So this conversation has been progressing in several different places (slack, twitter, and here).

We can have the make command be customizable and use a config and the stubs dir to add any make:whatever.
Then we can use that to put our makes into the repo and share with our team.

In addition to this we should add to the framework
make:action
make:class
make:contract
make:service
make:trait

[taylorotwell]

I'm not entirely opposed to this. My gut feeling on the commands would be something like:

make:class
make:class --action
make:class --invokable
make:contract
make:trait

Regarding make:service, was the idea for that to be a class within app/Services? If so, does it make sense to be make:class --service? Regardless, I'd like to get a better idea what we mean by "service" here.

[ronnorthrip]

First off - thanks for taking the time to think about this, Taylor.

The idea for service was app/Services (make:service).
But this also begs the question about app/Providers (make:provider)
I think make:class --thing could be the way to address both of those.

But I'm also wondering about make:class --STUBTEMPLATE too?
Thoughts?

[taylorotwell]

I think make:provider is a bit of a separate discussion since it's a very Laravel specific concept.

I'm still curious what we mean by "service" here. What is a service class in this context? For example, in my own applications I have created an app/Services directory before but it only contains classes that interact with outside third-party services like GitHub, AWS, and other external APIs. But, the word "Services" is a broad term and probably other people use to mean totally different things.

So, that being said, I feel like make:class --service is the option I'm least interested in at the moment since it feels the most vague. The others feel pretty solid.

[ronnorthrip]

I had to new up a laravel app.

1. make:provider is actually already there so there's nothing to do there
2. I actually thought the Service dir was standard and that's my bad - I follow that same pattern in my apps (apparently).
3. Should we consider the idea that maybe Service might be a worthy addition to the framework - probably in a different thread?
4. Any interest in make:class --STUBTEMPLATE or something like that so people can add their own stubs and use it/extend it themselves?
   make:custom --STUBTEMPLATE or make:special --STUBTEMPLATE
5. Is there value in mapping this with a config file or should it just use the content of the stub dir?

[Bowero]

I love this idea. I've never contributed to Laravel before, so I started with the simplest one. Could someone give me some feedback on this?

Bowero/laravel@555b4ad

If I'm doing this right, I'd be happy to work on the other suggestions as well.

[ronnorthrip]

I can't tell you how awesome I feel right now.
This idea is already coming to life.

[x7ryan]

If I could throw in my 2 cents, I really would like an easy way to create Services and Actions using artisan make commands. I know they are more of an "unofficial" standard from what I understand but I think they are used enough to deserve to be made first class concepts. I get that especially Services are somewhat vague, but I think that's sort of the point, Its a convention for storing plain PHP classes with logic that don't fit well in existing Laravel concepts.

But I wonder if it would not be better and more flexible to allow for custom make commands easily. Sure you could write a custom make command, but what if for simple things that require no custom arguments, could there not be a generic make:(something) command that would map to a matching stubs\something.stub file without having to define an actual command.

The way I imagine is if it does not find a matching command class for a given command name, but the command name starts with make: it would look to see if a stub exists with a name matching what comes after the : and if so scaffold that out. Ideally it would be nice if it could infer the path for the file from the namespace in the stub but off the top of my head I'm not sure how easy that would be. Worst case I suspect a simple array in a config file could map these custom make commands to a base path/namespace. Then having a make:service or make:action or any other custom make command becomes trivially easy so it could be customized per app without any real work beyond adding a stub file (and maybe a line of config).

So that if I make a file stubs/service.stub that defines a plain PHP class with a base namespace of App\Services. If I run php artisan make:service MyService The framework would not find a command with the signature of make:service but it would see that it starts with make: and pass it off to a default make scaffolding command that would see the namespace as App\Services and would then make a file at app/Services/MyService.php using the stubs/service.stub stub.

I think keeping it arbitrary and extensible would be the most generally useful way to move forward with a PR that provides for the most value for the additional framework code.