[DX] Moving prestashop forward

[FabienPapet]

As core developers we have a responsibility to build a reliable way to build apps following modern best practices with PHP tools. As prestashop 8.0 will be out on the next few weeks/months, I started thinking about prestashop pros and cons regarding developer experience and I would like to improve the experience developers have with prestashop. That’s why I need your opinion on this proposal before working on it.

Current situation

• We have a classes and a controller directory that can be modified directly by the developers, but it is known as a bad practice and is discouraged.
• The src/ code contains both some legacy/modern code and some bundle configuration owed by prestashop core.
• The src/ directory contains also Prestashop code and bundles that is not recommended to edit.
• As a developer on a PS project, if I want to add some project related code, I have no where to put the code but a module.
• We can have some internal code needed to run prestashop that should not rely on bc break, and it MUST not be updated.
• Inside the src directory, the namespace Prestashop\ is used

Proposition

• Move all the PrestaShop code and configuration that should not be edited to the vendor directory where I think it belongs under a prestashop/legacy package that will be required through composer
• Use src/ for all the code you are adding under the App\ namespace instead of the current Prestashop
• Modules / Themes / Bundles are unchanged, application configuration will not be updated.

I started a POC on this that can be found here

Impacts

Of course, if it was that easy it’ll be already done, so let’s have a look on impacts it can have

• Separate composer packages means separate repositories. Which means we have to either do PR on many repository and it can be a pain. but we can also (and this is what Symfony is doing) have a single core / bundles repository and sync them.
• All constants __FILE__, __DIR__ and other directory related constants must be updated
• BC Breaks of course, as always, as we move some files.
• The « core » code needs to be decoupled from the « app » code that users/developers are running (Prestashop version constant is in AppKernel and not in the core).

Advantages

• Update core without update distribution
• All code will be owned by the user and no more prestashop code will be commited.

This will now be possible:

• Allow developers to use git for their code only and not PrestaShop code
• Manage prestashop updates and deployments with composer.
• Allow third party apps to run PrestaShop code on a database without having the website running.

For module developers:

• Improve developer experience for modules developer by allowing them to test their modules with PrestaShop classes without having to install the whole project.
• Perhaps if some people are interested, find a way to use composer to require PrestaShop modules (free and paid ones).

For those who don’t need this: You can still continue to install & run prestashop as you did until today. The target of this PR is to only move some files.


Possible inconvenient

• Additional work to update many Github repositories at once, once a PR is merged (Symfony way)
• Prestashop/Prestashop will not be anymore the release project. Another project will be needed for the release.

[Amoifr]

The least we can say is that it's ambitious. However, I wonder about the practicality of having 2 repositories, as part of a migration, where we will take legacy code and port it to symfony. Will this involve 2 PRs (one per repository) which should be considered as a set?

[FabienPapet]

We may not need 2 PR, as the changes we make are both legacy/modern code, and this will only be repository.

The second repository will only be the release repository with the application configuration, constants, etc which is not modified often.

[abramofranchetti]

that's a lot of work to do but i think is a good idea.. but keep thing simple. over engineering the project could be a pain for prestashop developers that have to use all that. It will require an exhaustive documentation for devs for how use this and how this impact on modules and customization. Remember that a lot of customer choose prestashop because it is (was) customizable in front and backoffice (by prestashop partners and other software house). Now if there is not a hook or something customization is very very difficult. I thik that with your ambitious project prestashop could became more and more difficult to customize.. because all this sophistications. Remember that.