Slim CLI?

[ABGEO]

Hello,

I think it would be nice to create a new Slim component - CLI Console (like Symfony Console), to start the PHP Dev server, Debug router and Container, Generating Routes and Actions etc.

If you agree with me, I can immediately start working on it.

[l0gicgate]

It would be a good idea to integrate into a separate repo. CLIs require a kitchen sink of dependencies so isolating it to its own repo is better imo.

[ABGEO]

@l0gicgate I agree with you, this should be a separate repository. We can create a new repository, for example Slim-console, and I will work in it, if we really need this feature.

[l0gicgate]

I'm definitely open to new features that improve the end user UX. Let's get some feedback in here and see what we should put in there

[RyanNerd]

@ABGEO07 @l0gicgate Would it make sense to put a CLI component as a part of https://github.com/slimphp/Slim-Skeleton ?
Since this is what Slim-Skeleton's purpose is:

to quickly setup and start working on a new Slim Framework 4 application.

[rotexdegba]

Is this supposed to be a cli tool for Slim powered web applications like artisan is for Laravel? Or is it a slim cli framework for creating cli applications?

[mgamal92]

@l0gicgate Can i start implement thie CLI Component ?

[ABGEO]

Is this supposed to be a cli tool for Slim powered web applications like artisan is for Laravel? Or is it a slim cli framework for creating cli applications?

First one :)

[ABGEO]

@l0gicgate Can i start implement thie CLI Component ?

@mgamal92 Waiting for feedback. After that I will start working on it.

[zelding]

I would make the life of the cron-jobs much easier :) +1 vote from me

[rotexdegba]

Is this supposed to be a cli tool for Slim powered web applications like artisan is for Laravel? Or is it a slim cli framework for creating cli applications?

First one :)

Thanks for the clarification

[RyanNerd]

What's the status of this? Has a new repo been created? I'd like to contribute to this effort.

[l0gicgate]

I need to create a new repo. We also need to figure out how the CLI will be built. What are we going to use to create a console? I have experience with symfony/console. Any other suggestions?

Also, what is going to be the initial functionality?

• Setup a project?
• Create routes?

I need more input

[RyanNerd]

I need to create a new repo. We also need to figure out how the CLI will be built. What are we going to use to create a console? I have experience with symfony/console. Any other suggestions?

Also, what is going to be the initial functionality?

• Setup a project?
• Create routes?

I need more input

I would suggest the initial functionality be create a project (prompting the user for what interfaces they want to use for error control, DI, etc.), Routes with a hello-world skeleton action. Other features to be added later may be validation and sanitation middleware.

My suggestion is to use Robo with Climate. I've used this successfully in the Willow Framework
I created Willow to marry Slim 4 with the Eloquent ORM. Here are some examples:

./willow list

./willow db:show-tables and willow db:show-columns User

[d3n972]

I would suggest the initial functionality be create a project (prompting the user for what interfaces they want to use for error control, DI, etc.), Routes with a hello-world skeleton action. Other features to be added later may be validation and sanitation middleware.

I would like to see something like in the yii2 framework's cli interface(especially their gii/* commands.

[froschdesign]

@d3n972

I would like to see something like in the yii2 framework's cli interface(especially their gii/* commands.

This means:

• Model Generator - This generator generates an ActiveRecord class for the specified database table.
• CRUD Generator - This generator generates a controller and views that implement CRUD (Create, Read, Update, Delete) operations for the specified data model.
• Controller Generator - This generator helps you to quickly generate a new controller class, one or several controller actions and their corresponding views.
• Form Generator - This generator generates a view script file that displays a form to collect input for the specified model class.
• Module Generator - This generator helps you to generate the skeleton code needed by a Yii module.
• Extension Generator - This generator helps you to generate the files needed by a Yii extension.

https://www.yiiframework.com/extension/yiisoft/yii2-gii/doc/guide/2.1/en/basic-usage

But where are the models, controllers, forms, modules and extensions in Slim?

[d3n972]

@d3n972

I would like to see something like in the yii2 framework's cli interface(especially their gii/* commands.

This means:

• Model Generator - This generator generates an ActiveRecord class for the specified database table.
• CRUD Generator - This generator generates a controller and views that implement CRUD (Create, Read, Update, Delete) operations for the specified data model.
• Controller Generator - This generator helps you to quickly generate a new controller class, one or several controller actions and their corresponding views.
• Form Generator - This generator generates a view script file that displays a form to collect input for the specified model class.
• Module Generator - This generator helps you to generate the skeleton code needed by a Yii module.
• Extension Generator - This generator helps you to generate the files needed by a Yii extension.

https://www.yiiframework.com/extension/yiisoft/yii2-gii/doc/guide/2.1/en/basic-usage

But where are the models, controllers, forms, modules and extensions in Slim?

Excuse me for being short wording my comment, of course I meant just the idea of generating code from stubs, instead of controllers, modules, etc for example Action classes etc.

[nixoncode]

@d3n972

I would like to see something like in the yii2 framework's cli interface(especially their gii/* commands.

This means:

• Model Generator - This generator generates an ActiveRecord class for the specified database table.
• CRUD Generator - This generator generates a controller and views that implement CRUD (Create, Read, Update, Delete) operations for the specified data model.
• Controller Generator - This generator helps you to quickly generate a new controller class, one or several controller actions and their corresponding views.
• Form Generator - This generator generates a view script file that displays a form to collect input for the specified model class.
• Module Generator - This generator helps you to generate the skeleton code needed by a Yii module.
• Extension Generator - This generator helps you to generate the files needed by a Yii extension.

https://www.yiiframework.com/extension/yiisoft/yii2-gii/doc/guide/2.1/en/basic-usage
But where are the models, controllers, forms, modules and extensions in Slim?

Excuse me for being short wording my comment, of course I meant just the idea of generating code from stubs, instead of controllers, modules, etc for example Action classes etc.

This is an overkill, slim is small allowing everyone to define their own structure and have their own way of implementation and not a kitchen sink.

[Radiergummi]

We use Slim as the basis for all our applications, adding default modules, structured base classes, a CLI module, a bundle approach and several other useful additions to it. Slim is fantastic here because it's completely un-opinionated about everything not request and response, and that is how it should be IMHO: Otherwise you could just use Yii/Symfony/Laravel.

Still, I am in favor of adding a command line interface to Slim, for two reasons:

1. Bootstrapping default structures and best-practices is really useful. If you look around the web, Slim docs or the skeleton application, you will find several approaches to getting started. This is both confusing and at risk of being outdated or introducing subtle bugs.
   If we had a command line interface that'd allow bootstrapping default components like routes and their handlers or middleware, or setting up DI, or clearing/warming up the route cache, there would be a canonical, up-to-date way to do things.
   Symfony does this pretty well, I think - their make:* commands do lots of boring stuff for you. Not that Slim should fully go down the Symfony road, but taking inspiration is fine I think :)
2. The possibility to add custom commands. I think in most applications of a certain size, a need arises to perform some actions on the command line - clearing caches, showing stats or performing maintenance tasks. If the Slim CLI would pick up user-defined commands, this would be simplified. Additionally, people could provide packages that, when installed both locally or globally, provide more commands to a project. This is pretty exciting because it paves the way for a streamlined Slim ecosystem.

To make this as easy as possible, I'd suggest using Symfony Console. That's the basis of composer, Laravel's artisan, the Symfony console and countless other tools. It's a simple, battle-tested, well-documented way to create console applications in PHP.

I'd volunteer to participate here, too :)

[flangofas]

@l0gicgate
Initial implementation

• Ability to create and run commands
• View all available commands
• Ability to wrap third-party commands such as Seeders, Migrations within Slim to keep everything centralize through the framework's console

For future plans:

• Easy way to schedule cron jobs (I love Laravel's approach)
• Build .env file interactively would be nice too upon installing the project first time.

👍 for Symfony Console.

I am a user of Slim and would like to contribute too.

[geniuscd]

I would love to contribute :) I use Slim all the time :)
i vote for the following

• Build .env file interactively as @flangofas said
• Create Oauth boilerplate
• Generate routes and classes
• The possibility to add custom commands

for boilerplate, i love how @akrabat is putting it all together.

[RyanNerd]

@l0gicgate I agree with @flangofas road map as well as 5 others have given a thumbs up. Is anything else needed before a repo can be created for this?

[l0gicgate]

I will be creating the repo here shortly.

Should we call it Slim-CLI or Slim-Console?

Also the initial feature set will be:

• Create base project structure with index.php and bootstrapping, choose your PSR-7 implementation and container implementation
• Build .env file interactively
• Generate routes and classes
• The possibility to add custom commands

We will be moving this discussion in the new repository when it's created and we can make a roadmap there.

[adriansuter]

What would the namespace names be like?

• Slim-CLI \Slim\CLI
• Slim-Console \Slim\Console

Personally, I don't like all caps in namespaces, but that's maybe only me.

[zhorton34]

php slim preset:container {container}

php slim make:command ExampleCommand

<?php

namespace App\CLI\Commands;

use Slim\CLI\Command;

class ExampleCommand extends Command
{
   // ...generated stub
}

vs.

<?php

namespace App\Console\Commands;

use Slim\Console\Command;

class ExampleCommand extends Command
{
   // ...generated stub
}

My vote goes to Slim\Console

[ABGEO]

@l0gicgate nice to hear that from you🙂 I can immediately start working on the application when we get the repository.

P.S. I vote for the name Slim Console and the namespace Slim\Console

[l0gicgate]

I think Slim-Console and namespace Slim\Console makes more sense. The package would be called slim/console on packagist. I will be creating the repo shortly!

[zhorton34]

Anyone have thoughts on the idea of these two types of console commands?

1. Preset Commands
2. Make Commands

Preset Command

1. Ability to update composer.json (AKA require a specific implementation)
2. Ability to add/import stubs (AKA scaffold/dummy class)
3. Ability to add/import preset specific make commands
4. Ability to remove preset (composer dependency, stubs, and commands)

Make Commands

1. Ability to parse dummy stub
2. Ability to accept arguments/options for a given stub
3. Ability to override default location where file is generated
   (Is it overly biased to default a location where a class will be generated?)
4. Ability to check if the given class already exists, and omit overriding the class as well as
   inform the user of a pre-existing file.
5. Generate the directories to the given default generation path if the directories don't already
   exist

Examples of possible preset commands
(Many examples are absolutely outside of the current scope, but provide some context)

php slim preset:container {implementation}
php slim preset:logger {implementation}
php slim preset:config {implementation}
php slim preset:app-debugging {implementation}
php slim preset:orm {implementation}
php slim preset:template {implementation}
php slim preset:front-end {implementation}

Examples of possible make:commands
(Many examples are absolutely outside of the current scope, but provide some context)

php slim make:middleware {name}
php slim make:migration {name}
php slim make:command {name}
php slim make:controller {name}
php slim make:model {name}
php slim make:action {name}
php slim make:factory {name}
php slim make:view {name}
php slim make:component {name}
php slim make:config {name}
php slim make:exception {name}

===

How cool would it be if Slim never lost it's unbiased view point, but made it extremely easy to setup preset and make commands so once a development team inevitably decides on an implementation that even if the slim preset/make console package that it was easy enough to make that they would create it themselves.

Slim console itself is a core package, but then each preset/make group was its own package that acts as a sort of plug-in or provided service into the slim console package.

We never lose the agnostic view point of core, but still provide the ability to easily expedite and enforce the decided upon implementation.

If extremely easy, I think this would go leaps and bounds to pushing slim open source contribution to the next level.

I don't know, maybe I'm just a little too excited at this point ~ what's everyone else's thoughts?

[l0gicgate]

@zhorton34

How cool would it be if Slim never lost it's unbiased view point, but made it extremely easy to setup preset and make commands so once a development team inevitably decides on an implementation that even if the slim preset/make console package that it was easy enough to make that they would create it themselves.

I agree, I think we should make something that is framework agnostic but that can easily be integrated with some popular libraries easily.

For now let's try and focus on one command at a time and have some thorough discussions around them. I will open separate issues for each. Let's continue the conversations in those threads

[l0gicgate]

See the two first issues:
#1
#2

Let's start there