Improve scaffolding commands

All of us would agree that the scaffolding command is a great things in WinterCMS as it is into Laravel.

I've build many plugins this last weeks and used them widely, so I wanted to give my feedback on what could and should be improved from a "plugin-creator" point of view.

Also I'd like to get some other "plugin-creators" feedback here on how the features should be implemented

Translation keys into stubs

The first thing that should be improved is the translation keys into controllers. Most of them are already included into the core and translated in many language. I've modified the stubs here: https://github.com/wintercms/storm/pull/35

All of us need this:

many creator will create plugin for their personal use in their native-language so they are always forced to open and modify the generated controllers' views files which are only generated in english.
all the plugin-creators who aim to share their plugin on the marketplace want to make it usable by all the community without a regard to their language. Many plugins will be shared into english + the creator native language. I hope that the fact that the controllers actions will now be translated into the end-user native language directly from the core, it will ease its usage and invites the user to make a PR to the plugin to add his native-language translation.

[EDIT] @mjauvin pointed me out that a related feature has not been merged in the past due to the fact that it would be hard for beginners to read and modify the view file. This should live as an option of the create:controller command:

php artisan create:controller AuthorName.PluginName ControllerName --use-translations

Add composer.json file to `create:plugin` command

Because the marketplace will widely rely on composer-installation (stop me if I'm wrong), the create:plugin file should create the composer.json file.

Most of us has never published a package, easing the first step is a nice-to-have and will encourage us to do so.

The composer.json file can't contain any comment. To guide the users into publishing his package on packagist, the command-line should display into the terminal a link to this page which include a "how-to" section.

Generate the lang folder from command-line

A thing which is missing into the scaffolding commands is definitely the lang folder, I keep creating it plugin after plugin.

Because many of us will use create:plugin command to create site-specific plugin which will never be translated or may not even need user-readable text (Eg: a tiny Plugin.php file just to register to some event and process some logic), this should probably live into an option of the create:plugin command:

artisan create:plugin AuthorName.PluginName --with-lang-files

maybe this option could be filled with some extra locales that he want to translate himself:

artisan create:plugin AuthorName.PluginName --with-lang-files=en,fr,de,it

the default would be the en and [current_installation_locale] files.

Using this option, it would generates the lang folder and locale files but also include keys into the Plugin.php file:

public function pluginDetails()
{
    return [
        'name'        => 'authorname.pluginname::lang.plugin.name',
        'description' => 'authorname.pluginname::lang.plugin.description'
        //...
    ];
}

The presence of the lang folder should also be detected intocreate:model, create:component and create:reportwidget commands to generate the stub files including translation keys.

This would ease and so increase the number of translated plugins at a long term.

Add a `--settings` option to `create:model` command

A thing that annoyed me is to create a basic model that I should almost modify totally to make it as a settings model. The create:model command should accept a --settings option that would generate a basic settings model and not create a create_model_table.php file.

<?php namespace AuthorName\PluginName\Models;

use Winter\Storm\Database\Model;

class Settings extends Model
{
    use \Winter\Storm\Database\Traits\Validation;

    public $implement = ['System.Behaviors.SettingsModel'];

    public $settingsCode = 'authorname_pluginname_settings';

    public $settingsFields = 'fields.yaml';
}

if possible, passing this option would make the model class name optional and would default to Settings so this command would be valid:

php artisan create:model AuthorName.PluginName --settings

Add a `create:tests` command

It won't be the most used for sure but easing the creation of plugin-test will improve the community-plugins code quality at a long term and we'll all benefits from this.

This command line should generate the basic files including a passing test:

phpunit.xml

tests/unit/[PluginName]PluginTest.php


<?php namespace AuthorName\PluginNameTests\Unit

use PluginTestCase;

class PluginNamePluginTest extends PluginTestCase { /**

A basic test example.
@return void */ public function testBasicTest() { $this->assertTrue(true); } }

A shortcut to this could be included into create:plugin command, imagine ❤️ :

php artisan create:plugin AuthorName.PluginName --with-lang-files --with-tests

Add a `run:tests` command

Additionally to the previous one, it was a bit annoying to go into each plugin folder to run the plugin's tests. When I worked on some plugins that should work together, I had to make many:

go there
run tests from a ugly ../../../vendor/bin/phpunit
go back there
run tests from a ugly ../../../vendor/bin/phpunit
and so on many times...

This command should be possible to be ran from the root:

php artisan test:plugin AuthorName.PluginName

End-note

I could work on all these features as soon as most of us agree on the need of these and how they should be implemented. So please plugin-creators: Give us your feedback!

Do you think about anything that you would see implemented that I'm missing or should the commands I described be implemented in another way / syntax?

wintercms / winter