Problem/Motivation

Issue generated (with AI help) from Slack conversation here:
https://drupal.slack.com/archives/CJ93UNJP4/p1781812326340959

The drupal/genpass package currently relies on Drupal.org package metadata to populate some Composer dependency information from the module's .info.yml file.

This can make Composer resolution harder to reason about, especially when Composer recalculates available updates across different Drupal core versions. Composer itself does not understand Drupal.org's supported release state, and package metadata added by packages.drupal.org can affect what Composer sees as installable.

Adding explicit dependency constraints to composer.json would make the package metadata clearer and reduce reliance on Drupal.org's Composer facade.

Steps to reproduce

  1. Use a Drupal 10 site that has drupal/genpass installed.
  2. Run composer outdated.
  3. Notice that Composer may report drupal/genpass 2.2.0 as an available update.
  4. Run composer why-not drupal/genpass 2.2.0.
  5. Composer reports that drupal/genpass 2.2.0 requires drupal/core (^11.3 || ^12).

Proposed resolution

Update composer.json so the module explicitly declares its Drupal core compatibility and other Composer-managed dependencies, instead of relying on packages.drupal.org to infer them from .info.yml.

This should make Composer behaviour more predictable and align the package with the longer-term goal of contrib projects managing their own Composer metadata directly.

Remaining tasks

  • Review the current .info.yml dependencies.
  • Add the equivalent explicit constraints to composer.json.
  • Confirm the constraints match the intended supported Drupal core versions for each branch.
  • Run Composer checks against supported Drupal versions.


Need maintainers input but I'd suggest explicitly making a 2.2.1 so that the newer packages will start on that feature branch (instead of accidentally getting there with composer)

API changes

None expected.

Data model changes

None expected.

Issue fork genpass-3604931

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

joelpittet created an issue. See original summary.

joelpittet opened merge request !55

joelpittet’s picture

joelpittet
he/him
Primary language English
Location Vancouver
commented
Status: Active » Needs review
elc’s picture

elc commented

I can see the benefit of this. Ironically, I've had the explicit Drupal version support removed from the composer.json in a number of modules because they'd managed to mix up support with .info.yml showing one core support and composer showing another. The simplest way to fix it and stopping it from happening again was the rely on the magic.

The 2.2.x branch was a mistake. As soon as I released it and a Drupal 10 site composer offered it up as an upgrade option I knew I should have moved to a new major number which was the 3.0.0 release.

Continuing on the conversation in Slack, it seems the best way to solve all of the issues with 2.2.x branch, would be to revert all of the commits back to 2.1.x equivalent, and make a 2.3.x release to gather everyone on 2.x release into a correct release, and mark 2.1.x as unsupported after a few weeks.

#3605388: Supersede defunct 2.2.x branch

I think this also removes the need for the composer.json explicit versioning by fixing up my screw up on versions. At least until it is explicitly required as the magic means less chance of screw up with updating the info.yml and not the composer.json.

elc’s picture

elc commented
Status: Needs review » Postponed

Going to postpone this for now, hoping that the 2.3.x release will fix how composer handles providing a next available version.

joelpittet’s picture

joelpittet
he/him
Primary language English
Location Vancouver
commented

Totally reasonable to postpone, and your logic in #4 to let the magic sort it out, makes a lot of sense. I am curious to see how this all pans out 🪎, as it might change how I handle my composer.json in projects I maintain.

elc’s picture

elc commented

This appears to be working like it should and adding the explicit requirements is not be needed.

~78% of the 2.2.x sites have upgraded to 2.3.0, although only ~10% of the 2.1.x sites have upgraded yet.

Still going to leave 2.1.x supported for another 2 weeks as that hasn't moved that much. Perhaps it is the fact it is still supported that is holding updates, but there really is no rush.

elc’s picture

elc commented
Status: Postponed » Closed (won't fix)

A large swathe of the 2.1.x users have upgraded so have marked it as unsupported after a month now.

Composer is suggesting the correct versions for everyone now without needing to explicitly include which versions are supported as the magic inclusions are working like they should now. I just need to remember to follow the semantic release and Drupal's suggested rules for release number when dropping a currently supported core.

Going to close this as won't fix.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

joelpittet’s picture

joelpittet
he/him
Primary language English
Location Vancouver
commented

Thanks for jumping on top of this when I ran into it. These type can be tricky to look at as time goes because things move on the packaging side shift too(potentially)