I take several month to make this answers. But it is a sensible topic, so i have to compile a lot of point of view to make the good answer.
Well, does a user has to deal with the libraries dependencies of an application ? A « developer » user yes, and non technical end user, no.
In Dolibarr, all required libraries are embedded with a combination that is guaranteed by the project and the Continuous Test Integration platform.
Only the combination provided by dolibarr project and tested by continuous integration and beta sessions can be supported. Changing one version of an external libraries breaks dolibarr 90% of time, so it is not recommended to manage each library version independently by yourself. Most users and integrators should not have to think about this : This is the job of the software editor not he user. Dolibarr is one and only one package that works with no need for extra libraries. This is same philosophy than the new generation of packager (like snap, flatpack) are working now (thanks to them to save time of users and integrators).
Old way of working using automatic dependency download and even downloading sublibraries not required is just a dangerous way of working. It is great on a developer station. But Dolibarr packages are designed for users, not for developers.
Lets take the example of the debian package that was officialy integrated into debian :
Debian packaging is a similar system than composer in a sense that it uses an old school packaging system (where each components has a version minimum and each application is built by adding tons of other components according to automatic dependencies definition). This system creates tons of dependencies on very large projects and of course each micro-libraries evolves without taking into consideration the projects that consume/use them, above all when the project is a project that consume a project that consume another one that consume another one, etc… We did provide an official Dolibarr debian package that was officially available in debian distribution, but after spending a lot of money (several thousands of euros workign with the most famous official debian packagers and debian leaders’ companies) and after several years of work, the conclusion was that is was not possible to provide an official debian package that is as secured and as easy to install and to maintain than the « standalone dolibarr package » with same level of features (a standalone package is packages using the new generation of package policy, that does not depends on the external environment or on a dependency tree that changes on each different station each time a sub library change. a standlone package is just a package that match 100% like the editor wants, with even 1 byte of difference). Such standalone packages just always works whatever is the system your install on it, whatever are the changes done on external libraries done by libraries maintainers and it does not change nothing on what is already installed, keeping all existing application working the same way with a 100% guarantee. The only solution to keep the same quality with the debian old school packing compared to a autonomous packaging that embed all dependencies was to become the maintainer of packages of all dependencies Dolibarr depends on. The debian project encourages us to do it. So we did it !
And we become the packager of debian TCPDF library for example, then we add to become also the packager of some javascript libraries, and then another one, etc… Even by becoming the official packager of project developed by other team (this was stupid yes, but we have to do it to guarantee that packages combinations was working together), we had to removed a lof of feature in Debian official package because the combination of libraries provided by dependencies tree was not the one we need, some features were missing or broken when each libraries were used together in same application. Also size of installed application become enormously ridiculous due to the ton of dependencies installed, that nobody need/want. And i don’t speek about security (the more you add library your don’t need, the more you introduce holes).
We finally stopped the objective to provide official package into a debian distribution where dependency were managed by an external system. I pushed myself the project in this direction and we failed. We have earned.
Now we provide a debian package where all dependencies are embedded in the Dolibarr package, dependencies are the result of the choice of the project and only the choice of the project. All files are validated and tested by automatic integrity platform of official project and also by beta releases and testers. There is even 1 file we don’t want/need. We saved so much time doing like that (several hours of work each week during several years, only for myself), solve so many problems we got, without seeing any disadvantages, that I still don’t known why we keep so many years to try to use a dependency system where we don’t need.
Yes, composer is a little bit better than Debian dependency system (for example, each application can install its own version of library, we have more choice/option to force range of version we want/need), but it is an example to explain why a « multi-level dependency » can be bad for a very large project. The size of a Dolibarr project is nearly doubled due to stupid and unwanted dependencies. Combination of libraries we need is often just not possible to install due to dependencies conflict on sub-libraries of such libraries, and this sub libraries that are in conflict are even never used in our project context ! Why installing them ? We just introduce bugs, security holes and e have different installation with different combination of subversion of libraries that was not the one tested and qualified ? We want this on a developer station but we want this opposite on and end user stable production server.
We made an error with Debian package trying to persist several years, spending a lof of money, we won’t make same error with composer and we won’t persist after seeing all the bad effect that an « automatic dependency package system » brings even if this is a good tool for a developer station), with no gain. So composer experience has also been abandoned. As often, it is the proof of the experience that rule on Dolibarr (we test both and we keep what is better). May be we will try it again later, but, currently 99% of NOT experienced users install Dolibarr with an « autoinstaller » dolibarr package (doliwamp, dolideb, dolirpm, …), composer is not able to make what such package do (like installing a full webserver or editing windows registry), and most experienced users and integrator (at least among the one i can speak about) are using « git clone » with a so higher satisfaction compared to composer that the task to provide a composer package again is now a very low priority. More suitable solutions like « snap » or « flatplack » seems more interesting but let’s see how contributions evolves and package system popularity evolves. All contributions are still welcome if they brings more pro than cons, but currently composer brings more cons than pro. But things can change quickly in the computer world.
About the integrity check of a Dolibarr installation, there is also a native integrated feature of Dolibarr to check this (into home - setup - dolibarr - file integrity) and this check includes external libraries, so if you change a library with a version that is not the one expected by project, you can, but Dolibarr can detect your are using a not validated/tested combination (one byte modified in one file is enough) and the file integrity checker will report it. This feature can be used by any not technical user from the graphical interface, it is often enough for a user. For integrator using git, the git status can also do it. Of course both methods are always available and can be combined, for a best world !
The questions of external module is different. The compatibility of a module with a dolibarr version is guaranteed by the module developer not by the Dolibarr project, and the developer has the feature into the dolibarr module installation process to guarantee that its module is not installed if it does not follow the Dolibarr version the module developer has validated it for.
