[StimulusBundle] UxPackageReader class doesn't support projects with varied structures using Composer with custom directory structure

[yobrx]

Q	A
Bug fix?	yes
New feature?	no
Issues	no
License	MIT

Hello,

I've encountered an issue with the UxPackageReader class within the Symfony UX package, where it fails to accurately detect package existence in projects that have a structure differing from the standard Symfony application structure, despite these projects using Composer for package management.

Description of the Issue

The UxPackageReader class appears to be designed with a certain project structure, which works well for typical Symfony applications. However, in projects that deviate from this structure (for instance, microservices or applications with a modular architecture), the class does not effectively locate and read the Composer-managed packages.

Specific Scenario

To give a concrete example, my project consists of multiple directories at the root, each representing a sub-project within a larger ecosystem. These sub-projects are designed to have their own vendor directory for autoloading purposes. However, all Composer packages are installed in a shared vendor directory at the root of the project. This setup is beneficial for my project's architecture but unfortunately, UxPackageReader is unable to recognize the packages in this unique structure.

Example :

app1
|- vendor
  |- composer
    |- autoload-*.php -> reference files to ../vendor/
    |- ... and other files of composer
app2
|- subapp1
  |- vendor
    |- composer
      |- autoload-*.php -> reference files to ../../vendor/
      |- ... and other files of composer
|- subapp2_legacy
  |- vendor
    |- composer
      |- autoload-*.php -> reference files to ../../vendor/
      |- ... and other files of composer
vendor
 |- symfony
   |- packages
     |- v6.3
       |- _files of package_
     |- v6.4

Proposed Solution

To address this limitation, I have implemented a workaround by utilizing the InstalledVersions class from Composer, whenever it is available. This class offers a more robust and flexible way to check for the existence of packages, as it does not rely on the project's directory structure but instead directly reads from Composer's autoload mechanisms and installed packages metadata.

Suggested Changes

I suggest that the Symfony UX team considers integrating a similar approach into the UxPackageReader class. By leveraging InstalledVersions or an equivalent method, Symfony UX can enhance its compatibility with a broader range of project structures that use Composer, thus increasing its versatility and usability.

This modification would not only resolve the issue for projects with unique structures but also align the package detection mechanism with Composer's native capabilities, ensuring a more consistent and reliable detection process.

My solution is not testable because it uses Composer class with static methods. Therefore, I was unable to write tests for it. However, I am open to any suggestions for improvement.

[weaverryan]

Thanks @yobrx!