Add a composer plugin that supports 'composer require-lenient' to support major version transitions

I have struggled for weeks now upgrading sites to D10. A fresh install worked on one site, but generally I want to upgrade. All my modules are either upgraded or patched (using cweagans/composer-patches). But this still does not work. So I tried composer-lenient, and the laminas package installed by upgrade_status still stops the upgrade. It should not be so difficult. Users should not have to munge around in composer.json.

A fundamental flaw in Drupal is that a small change can give a php error that kills the site, and sometimes even a db restore does not work.

Module patches sit unreleased for months. Drupal.org needs to push developers to at lease release dev versions immediately that a patch works.

It looks to me like there's a majority for relaxing the recommended core_version_requirement, which I agree with. (I recently created and closed the duplicate issue ✨ Always allow downloading and installing contrib module dev-release in next major version Closed: duplicate ).

I really like @japerry's method outlined in Navigating core_version_requirement, and think it would sense to make this the recommended model:

What should core_version_requirement look like?

My personal preference is to work with the next ‘beta’ of a major version. That allows developers to immediately work with a module, but doesn’t allow it to automatically work with the next stable release:

If your module supports Drupal 8, 9, and 10:
core_version_requirement: >=8.9 <11.0.0-stable

If your module supports Drupal 9 and 10:
core_version_requirement: >=9.2 <11.0.0-stable

This could reduce future contrib module upgrade bottle necks, and allow contrib modules to be easily installed and worked on in the next official major release while it's underway, but not yet released.

In the issue summary's "Proposed resolution" section, it is still proposed that an open constraint (>=) is used as the core_version_requirement. IMHO, this is a bad idea, for all the reasons pointed out by Kingdutch, cmlara, Berdir and Pasqualle. I think this link: Why are unbound version constraints a bad idea? bears repeating.

However, when reading the discussion, my interpretation is that consensus gravitates towards adding the Lenient Composer Plugin → as the preferred solution.

Perhaps the "Proposed resolution" section of the issue summary needs updating?

Installing and configuring a Composer plugin is easy for developers (the majority of users in this issue), not so much for the Drupal beginner. As @xjm puts it, and I agree with:

Using >= will put the power in the hands of site maintainers if they want it. Might the module still be broken? Sure, but then they're no worse off than they were. And there's a 50% chance it will just work (see Gábor's data above about D9 projects), and tools like Upgrade Status can warn the site owners if there are problems.

It's the right choice for the sustainability of contrib, for the major release cycle going forward, and for making upgrades easier for site owners, which is our top priority for Drupal.

I think we need to discuss the option of using a "Range Constraint", with a minimum and maximum Drupal core, for example:

core_version_requirement: >=9.2 <11.0.0-stable

I agree that installing and configuring a Composer plugin may not be easy for inexperienced developers. That's just the way it is. If they're that inexperienced, maybe they're better off not using unstable versions?

You quote @xjm's argument from comment #24, that says:

Using >= will put the power in the hands of site maintainers if they want it.

Unfortunately, if an unbounded version constraint is used, the site maintainer will get this "power" whether they want it or not. The version constraint is not something the site maintainer can control, it is put into the project's .info.yml by the project maintainer.

And IMHO, the "power" they get is akin to a shotgun aimed at their own foot. Yes, it gives them the "power" of being able to easily install the dev-version of an unmaintained project on their website, but if it blows up due to unhandled deprecations, they're stuck with a WSOD. And if they are inexperienced, maybe they shall not be able to recover from that.

To me, the downside of increasing the risk of the site breaking outweighs the upside of letting site maintainers easily install an unmaintained project that just might work anyway.

I think we need to discuss the option of using a "Range Constraint"

Using a Range Constraint with a minimum and maximum is not an Open or Unbound version constraint. It requires the project's maintainer to explicitly declare the upper bound of compatibility. It will not let users install the project on the next major version of Drupal unless the project's maintainer intervenes and changes the maximum constraint to certify compatibility with the next major version of Drupal. Using Range Constraints are a nice idea, but this idea is perpendicular to the problem discussed in this issue.

We could consider adding the composer lenient plugin to core, then it's available to everyone who installs core. It would still be opt-in for installing particular extensions, it doesn't take over everything, just the things you explicitly tell it to install (iirc).

That's a great suggestion @catch. It would definitely be a step in the right direction, towards making it easy to download a contrib modules in the next major release. The user still needs to define the allowed modules, and also patch the *.info.yml file, and add || ^11 though ...

Ideally, to lower the bar of entry for new Drupal users, and just overall make it easier to run modules in the next major release, if the Lenient plugin was added in Drupal Core, it would be fantastic if a new Leniency toggle feature was added, allowing both the download of any module with Composer, but also a subsequent installation in Drupal 11:

composer config extra.drupal-lenient.allow-all true

After running this command, a module with core_version_requirement: ^10 should be able to be downloaded, as well as installed in Drupal 11.

It could also be split into one setting for downloading via Composer, and one for installing in Drupal:

composer config extra.drupal-lenient.allow-download-all true
composer config extra.drupal-lenient.allow-install-all true

It sounds like the core_version_requirement in the module should just be deprecated in favor of composer.json constraints, period.

Thanks for sharing your opinion @mglaman, I added it as an option in the Issue Summary, and in the "Persona | Site owner | Maintainer" table together with "Open Constraint >= 9", since those two options share a lot of traits.

Should the title be updated to something like "Make major version transitions easier"?

📌 Add Drupal 11 support Needs work :)

A small update in the CSS and adding || 11 under the core_version_requirement's, and Admin Toolbar works well in Drupal 11.

Since people are linking to this issue as justification to put open ended version constraints like ">=9.0" in their contrib module composer.json files, I think we should better explain the dangers of doing this in the issue summary.

Folks here might already know this, but I only recently learned (via a Bun.js release announcement) that npm supports an overrides field and yarn supports a resolutions field that let you achieve what the composer-require-lenient plugin lets you achieve. I think this adds to the argument that Composer itself should add similar functionality upstream, but if they don't want to, I'd support #74's suggestion of adding it to Drupal core.