Rearrange src/commands directory following the new conventions

[tom-combet]

Rearrange src/commands directory following the new conventions defined in issue #85.

[tom-combet]

Question: Should we add a convention that requires a verb for the action? It looks quite messy when we have EmployeeList and ProductLatest at the same time. If we apply this convention, it becomes ProductListLatest.

The drawback I see is that the command names will be longer. Unless we apply this convention for class names only, but we would have a problem of consistency.

[ghost]

I dont test all commands but a lot it's ok for me !

Can you rebase the PR for the conflicts

[SebSept]

Converted to draft. MUST NOT be merged now because it introduce breaking changes. And we should also have a phpstan to ensure commands respect the schema. @Kaudaj is currently working on a validator that could be used inside the phpstan rule I created. #96

There is (at least) 2 different ways to switch the command names :

• raw : just change and let users change there scripts and habits
• shadow current commands with a 'redirect' to the current name + a deprecation warning ( à la Symfony ) if possible. Then remove the shadows in the next major release.

[tom-combet]

* shadow current commands with a 'redirect' to the current name + a deprecation warning ( à la Symfony ) if possible. Then remove the shadows in the next major release.

It would be hard work but I can do it progressively. Are you referring to this documentation?

[SebSept]

I don't think it will be hard. I did not study this point. I suppose that's not so difficult. Maybe I'm wrong, will see...

[tom-combet]

I don't think it will be hard. I did not study this point. I suppose that's not so difficult. Maybe I'm wrong, will see...

Not so hard, but quite long. I'll have to retype every old command class name, name and service name to mark them as deprecated if I understand well. I'm gonna study it after validator step.

[tom-combet]

/!\ Need your opinion /!\

@SebSept @okom3pom @jf-viguier @nenes25

I moved the validator in a Validators folder. Is it adequate? Should it be more general like Tools for instance?

[SebSept]

Too general names are subject to become a mess. The fact that this validator is used for code quality, for checking must be clear. This validator mustn't be in the same folder as the user code.

fyi, I worked on this subject with @Kaudaj , and this validator will be used via a phpstan rule.

[SebSept]

Notice, you can have a "dev-autoload" section in composer.json

[tom-combet]

Looks like PrestaShop put Validation classes in src folder, same for PrestaShop modules. @SebSept Do you still think we should put it aside? I found no resources at all about this topic.

[SebSept]

the src folder is currently perfectly clean, adding the validator doesn't look good to me. Maybe another folder, not src, what does Symfony do for this purpose (testing tools) ?

[tom-combet]

The most relevant documentation I found is about Validator component. I can't find any folder recommandation. Symfony stores it in src/Component/Validator folder.

Or maybe I missunderstood, what do you mean exactly by testing tools?

[SebSept]

The Validator in a class for the main Symfony code, not for testing Symfony, so it's normal to find it in src.

Here [https://github.com/symfony/symfony/tree/5.4/src/Symfony/Component/Dotenv]() we can see a folder Tests, it looks like the tests folder are at the same of the components, in a src folder. (it will be src/Tests/Validator for us, because it's a generic test) For prestashop, tests are at the root.

Having a test folder at the level looks good but is not the PrestaShop way.

So it's possible to :

• create a tests folder : require additionnal autoload config. | easy to remove the tests for the release
• create tests folder at the component level : no additonnal autoload | more complicated/risky to remove for release.

...

[tom-combet]

Ok so if I follow you, we put it in tests/Validator folder? Tests autoload configuration is already set in composer.json btw.

[SebSept]

Yep, looks good to me. WDYT @nenes25 ?

[nenes25]

@SebSept yes i agree with your point of view. With this way we can clean the release of all tests easily 😄

[tom-combet]

@SebSept @nenes25 Validator has been relocated. Could we merge this PR in priority? It was very annoying to rebase, I wish I didn't have to do it again... 😅

[SebSept]

I let others do the job as I'm on holiday 😎

[ghost]

The status is draft ?

[SebSept]

Command name's will change, right ?

[tom-combet]

Command name's will change, right ?

What do you mean exactly?

[SebSept]

'fop:debug-mode' is not available anymore. It's replaced by 'fop: environment:debug-mode' So scripts calling this commnad will break. That's a breaking change, unless there is backward compatibility. It's easy to achieve with $this->setAlias().

[tom-combet]

'fop:debug-mode' is not available anymore. It's replaced by 'fop: environment:debug-mode' So scripts calling this commnad will break. That's a breaking change, unless there is backward compatibility. It's easy to achieve with $this->setAlias().

Ah yea ok, I forgot that! Thought you wanted to change command names again. Commands aliases are set up. Also, service name will change. Is it a BC break too? I don't think we can set aliases for this.

[SebSept]

I guess, there is no need to set alias for services, this is not really services but just commands declarations.

[SebSept]

The next step will be to emit deprecation warnings but that could be done in another PR.

[tom-combet]

The next step will be to emit deprecation warnings but that could be done in another PR.

Do you mean in the code with PHPDoc deprecated keyword? I don't really see how to warn user in console output...

[SebSept]

I mean in console output. We'll fond a way to do it probably.

[tom-combet]

@SebSept I have added a deprecated warning, please check when you can.

[SebSept]

Good 👍 Maybe you can write in "version 2" instead of "soon"

[SebSept]

I updated the issue, not a draft anymore, since there is no breaking change.