Contrib.social

[meta] composer require / install module discrepancy issues

Open on Drupal.org →
Created on 16 January 2025, 5 days ago

Problem/Motivation

Inspired by 📌 Dependencies should be 'unpacked' to the root composer.json and merged/resolved Needs review but I think there might be other situations that can cause a problem.

I did not do an extensive review of the codebase or issue queue

Steps to reproduce

Let's assume a fictional module, drupal/pathauto_extras

pathauto_extras depends on pathauto.

A site owner, who hasn't already installed pathauto, installs pathauto_extras.

At this point, project browser/package_manager will do composer require drupal/pathauto_extras adding it to the site's composer.json. pathauto will be added to composer.lock because it's an implicit dependency.

Later on, pathauto_extras gets marked obsolete because its features were merged into pathauto, the maintainer empties out the module except for absolute minimum, removing the pathauto dependency in the meantime.

The site owner updates to the latest version of pathauto_extras, and now pathauto gets removed from their code base, because it's no longer a dependency of anything.

There is another issue, which probably would need similar underlying infrastructure but is in the opposite direction:

Let's say the owner doesn't like pathauto_extras and uninstalls it, at this point pathauto will still be installed.

Then later they want to update to Drupal 12, but pathauto_extras doesn't have a 12.x compatible release.

In this situation with cli composer, I would just run composer remove drupal/pathauto_extras and be done - as long as I'd verified it was uninstalled. If you only maintain your site with project browser + automatic updates, this isn't yet an option. It suggests the need for a 'remove' page, where you can actually remove dependencies from composer, when they're not in use.

Proposed resolution

Either of the above cases would require being able to match Drupal modules to projects, which Drupal core doesn't have any support for outside of update status - possibly the update status metadata would be the way.

When a module is installed, we could check which composer project it's in, and whether that composer project is in the root composer.json, and if it's not composer require it at that point to make it an explicit dependency of the site.

Conversely, if we have that logic, we can also show which uninstalled modules are eligible for composer removal (e.g. no modules from a project are installed).

🌱 Plan
Status

Active

Version

2.0

Component

Code

Created by

🇬🇧United Kingdom catch

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @catch
  • Comment 5 days ago →
    🇬🇧United Kingdom catch
  • Comment 5 days ago →
    🇪🇸Spain penyaskito Seville 💃, Spain 🇪🇸, UTC+2 🇪🇺

    > Later on, pathauto_extras gets marked obsolete because its features were merged into pathauto, the maintainer empties out the module except for absolute minimum, removing the pathauto dependency in the meantime.

    For the first case: A responsible maintainer wouldn't remove the pathauto dependency in the meantime. That's a bug in pathauto_extras, and they need to create a new release with the dependency back.
    If in that frame of time someone upgraded, that would remove the pathauto dependency, which would cause a WSOD if I'm right? We might want to check if a module is uninstalled before removing it with composer.

    > There is another issue, which probably would need similar underlying infrastructure but is in the opposite direction

    The second case is a very good valid point.

    The Proposed resolution would fix both cases IMHO.

  • Comment 5 days ago →
    🇪🇸Spain penyaskito Seville 💃, Spain 🇪🇸, UTC+2 🇪🇺

    There are some edge cases (drupal module + composer packages having different name, composer packages with several modules) that we might need to cover. Not sure how we can track which packages provide which modules.

  • Comment 5 days ago →
    🇬🇧United Kingdom catch

    @penyaskito I think the first case could be simplified to 'any release of any module that removes a composer dependency on another Drupal project'. Not at computer but can update later.

  • Comment 5 days ago →
    🇬🇧United Kingdom catch

    Updated the issue summary to be a bit more generic, I think that shows that both examples can be valid.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024