Language and development rules: Difference between revisions

* First, you must understand that composer is a tool '''to deploy a frozen image of a package'''. It is a tool to '''deploy''', not a tool to '''manage dependencies''' (event if some features exists for that). Dolibarr is an application that has a lot of dependencies, but for each of them, the Dolibarr project has to apply some patches to have the dependencies working correclty (for different reasons, mainly because of bugs or architecture error into original project. See the file '''dev/dolibarr_changes.txt''' for full list). Each PHP dependency has at least one change to do to have it working correctly. So the image of a library L that Dolibarr needs is NOT the image provided into the composer package by the L project. After discussion with '''Nils Adermann''', the author of the composer package during the first OSFS congress (https://05f5.com) to get its point of view on this need for large projects, it appears that if a large project is in this situation, the good way to use composer is to build yourself a very large package called "dolibarr" with no composer dependencies and all external libraries embedded into the same composer project so we can deploy all in one composer command, confirming that composer is above all a good "fast deployment system" but a bad "dependency manager". The dependency system of composer project was simply designed to use an exact version of a library and not to use a patched version of this library. It is even designed to avoid this, making its use not possible in this context.

* Second point is a different problem with the composer dependencies system: Each dependency on a library has itself a high number of sub-dependency. And all this sub-dependencies have also a high number of dependencies that nobody can't control (there is always sub-dependencies on the libraries you use that are managed by a lower level dependency project). The result is that when you use composer to install the main library you need, you install (and you can avoid it) a ton of other packages you don't need. For example, Dolibarr is a 80Mb project with all its PHP dependencies. If you install it with composer (we suppose that the first point is not a problem), then the project reach the size of 300 Mb. Size of project is multiplicated by 3.5 with no reason.

* Last point is about security: As we view in the second point, when using composer, a very high number of PHP files are installed even if you don't need them. Dolibarr is a critical application that need a very strict security policy. Requirement for security is at a high level (See our page [[Security_information]]). When using composer, you install a lot of files and small sub-project and sub-project of sub-projects where security is not considered as important than what we need on the Dolibarr project. If we make an analysis on a given period, the number of vulnerability reported on the whole project Dolibarr + files of external libraries when installed by composer (that we mostly don't need) is multiplicated by 20 compared to the number of vulnerabilities that are reported only in the scope of Dolibarr + external libraries when they are embedded in their minimal version manually). Such an increase is simply not possible and a some companies would simply not be allowed to use Dolibarr if we accept these due to their strict security requirements.

As we can see, composer, even if it was largely adopted by a lot of small projects, is far away from the state of the art. For all this reasons, it is just not possible to use composer so we keep the composer.json file in the project so we can use it for some development tests or make upgrade tests of some libraries with it, but we have renamed it by adding the extension ".disabled" to be sure that end users won't try to install or update their Dolibarr with it (in which case, the application will become unsecured and unstable).