Add a module and theme uninstall command

I would like to suggest that old aliases are not included, so that only ex:uninstall and its alias exun are available.

$ dr ex:uninstall -h
Description:
  Uninstalls one or more modules or themes.

Usage:
  ex:uninstall [options] [--] <extensions>
  exun

General help

$ dr
[...]
 ex
  ex:uninstall      [exun] Uninstalls one or more modules or themes.

Assigning to me.

Ready for review. Closely matches the code flow and UX of the new ex;install command.

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.

Ok I manually ran through the following test scenarios similar to the install command tests:

With CLI

• I uninstalled a module by itself - Worked
• I called two modules, one already uninstalled - Worked
• I uninstalled a theme - Worked
• I uninstalled a module with dependencies - Worked
• I uninstalled an already uninstalled module - Worked
• I uninstalled a theme with subtheme dependencies - Worked
• I uninstalled a theme with module dependencies - Worked
• I uninstalled a module and theme at the same time - (gave appropriate error)
• I uninstalled a profile - Worked
• I uninstalled an experimental theme - Worked
• I uninstalled an experimental module - Worked
• I uninstalled the default theme - (gave appropriate error)

IN UI

• I uninstalled a module by itself - Worked
• I called two modules, one already uninstalled - N/A
• I uninstalled a theme - Worked
• I uninstalled a theme with subtheme dependencies - N/A
• I uninstalled a theme with module dependencies - Worked
• I uninstalled an already uninstalled module - N/A
• I uninstalled a module and theme at the same time - N/A
• I uninstalled a profile - Worked
• I uninstalled an experimental theme - Worked
• I uninstalled an experimental module - Worked
• I uninstalled the default theme - N/A

Happy to report that everything worked!

@godotislate mentioned in slack that main is now for criticals and 12.x only for a bit so I think this won't get in until 12.x beta is out which means we'll need a separate CR for this.

The test still needs to be moved to the Extension test namespace.

I had wondered if some of the command code can be refactored into helpers since it looks like a few chunks are almost identical. I think that might be premature since this is only the second use, and there are enough minor differences that it could be painful.

The Needs Review bot is again defacing issues by moving the status to Needs Work and attaching a file "Patch fails to apply". We dont use patches anymore. Also, the MR is mergeable as seen on this issue and on the MR itself.

If someone could review this that would be appreciated.

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.

There is something weird going on for sure.

I pulled the diff down https://git.drupalcode.org/project/drupal/-/merge_requests/17083.diff and created a patch from it.

When I apply that to main I get an error:

error: core/modules/system/src/Command/ExtensionInstallCommand.php: No such file or directory
error: core/modules/system/tests/src/Kernel/Command/ExtensionInstallCommandTest.php: No such file or directory

If you look at the diff it still references those files even though the MR doesn't appear to, I think gitlab or fastly is caching something incorrectly.

For the record the bot says patches, but it's using the MR as well.

Git has smarts to know about file moves/renames and all sorts of things. Thats why MRs stay green longer than patches too. Now that we have change proposals in git, I dont see value in knowing whether a derived patch would apply cleanly. I wrote about this 10 years ago.

The process of a core commit involves applying the .diff to the codebase, that's why the bot test for that. Bot is here to make sure a RTBC issue is committable at all times, without relaunching a unreasonable amount of CI test runs, which is why it doesn't trigger a rebase automatically either.

Ok I rebased, we still need the CR I think.

I am at DrupalCon Rotterdam 2026, today I will be working on this issues. My mentor is Ekes.

I have written a change record for review on this issue.

@mradcliffe, I added the description for CR according to https://www.drupal.org/node/3623057/ example

This issue is now held up on a change record on an interface which virtually noone has ever extended. And will that person actually find and benefit from this CR? If someone finds an issue with an MR, it would be ideal if they made the accompanying change in order to keep it moving forward. Thank you.

Repurposed the change record - onwards

This issue is now held up on a change record on an interface which virtually noone has ever extended.

Yes, we still need a change record though.

I updated the change record a bit, I think it's good to go.

If someone finds an issue with an MR, it would be ideal if they made the accompanying change in order to keep it moving forward. Thank you.

People can do that, but then it generally removes their ability to RTBC cleanly, it's usually better for one person to take point.

In any case I think this is ready!

> People can do that, but then it generally removes their ability to RTBC cleanly, it's usually better for one person to take point.

Thanks for moving this along.

IMO its a bug in the policy if we are preventing or disincentivizing a person from making a fix when they see a problem in an MR. We should prioritize forward progress, not high fidelity to a peer review flow. It is still within the spirit of our workflow to make improvements AND provide the RTBC. Remember, rules are meant to be broken (wisely).

Manually tested

71faf1f882de:/data$ dr en -y comment
The following module will be installed:
 * Comment (comment)


 [OK] Successfully installed 1 module.


 * Comment (comment) — Help, Permissions, Configure

71faf1f882de:/data$ dr pmu comment
The following module will be uninstalled:
 * Comment (comment)


 [OK] Successfully uninstalled 1 module.


71faf1f882de:/data$ dr en -y history
The following module will be installed:
 * History (history)


 [OK] Successfully installed 1 module.


 * History (history) — Help

71faf1f882de:/data$ dr pmu history
The following module will be uninstalled:
 * History (history)


 [OK] Successfully uninstalled 1 module.

Works like it says on the tin

I wonder if we have plans to support variadic arguments rather than a csv list?

71faf1f882de:/data$ dr pmu node stark

  Too many arguments to "pmu" command, expected arguments "extensions".

Tested a few other scenarios

71faf1f882de:/data$ dr pmu node
The following module will be uninstalled:
 * Node (node)

The following additional module will be uninstalled as a dependency:
 * Taxonomy (taxonomy)

 Uninstall 1 additional module as a dependency? (yes/no) [yes]:
 >

Committed and pushed 3b94128e929 to main. Thanks!

Published the change record