drush en incorrectly reports that it enabled new dependency modules

[rwalkerands]

Describe the bug
Let's say you use composer update, and one of the modules that gets updated, say, abc, was already enabled in Drupal, but it now has extra module dependencies ghi and jkl (specified in its composer.json and in the dependencies entry of its .info.yml file). Then the new dependencies are downloaded, but not automatically enabled in Drupal. This is already a known problem, and it seems drush can't help; e.g., see https://drupal.stackexchange.com/questions/77533/enable-new-modules-dependencies-on-deploy/78138 and https://www.drupal.org/node/1436550 . (On this point, I would be very happy to be corrected if I'm wrong.) IMHO this is a very bad outcome, because you may not know about those new dependencies and that you need to enable them.

But let's say that you do know about the new dependencies ghi and jkl, and you want to enable them using drush. Saying drush en ghi jkl works correctly. But let's say you instead did drush en abc. drush will offer to enable the ghi and jkl modules, but if you accept its offer, it then doesn't enable them, but it tells you that it did!

This happens because the abc module is already enabled, so the whole thing is a no-op.

To Reproduce
What did you do?

composer update
... downloads happen ...
drush en abc
The following module(s) will be enabled: ghi, jkl

 Do you want to continue? (yes/no) [yes]:
 >

 [success] Successfully enabled: ghi, jkl

Expected behavior
What did you expect would happen?

The ghi and jkl modules are now enabled.

Actual behavior
What happened instead?

The ghi and jkl modules are not enabled.

Workaround
Is there another way to do the desired action?

Install the new dependencies directly.

drush en ghi jkl

System Configuration

Q	A
Drush version?	10.3
Drupal version?	9.2.7
PHP version	7.4.22
OS?	Mac

Additional information
Add any other context about the problem here.

The enable code is in the enable() function of src/Drupal/Commands/pm/PmCommands.php. The list of modules specified in the command is $modules, and the function creates local variable $todo with the dependencies. But then only the modules in $modules are enabled. If these modules aren't already enabled, this is normally enough to also enable the dependencies. But in this case, the modules in $modules are already enabled, so it seems the code "falls through" without enabling the new dependencies.

[weitzman]

he new dependencies are downloaded, but not automatically enabled in Drupal. This is already a known problem, and it seems drush can't help

Correct.
This report does look like a bug, with a good workaround easily available. Tagging accordingly.

[rwalkerands]

Example Bash script to run after doing composer update. Set DRUSH as appropriate, then:

ALREADY_ENABLED_MODULES=$(${DRUSH} pml --type=module \
  --status=enabled --fields=name --format=list)
ALREADY_ENABLED_THEMES=$(${DRUSH} pml --type=theme \
  --status=enabled --fields=name --format=list)

${DRUSH} en -y ${ALREADY_ENABLED_MODULES}
${DRUSH} then -y ${ALREADY_ENABLED_THEMES}

This doesn't enable the new modules for you, but "should" tell you what they are.

[rajeshreeputra]

I found an workaround for the same and create PR, it's in draft state. @rwalkerands Could you please review once.
#5057

drush en abc
Requested module is already enabled: abc
 [success] Successfully enabled: ghi, jkl
The following module(s) will be enabled: ghi, jkl

 Do you want to continue? (yes/no) [yes]:
 > yes

 [success] Successfully enabled: ghi, jkl