Init / Setup Command

[l0gicgate]

As per my comment in the original thread, I would like to have discussions about the functionality and structure of each command. In this case, this comment would do the following:

• Create public directory (this is overridable from user input)
• Ask if they want to install a PSR-7/Server Request Creator implementation, default slim/psr7 but choices would be (Laminas, Guzzle or Nyholm)
• Ask if they would like to install a dependency container, default would be php-di/php-di but choices would be (Pimple or overridden by user input)
• Ask if they would like to setup PSR-3 logging, default would be Monolog, I'm open to other suggestions here.
• Setup composer.json with project name, copyright, license, scripts and PSR-4 autoload namespacing

As for initial directory structure we should stick to something like Slim-Skeleton:

app
|--dependencies.php
|--middleware.php
|--routes.php
|--settings.php

logs
|--*empty*

public
|--index.php

src
|--*empty*

tests
|--bootstrap.php

.gitignore
composer.json
phpunit.xml

Please provide some input y'all!

[zhorton34]

I like the thought process of giving the dev an initial core preset with some options. I'm wondering if we can decouple the specific default preset even further.

Before we set up the commands we need to set up the console entry point itself.

We could add a slim-console/bin/init.sh shell script responsible for publishing the entry point.

1. composer install slim/slim-console
2. ./vendor/bin/slim-console init

The slim console initialization script would generate a slim file in the repo root.

#!/usr/bin/env php

<?php

require __DIR__ . '/vendor/autoload.php';

$console = new \Symfony\Component\Console\Application::class;

/**
 * Register whatever commands we would need by default here
 *
 * $console->add(new \Slim\Console\Commands\Make\PublicDirectoryCommand::class);
 * $console->add(new \Slim\Console\Commands\Preset\DependencyContainerCommand::class);
 * $console->add(new \Slim\Console\Commands\Preset\PSR7ServiceRequestCommand::class);
 * $console->add(new \Slim\Console\Commands\Preset\PSR3MonologCommand::class);
 * 
 * Walkthrough each of the defined preset commands and give user options
 * $console->add(new \Slim\Console\Commands\Preset\WizardCommand::class);
 */

/**
 * Run Command
 */
$console->run();

/**
 * Exit Console Application
 */
exit();

php slim preset:wizard

This would allow us to stick to the actual core slim setup with the addition of slim-console and the given console implementation we decide to go with.

We wouldn't need to depend on a single command to set up a structure and eventually we could decouple or override the default application structure defined by the preset commands from slim-console.

[l0gicgate]

The slim console initialization script would generate a slim file in the repo root.

Typically you would have an application land in the vendor/bin directory. This will be addressed in the first PR and we can all discuss if what I came up with is the right solution.

php slim preset:wizard

This would allow us to stick to the actual core slim setup with the addition of slim-console and > the given console implementation we decide to go with. I really like the idea of having a setup/init command with a preset and an option to do things manually.

• setup:wizard
• setup:preset

Great idea!

[l0gicgate]

@ABGEO07 would you like to work on this command after #4 is merged? I know everyone was very eager to collaborate on this. Let me know

[ABGEO]

@l0gicgate Sure, I can work on this, but after merging #4 we have to decide what to do with #6.

I also have one question, whether Slim or Slim Skeleton will depend on Slim Console or users will install it globally and run from the global Composer vendor/bin/slim? In the case of Symfony Skeleton, it has a dependency on the Symfony Console, and we can manage the lifecycle of our project from ./bin/console. I think it would be great to make Slim Console part of Slim Skeleton.

[l0gicgate]

@ABGEO07 it’s a good idea, I’m curious as to how that would work considering the current skeleton has maybe a few too many things in it at the moment versus what a blank project would look like.

[ABGEO]

@l0gicgate We can offer users the following method:

1. If the user wants to create a project from Skeleton, he/she traditionally creates it using Composer and will have a Slim console in the project for further needs (Create command, route... Start dev server...).
2. If the user wants to create an empty initial project, he/she needs to require slim console in an empty directory and run the init command (e.g, php bin/slim init). After that, the necessary empty project is created interactively.

What do you think of this solution?

[l0gicgate]

I think that’s a good solution @ABGEO07

[zhorton34]

@ABGEO07 Okaay, I think I'm tracking now

Slim Core ~ Console Setup Will Require A Dev To Run

1. composer require slim/console
2. ./vendor/bin/slim-console init

Slim Skeleton ~ Console Setup Removes The Need To Run Those Steps

[ABGEO]

1. @l0gicgate Then i'll wait @flangofas when he will provide PR for #6, and after the merge I will start working on it.

2. @zhorton34 Slim Skeleton provides everything for a working application and does not need initialization. If the user wants to start from scratch, he/she requires Slim Console and runs the init command to create the structure described here.

[l0gicgate]

@ABGEO07 sounds good!

So what should we call the command to setup a project from scratch?

We need a command that has a default preset and one that’s a setup wizard that walks you through choices.

• setup:wizard for choices
• setup or setup:default for preset with Slim-Psr7, PHP-DI and default dir structure we choose?

[ABGEO]

@l0gicgate Since this command will initialize, start from scratch a new project, what do you think about this command and option? slim init - Initialize the project interactively; slim init --default - Initialize the project with default/recommended options;

Also this command will setup composer.json as you said.

[l0gicgate]

Alright sounds like we got it nailed down @ABGEO07!

[flangofas]

@l0gicgate @ABGEO07 Will the "Init" command create the slim-console.config file in the project's root directory as well, right? 😄

[l0gicgate]

@flangofas yes. We need to create the parameters for that config object though. We should define what those parameters are in #6.

[ABGEO]

@l0gicgate i think i can start working on this.

What did we decide about the global installation? Is this really necessary, or will we only have Slim Console as a project dependency?

[l0gicgate]

@ABGEO I think that we can go with global. This may change if we run into weird complexity though. Also make sure you make the initial PR a draft, don't waste time writing tests as I foresee a lot of changes along the way.

Can you list what the initial command will do just so we're on the same page before we begin?

[ABGEO]

@l0gicgate as we agreed earlier, we will have two types of initialization: 1) with default settings and 2) with interactive setup.

As you described in this issue, in the interactive initialization wizard, the user will configure:

• PSR-7/Server Request Creator implementation;
• Dependency Container;
• PSR-3 logging;
• Project composer.json; (I think the last one should be interactive in default mode too. I mean, the user will only fill information about the project. We can run the composer init command and it will setup composer.json)

[l0gicgate]

Sounds good to me @ABGEO! Just for future notes I think we should probably include minimum 2 different skeleton types. Right now Slim-Skeleton is for an API while a lot of people still seem to need one for static websites and use it with Twig. Should we also include that initially?

[ABGEO]

Should we also include that initially?

@l0gicgate i think yes. The first thing that comes to mind is initialization profiles, something like slim init --profile (web-skeleton || api-skeleton || something-else). What do you think?

[l0gicgate]

yeah I think that's a good idea @ABGEO. @adriansuter thoughts on the naming?

[adriansuter]

Not sure if the term skeleton is needed, if we talk about profiles. So api and web would be enough.

[l0gicgate]

I agree @adriansuter. Let's go with that naming convention api|web @ABGEO

[ABGEO]

Okay guys I will start working on this.

[ABGEO]

@l0gicgate I have a question, we can create some default files (app/dependencies.php, app/middleware.php, app/settings.php, public/index.php ...) and create a working application if the user selects the default dependencies (Slim PSR-7, PHP DI, Monolog), but what to do with other options? In the case of the dependency container, we should also get user input as you described.

[JustSteveKing]

I think a good way to approach this, and allow custom user commands is to use the Slim-Skeleton template, but with the commands addition:

app
|--commands.php
|--dependencies.php
|--middleware.php
|--routes.php
|--settings.php

logs
|--*empty*

public
|--index.php

src
|--*empty*

tests
|--bootstrap.php

.gitignore
composer.json
phpunit.xml

This way we have a specific place to look for commands alongside the default ones provided with the cli itself.

[l0gicgate]

@ABGEO sorry I've been unavailable, I am super busy with doing contractual work at the moment. I will try to respond when I can. I can't provide a timeline at the moment. @adriansuter may be able to help review and comment though if he has time.

[ABGEO]

@l0gicgate Np. I have more time for thinking and refactoring 😃