Removed modules should be included as a replace in composer.json

catch suggested this be done for all the module removed

https://www.drupal.org/docs/core-modules-and-themes/deprecated-and-obsolete

It would be for the extensions removed in Drupal 12, #3488826: [meta] Remove deprecated extensions from Drupal 12
So far that is Ban, Contact, Field Layout and History. Although the last three still fail to pass manual testing of the upgrade path.

Cross-referencing #3580635: Can't update to 1.0.6 on Drupal 10, this now also affects forum module due to the generated history dependency and in turn affects testing of pathauto and metatags and that also affects 11.2 (previous minor). There is a possible workaround to lock down the dependency to a release before the updates were made to drupal.org, about to test that.

I'm suggesting to raise this to major. previous minor testing means this also affects 11.2, at least for history module.

I would suggest going further, and undo #3292380: Remove the "replace" section from core/composer.json.

As it stands right now older releases are also being tampered with, while core may not support itself on older deployments this is likely breaking unsupported released can hinder evaluating long-lived issue reports that may require deploying old core versions to validate a feature functionality.

Additionally there is a high likelihood of this issue being forgotten again when modules are deprecated again in a future major (such as D13) since this issue was already forgotten from the past with D9.

Revering to the old system and removing the replaces when deprecation occur would reduce the likelihood of these faults impacting maintainers again in the future.

Additionally I opened #3582324: Deprecate facade magic for removal with D13 for the future, if infra didn't manipulate package metadata this would have been less impactful against contrib.

We all need to remember that Slack will not always be available and conversations there should be summarized and the participants named here on the issue. That way we have a record of the conversation and can add credit to those who helped in Slack.

I tested this by cloning 10.6.x. After configuring DDEV, I ran composer install to get the core dependencies.

I tried requiring a module that wasn't previously a Core module, inline_entity_form for the record, just to make certain that it was working correctly. There were no issues. Composer placed it in the modules/contrib directory.

After that, I attempted to clone the four replaced modules. All four had entries added to the composer.json file. But no JSON for them was added to composer.lock. Only the lock file's hash was updated. Nothing was downloaded to the modules directory. This was the expected behavior. So it appears that the replacements are working correctly. I have no feedback. It looks good to me.

Working on the stable9 split now so not sure when we add to the list?

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

So I've done the stable9 and telephone deprecations and contrib releases since this. Is this a blocker from getting tickets like https://git.drupalcode.org/project/project_composer/-/work_items/3583681 fixed? Telephone download is saying telelphone-telephone right now.

#3188544: [policy discussion] Address Composer namespacing issues when extensions move between core and contrib appears related as it discusses module naming/investigating how to streamline.

This isn't blocking but we should still do it asap.

Since the replaces is harmless we should do it here for every module we know we're removing in 12.x

We may need a few target branches here. Ban needs to go in 11.1 and below , telephone in 11.3 and below, etc.

Apart from Telephone (drupal/telephone-telephone), these two other core-to-contrib projects also use a wrong Composer name, and need an update:

• drupal/shortcut-shortcut
• drupal/toolbar-toolbar

Moving this up to 11.x. We should do this for search/toolbar in the 11.4.x branch at least since those aren't removed yet but will be by 12.0

I added the modules I know are getting removed in D12 to the summary. Could we add what branches each need to land in because as @mstrelan mentioned sounds like we will need branches for a number D11 releases.

I think we should start with MRs for 11.x (11.5), 11.4.x, and 10.6.x

11.3.x is technically only on security support now, but we could consider a bonus patch release since it may make security updates easier, or bundling the commit into a security release if/when it next happens. Let's handle that after the other branches though.

We won't do any further releases of 11.2 or 11.1 and sites on those should be updating to 11.3 or higher next time they update anyway.

Opened a 11.x MR with everything. Could we merge that and see what backports well before I do the other branches?

This is tricky because a site on 11.3 might already be using https://www.drupal.org/project/contact and if we add the replace to 11.3-5 for contact it would force them back to the core version.

To minimise unexpected changes in both directions, I think we probably want to only put search, toolbar etc. in replace for 11.4 and 11.5 - e.g. the modules that don't have contrib versions yet/aren't deprecated in the version. And those changes would also need to be backported to 11.3 assuming we do the bonus release.

For 10.6 we can and should put the full list though.

So I should close the 11.x?

@smustgrave I think we should probably have 11.x and 11.4.x the same, and then when we actually remove a module from main and it has a stable release in contrib, and extra step could remove it from replaces.

Technically it doesn't hurt if e.g. search module on 11.x keeps a replace entry, because it'll still be available in core, but it's easier for a site owner to add their own replace entry than it would be to circumvent one (not even sure how to do that).

So can the current MR be merged to 11.x and 11.4 if it backport?

People are noticing the duplicate name on contrib not sure if it’s going to be a problem for them later

@smustgrave see #31:

I think we probably want to only put search, toolbar etc. in replace for 11.4 and 11.5 - e.g. the modules that don't have contrib versions yet/aren't deprecated in the version.

Updated summary with modules that have releases and those that don't

Okay opened a 10.6.x branch with everything
11.4.x MR with just search, shortcut, settings_tray, and toolbar
11.5.x isn't created yet.

What about main?

Updated the 11.x MR to match 11.4.x

I'm not sure though how this will fix the releases we already got that are showing stable9-stable9 for example?

That's d.o packagist and there should already be infrastructure issues for these in at least some cases. Not something to worry about here.

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Rebased 11.x branch.

Let's get this in.

Committed and pushed 4bc9f7c to 11.x and 76b6eee to 11.4.x.

I had a couple suggestions on the 10.6.x MR about removing the allowed plugins entries, which I don't think should be there at all. I've applied them, but it might need a composer.lock update. Pulled down the diff and composer.lock did not change after composer update --lock.

Think I should get a +1 on the 10.6.x change before I commit.

Last commit on 10.6 looks right - we shouldn't be changing that here.

Committed 9a68ba6 and pushed to 10.6.x. Thanks!

No change yet:

$ composer create-project drupal/recommended-project:10.6.x-dev "install-dir"
$ cd install-dir
$ composer require 'drupal/crowdsec:^1.1'
./composer.json has been updated
Running composer update drupal/crowdsec
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Root composer.json requires drupal/crowdsec ^1.1 -> satisfiable by drupal/crowdsec[1.1.0-beta1, ..., 1.2.x-dev].
    - drupal/ban[dev-1.0.x, 1.0.0, ..., 1.0.x-dev] require drupal/core ^11.2 || ^12 -> found drupal/core[dev-main, 11.2.0-alpha1, ..., 11.x-dev, 12.x-dev (alias of dev-main)] but the package is fixed to 10.6.x-dev (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
    - drupal/ban[dev-1.1.x, 1.1.0-beta1, ..., 1.1.x-dev] require drupal/core ^11 || ^12 -> found drupal/core[dev-main, 11.0.0-alpha1, ..., 11.x-dev, 12.x-dev (alias of dev-main)] but the package is fixed to 10.6.x-dev (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
    - drupal/crowdsec[1.1.0-beta1, ..., 1.1.x-dev] require drupal/ban * -> satisfiable by drupal/ban[dev-1.0.x, dev-1.1.x, 1.0.0, ..., 1.1.x-dev].
    - drupal/crowdsec[1.2.0, ..., 1.2.2] require drupal/core ^11.2 -> found drupal/core[11.2.0-alpha1, ..., 11.x-dev] but the package is fixed to 10.6.x-dev (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.
    - drupal/crowdsec[1.2.3, ..., 1.2.x-dev] require drupal/core ^11.2 || ^12.0 -> found drupal/core[dev-main, 11.2.0-alpha1, ..., 11.x-dev, 12.x-dev (alias of dev-main)] but the package is fixed to 10.6.x-dev (lock file version) by a partial update and that version does not match. Make sure you list it as an argument for the update command.

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.

Installation failed, reverting ./composer.json and ./composer.lock to their original content.

I believe we actually want this added to core/composer.json since that is the subtree split that’s installed as part of recommended-project. And the modules are contained within core/modules/ too.

Agree with #55, this needs to go in core's composer.json, the top level one is only used for core development. Will revert them all so we can try again.

ComposerIntegrationTest.php was failing so I changed that to simply filter out the replaces extensions.

new MRs LGTM.

OK, try two.

Committed and pushed 2d50129 to 11.x, e74b946 to 11.4.x, and 56ced95 to 10.6.x. Thanks!

Excellent, my test from #55 installs crowdsec cleanly now.

I recommend including all core components, the submodules & themes, for all core branches. That way a component can be removed at any time, and the existing releases all know what components they still have.

Related fallout #3616198: The existence of this forces D11.4 upgrade not so much due to the replace, but more related to the practice of having the contrib module's core_version_requirement try to reflect when it left core, instead of what version of code it works with.

As a followup, every core component should be included in replace the same way, not just the ones that are planned to be deprecated. That will ensure even older sites know what core components they have, and removes a step from the deprecation/removal process when there are more.

To address #74