🇫🇷France @Chris64

Okay. Update done @smustgrave.

Yes, in core/lib/Drupal/Core/Utility/ProjectInfo.php. And just following,

      // If we still don't know the 'project', give up.
      if (empty($file->info['project'])) {
        continue;
      }

living the loop foreach ($list as $file) and missing the setting,

      if (!isset($projects[$project_name])) {
        // Only process this if we haven't done this project, since a single
        // project can have multiple modules or themes.
        $projects[$project_name] = [
          'name' => $project_name,
          // Only save attributes from the .info.yml file we care about so we do
          // not bloat our RAM usage needlessly.
          'info' => $this->filterProjectInfo($file->info, $additional_elements),
          'datestamp' => $file->info['datestamp'],
          'includes' => [$file->getName() => $file->info['name']],
          'project_type' => $project_display_type,
          'project_status' => $status,
        ];
      }

For a method without phpcs. (supposing phpcs part done, processing the remaining part.) Supposing the concerned instruction is !isset($this->service). To get a file list,
sudo grep -nr \!isset | grep service\)
To verify the instructions,
sudo grep -nrA 2 \!isset\(\$this-\>service\)
In the files list, to distinguish generator and generated, as simply generated files are different but the instruction is always at the same line. For generator the line number is singular.

Okay @smustgrave, an important information. How to do this with phpcs due to the obstruction in that case?

Better file...

phpcs command used,
phpcs --standard=SlevomatCodingStandard --sniffs=SlevomatCodingStandard.ControlStructures.RequireNullCoalesceOperatorIsset --extensions=php,module,inc core
The file RequireNullCoalesceOperatorIssetSniff.php has to be in the right place: in slevomat/coding-standard/SlevomatCodingStandard/Sniffs/ControlStructures, in /home/.config/composer/vendor.

and ideally a coding standards sniff we could enable to prevent this code from creeping back in.

A coding standards sniff rule now ready for this multi-line case. And now case fixable with phpcbf. MR mergeable. Need review.

MR Mergeable. Need review. Not a straight line, but seems okay now. Rebased on #3428032 to pass the test.

Okay @Spokje, that is clear.

Thank you @Spokje for the information. You mean #30 📌 Switch long-form single-line assign and null coalesce (= ??) to null coalesce assign operator (??=) Needs work ? Normally it is a new rebased version.

The $output comes from,

    // Confirm that 'git' is no longer available.
    $output = [];
    exec('git --help', $output, $status);
    $this->assertEquals(127, $status);
    // Run the scaffold command.
    $output = $this->mustExec('composer drupal:scaffold 2>&1', NULL);

And the composer error comes from the latter line.

From https://getcomposer.org/root-version the error message correspond to the case 4. The information can not come from case 3, since git is not available here. Therefore, to provide the information remain either case 1, through the version key in composer.json, or case 2, from the COMPOSER_ROOT_VERSION environment variable. Else the message is right, and the the $expected is erroneous with this message missing.

I don't see the relation with ??=.

The test error message,

Drupal.Tests.Composer.Plugin.Scaffold.Functional.ManageGitIgnoreTest
Name testUnmanagedGitIgnoreWhenGitNotAvailable
File core/tests/Drupal/Tests/Composer/Plugin/Scaffold/Functional/ManageGitIgnoreTest.php
Execution time 448.86ms
System output

Drupal\Tests\Composer\Plugin\Scaffold\Functional\ManageGitIgnoreTest::testUnmanagedGitIgnoreWhenGitNotAvailable
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'Scaffolding files for fixtures/drupal-assets-fixture:\n
+'Composer could not detect the root package (fixtures/drupal-composer-drupal-project) version, defaulting to '1.0.0'. See https://getcomposer.org/root-version\n
+Scaffolding files for fixtures/drupal-assets-fixture:\n
   - Copy [web-root]/.csslintrc from assets/.csslintrc\n
   - Copy [web-root]/.editorconfig from assets/.editorconfig\n
   - Copy [web-root]/.eslintignore from assets/.eslintignore\n

vendor/phpunit/phpunit/src/Framework/Constraint/Equality/IsEqual.php:94
core/tests/Drupal/Tests/Composer/Plugin/Scaffold/Functional/ManageGitIgnoreTest.php:253
vendor/phpunit/phpunit/src/Framework/TestResult.php:728
vendor/phpunit/phpunit/src/Framework/TestSuite.php:684
vendor/phpunit/phpunit/src/TextUI/TestRunner.php:651
vendor/phpunit/phpunit/src/TextUI/Command.php:144
vendor/phpunit/phpunit/src/TextUI/Command.php:97

1 test error occurs. Some thing wrong happen with,
Drupal\Tests\Composer\Plugin\Scaffold\Functional\ManageGitIgnoreTest::testUnmanagedGitIgnoreWhenGitNotAvailable
in core/tests/Drupal/Tests/Composer/Plugin/Scaffold/Functional/ManageGitIgnoreTest.php line 253,
$this->assertEquals($expected, $output);
The $expected is not equal to the $output. In this latter an error message exists,
Composer could not detect the root package (fixtures/drupal-composer-drupal-project) version, defaulting to '1.0.0'. See https://getcomposer.org/root-version

Use phpcs with rule RequireNullCoalesceEqualOperator from SlevomatCodingStandard:
phpcs --standard=SlevomatCodingStandard --sniffs=SlevomatCodingStandard.ControlStructures.RequireNullCoalesceEqualOperator core

@smustgrave, for phpcs, a rule exists about this case,
slevomat/coding-standard/SlevomatCodingStandard/Sniffs/ControlStructures/RequireNullCoalesceEqualOperatorSniff
but is missing in drupal/coder/coder_sniffer/Drupal/ruleset.xml,
<rule ref="SlevomatCodingStandard.ControlStructures.RequireNullCoalesceEqualOperator" />
I think this is this case since the rule message is,
Use "??=" operator instead of "=" and "??

Since its message is,
Use "??=" operator instead of "=" and "??".
the rule corresponds to the case A. But not to the case B.

A code sniffing rule exists about this topic,
slevomat/coding-standard/SlevomatCodingStandard/Sniffs/ControlStructures/RequireNullCoalesceEqualOperatorSniff
but is missing in,
drupal/coder/coder_sniffer/Drupal/ruleset.xml
that is,
<rule ref="SlevomatCodingStandard.ControlStructures.RequireNullCoalesceEqualOperator" />

Do you know if there is a code sniffing rule we could enable that would prevent these from coming back?

Okay @smustgrave, you mean a rule for phpcs... There is,
slevomat/coding-standard/SlevomatCodingStandard/Sniffs/ControlStructures/RequireNullCoalesceEqualOperatorSniff
but is missing in drupal/coder/coder_sniffer/Drupal/ruleset.xml. That is,
<rule ref="SlevomatCodingStandard.ControlStructures.RequireNullCoalesceEqualOperator" />
Maybe to be after,
<rule ref="SlevomatCodingStandard.ControlStructures.RequireNullCoalesceOperator" />

To take into account the request #11 📌 Change !isset to ??= assignment operator: generator and their generated files case. Needs review the parent issue 📌 Use null coalescing assignment operator Active has been updated.

Some updates following #3424083-#11 📌 Change !isset to ??= assignment operator: generator and their generated files case. Needs review ,

There are now several issues on this topic. To help reviews and understand the scoping of the issue it will help if a meta issue is made to discuss the overall change. The issues to implement the change should be children of that meta and then they can be removed as related. Use the component 'other' for these because they are not directly related to a particular subsystem.

MR mergeable. NR.

Two sets are voluntary ignored here,
- generator/generated files 📌 Change !isset to ??= assignment operator: generator and their generated files case. Needs review .
- 2 files with phpstan obstruction 📌 Use null coalescing assignment operator ??=: phpstan obstruction case. Closed: won't fix .

For a code sniff rule, this multi-line case is much more complicate than the uni-line case. Since several different configurations exist, and many should be exclude from this transformation: if else, if elseif, etc.

The sed command used has a rule to reach the good targets. Not perfect. Maybe the best is to use rector rule, as suggest by @dpi in #3418494-#23 📌 Switch long-form single-line assign and null coalesce (= ??) to null coalesce assign operator (??=) Needs work . However the rule doesn't exist (?).

Questions,
-1. Did the transformations done are right?
-2. Did some files are missed?
-3. Did some cases are missed?

A new commit, since a rebase was needed. 4 conflicts, in,

core/lib/Drupal/Core/Database/Query/Insert.php
core/lib/Drupal/Core/EventSubscriber/ConfigImportSubscriber.php
core/modules/workspaces/src/WorkspaceManager.php
core/tests/Drupal/KernelTests/Core/Cache/GenericCacheBackendUnitTestBase.php

@smustgrave, this particular case is efficiently managed by rector. As indicated by @dpi in #23 📌 Switch long-form single-line assign and null coalesce (= ??) to null coalesce assign operator (??=) Needs work . The general purpose is some thing else. I am in favour of dividing the general problem into different particular cases.

Title changed. Less detailed but more clear.

Actually a parent issue exists, with all the children. Is it the right place for such a [Meta] and discussion? Or some thing else is needed.

Title changed. Is it suitable now?

As observed by @dpi for an other case 📌 Switch long-form single-line assign and null coalesce (= ??) to null coalesce assign operator (??=) Needs work , some files are missed. Since some directories was ignored.

New IS with some changes and less mistakes.

A proposal. MR mergeable. Need review. Work done even maybe refused.

Sed used. And not Rector, since I haven't its rule. Normally no files missed. The targeted function is lazyLoadItself. 31 files modified.

@dpi, after reading your comments I think the actual problem exposition is not clear enough: generator is not present as it should be. The title and the IS should be changed.

To be more faithful the title might be changed to "... generator and their generated files".

In fact, the ask is about a change in the generator. A Drupal authority has to decide if the asked change is acceptable or not.

If the generator is altered, the regenarated files will be too. The generated files must be in the package. Either the generator script must be applied, or the original generated files must be altered in accordance with the generator.

The motivation for the ask is to make the changes !isset() to ??= in the code wherever possible.

The generator file should also concerned by the phpcs. However this file is not protected by the instruction // phpcs:ignoreFile. Probably the nowdoc block used is ignored by phpcs.

MR mergeable. NR.

- The phpstan errors have no line number. The corresponding items should be removed from core/phpstan-baseline.neon file.
- Following the messages,

in empty\(\) always exists and is not falsy
in isset\(\) always exists and is not nullable

since always exists, make some changes empty($A) to !$A and isset($A) to $A !== NULL. (Not always, to keep the ??= transformations still possible.)

Still some phpstan errors,

 ------ ------------------------------------------------------------------------------------------------ 
  Line   core/modules/views/src/Plugin/views/display/DisplayPluginBase.php                               
 ------ ------------------------------------------------------------------------------------------------ 
         Ignored error pattern #^Variable \$pager in isset\(\) always exists                             
         and is not nullable\.$# in path                                                                 
         /builds/issue/drupal-3424107/core/modules/views/src/Plugin/views/display/DisplayPluginBase.php  
         was not matched in reported errors.                                                             
         Ignored error pattern #^Variable \$style in empty\(\) always exists                             
         and is not falsy\.$# in path                                                                    
         /builds/issue/drupal-3424107/core/modules/views/src/Plugin/views/display/DisplayPluginBase.php  
         was not matched in reported errors.                                                             
 ------ ------------------------------------------------------------------------------------------------ 
 ------ --------------------------------------------------------------------------------------------- 
  Line   core/modules/views/src/Plugin/views/display/PathPluginBase.php                               
 ------ --------------------------------------------------------------------------------------------- 
         Ignored error pattern #^Variable \$access_plugin in isset\(\) always                         
         exists and is not nullable\.$# in path                                                       
         /builds/issue/drupal-3424107/core/modules/views/src/Plugin/views/display/PathPluginBase.php  
         was not matched in reported errors.                                                          
 ------ --------------------------------------------------------------------------------------------- 
 ------ -------------------------------------------------------------------------------------------- 
  Line   core/modules/views/src/Plugin/views/style/StylePluginBase.php                               
 ------ -------------------------------------------------------------------------------------------- 
         Ignored error pattern #^Variable \$plugin in empty\(\) always exists                        
         and is not falsy\.$# in path                                                                
         /builds/issue/drupal-3424107/core/modules/views/src/Plugin/views/style/StylePluginBase.php  
         was not matched in reported errors.                                                         
 ------ -------------------------------------------------------------------------------------------- 
 ------ --------------------------------------------------------------------------------------------------- 
  Line   core/modules/views_ui/tests/src/FunctionalJavascript/PreviewTest.php                               
 ------ --------------------------------------------------------------------------------------------------- 
         Ignored error pattern #^Variable \$message in isset\(\) always exists                              
         and is not nullable\.$# in path                                                                    
         /builds/issue/drupal-3424107/core/modules/views_ui/tests/src/FunctionalJavascript/PreviewTest.php  
         was not matched in reported errors.                                                                
 ------ --------------------------------------------------------------------------------------------------- 
 [ERROR] Found 5 errors

Finally the issue perimeter could be restricted to the nullable problems,

so lets create an issue just for this

using this issue for these problems.

@dpi, for #6 📌 Use null coalescing assignment operator ??=: phpstan obstruction case. Closed: won't fix and $access_plugin,

However I can see there a return void;, so lets create an issue just for this, which changes the documentation, and explicitly return NULL;

I believe you have in head,

    // Return now if no options have been loaded.
    if (empty($options) || !isset($options['type'])) {
      return;
    }

in getPlugin in core/modules/views/src/Plugin/views/display/DisplayPluginBase.php. And if I follow 🐛 \Drupal\Core\Config\StorageInterface::read is typehinted as possibly returning bool, but never returns true Fixed I think the change needed should be,
* @return \Drupal\views\Plugin\views\ViewsPluginInterface
to
* @return \Drupal\views\Plugin\views\ViewsPluginInterface|null
in,

  /**
   * Get the instance of a plugin, for example style or row.
   *
   * @param string $type
   *   The type of the plugin.
   *
   * @return \Drupal\views\Plugin\views\ViewsPluginInterface
   */
  public function getPlugin($type);

in core/modules/views/src/Plugin/views/display/DisplayPluginInterface.php since,
abstract class DisplayPluginBase extends PluginBase implements DisplayPluginInterface, DependentPluginInterface {

About #6 📌 Use null coalescing assignment operator ??=: phpstan obstruction case. Closed: won't fix , on one side, in core/modules/views_ui/tests/src/FunctionalJavascript/PreviewTest.php,

  /**
   * Asserts that an element has a given class.
   *
   * @param \Behat\Mink\Element\NodeElement $element
   *   The element to test.
   * @param string $class
   *   The class to assert.
   * @param string $message
   *   (optional) A verbose message to output.
   *
   * @internal
   */
  protected function assertClass(NodeElement $element, string $class, string $message = ''): void {
    if (!isset($message)) {
      $message = "Class .$class found.";
    }
    $this->assertStringContainsString($class, $element->getAttribute('class'), $message);

On the other side, in core/modules/system/tests/src/Functional/Pager/PagerTest.php,

  /**
   * Asserts that an element has a given class.
   *
   * @param \Behat\Mink\Element\NodeElement $element
   *   The element to test.
   * @param string $class
   *   The class to assert.
   * @param string $message
   *   (optional) A verbose message to output.
   *
   * @internal
   */
  protected function assertClass(NodeElement $element, string $class, string $message = NULL): void {
    if (!isset($message)) {
      $message = "Class .$class found.";
    }
    $this->assertTrue($element->hasClass($class), $message);
  }

To make the two match change,
, string $message = ''): void {
to
, string $message = NULL): void {

Okay @dpi, after having a look your requests about null are clear for me.

Yes @dpi, I saw that: // phpcs:ignoreFile. But here it is about code instruction changes. I ask the question: Should we make some change in this kind of files? Your answer is: We should not.

Yes it is a special case. A reason why this issue exists. Critical.

I made the distinction between generated files and generator files. If some changes are made in the generator, some changes will happen in the generated files. And the generated need to be regenerated. Hence the generator is the key.

(The generated files are in the Drupal core package and are not regenerated during a drush cr.)

One an other hand the directive 📌 Switch long-form single-line assign and null coalesce (= ??) to null coalesce assign operator (??=) Needs work is,

.... assume there are many similar changes we could make across all of core, and ideally a coding standards sniff we could enable to prevent this code from creeping back in.

and if I ignore some cases I face a kind of contradiction with this goal.

May be refused, but nice information: with these few changes now these two cases have MR mergeable. A step forward.

I push the work, since done. It can be refused.

@dpi, I think the problem is not ??=. The problem, as phpstan tells us, is not nullable + isset.

@dpi, thank you for your answer, We can discuss.

For PreviewTest.php, lets keep the change in the ??= issue.

Well, this case block the MR, because of the phpstan error. I face this before.

For PathPluginBase, \Drupal\views\Plugin\views\display\DisplayPluginInterface::getPlugin the docs say it can never return null.

So, is not nullable, so,

    if (!isset($access_plugin)) {
      // @todo Do we want to support a default plugin in getPlugin itself?
      $access_plugin = Views::pluginManager('access')->createInstance('none');
    }

is inconsistent: never go in the block. Or is nullable, and this code is okay (...and could be changed to ??=).

Chris64 → created an issue.

Chris64 → created an issue.

@dpi are your sure? I am not. I would like to keep this issue. I see that as a method. To have an overview on the different cases and to control them to be sure to reach the goal. You would like that I change this method? Moreover, some others do the same in the Drupal project. For example Replace 🌱 Replace strpos/substr with PHP 8's str_starts_with() / str_contains() / str_ends_with() Active .

13 missing files found, in core/lib. Got with rector.

You are right @dpi! Rector is much better. Indeed, some cases was missed...

Sorry, my purpose is not clear enough. Even is obscure. May be it should be ignored since it is about about some thing that does not exist, but I don't think it should be closed as duplicate. It is not Elvis operator. Yes, ?: is not an assignment operator, but I would like to speak about an assignment operator for ?:.

Here a clearer exposition,

-------------------------------------------------
symbol | ternary operator | assignment operator |
-------------------------------------------------
  ??   |        ??        |        ??=          |
-------------------------------------------------
  ?!   |        ?!        |        ?!=  (1)     |
-------------------------------------------------
(1) : does not exist/missing in php 8.2

The purpose of this issue is about case (1).

Okay @smustgrave: MR is powerful, compare to patch. Lot of validation work is made by the machine. Now MR mergeable got, the human work needed is smaller.

Then, compared to the initial goal,

ideally a coding standards sniff we could enable to prevent this code from creeping back in.

all the cases are not considered here. Two sets are known missing: #8 📌 Use null coalescing assignment operator: multi-lines case. Needs work and #9 📌 Use null coalescing assignment operator: multi-lines case. Needs work .
#8 is not explicit enough about "generated files". That is some php files with header,

/**
 * This file was generated via php core/scripts/generate-proxy-class.php <*> <*>.
 */

I plan 2 other issues for them.

Mergeable.

The MR faced obstructions from phpstan: 4 = 2x2 errors: 2 files,

 ------ --------------------------------------------------------------------------------------------- 
  Line   core/modules/views/src/Plugin/views/display/PathPluginBase.php                               
 ------ --------------------------------------------------------------------------------------------- 
         Ignored error pattern #^Variable \$access_plugin in isset\(\) always                         
         exists and is not nullable\.$# in path                                                       
         /builds/issue/drupal-3423310/core/modules/views/src/Plugin/views/display/PathPluginBase.php  
         was not matched in reported errors.                                                          
  199    Variable $access_plugin on left side of ??= always exists and is not                         
         nullable.                                                                                    
 ------ --------------------------------------------------------------------------------------------- 
 ------ --------------------------------------------------------------------------------------------------- 
  Line   core/modules/views_ui/tests/src/FunctionalJavascript/PreviewTest.php                               
 ------ --------------------------------------------------------------------------------------------------- 
         Ignored error pattern #^Variable \$message in isset\(\) always exists                              
         and is not nullable\.$# in path                                                                    
         /builds/issue/drupal-3423310/core/modules/views_ui/tests/src/FunctionalJavascript/PreviewTest.php  
         was not matched in reported errors.                                                                
  309    Variable $message on left side of ??= always exists and is not                                     
         nullable.                                                                                          
 ------ --------------------------------------------------------------------------------------------------- 
 [ERROR] Found 4 errors

The problem seems not the present code transformation but an other problem. To allow a MR we propose,
- to remove these 2 files from this MR,
- to create an other issue about these phpstan problems,
- to treat in an other issue the ??= code transformation of these 2 remaining files.

Mistakes exist. Still some work.

A Commit corresponding nearly to the patch 9B → . As said in #9 📌 Switch long-form single-line assign and null coalesce (= ??) to null coalesce assign operator (??=) Needs work this need review and comments.

Issue changed from general to the particular simpler case A corresponding to the MR. See the parent issue 📌 Use null coalescing assignment operator Active for the general purpose.

Chris64 → created an issue.

Chris64 → created an issue.

May be this issue would be more easy to manage with a parent issue with children corresponding to the different cases. Actually two.

@sakthi_dev your MR seems correspond with the patch 9A. Agree with this choice. Thank you for your MR.

Usually just putting an isset() could be masking a larger issue

Agree with this principle. And the other part.

Original code reinstalled. But the problem does not happen any where. Therefore not possible for me actually to get more information about the issue...

@jonathan1055, may be the problem is project and component are not well chosen... Changed for Drupal core and base system.

Also recommended to use MRs

I thought about it, but the work needs a first general code review, and a patch file seems for me a simple means to do it. If it will be, look right try a MR now, or some things likes, to big must be cut, or, some rules look wrong.

Chris64 → created an issue.

A good documentation is wellcome.
Yes @dqd, still some work for DataTables.
And thank you for your support!

Two files corresponding to patches giving an idea of what kind of code transformations the rule gives. One is small, A, grouping uniligne code, the other is bigger, B, grouping multiligne code. All the code changes here are produced automatically via a sed command (one command, one file). It is the moment for comments. Is it right? Is it complete? Is reasonable?

(the modules appearing here are coincidences, linked to home changes, and not release state.)

The elements automatically add by Drupal.org packaging script in the info.yml when a new release is created are the 3 keys version, project and datestamp.

If for some reasons those information are not in a module of an installation some problems could happen.

Some errors happen in some pages of the applications (see 📌 Handle malformed module info in the translation status form Active ).

Some others happen when trying to update the installation via composer. Indeed, it seems that if the information does not exists the update system is blinded about the module, and the module is not updated,

Loading composer repositories with package information
Updating dependencies
Nothing to modify in lock file
Installing dependencies from lock file (including require-dev)
Nothing to install, update or remove

To update a module with such a problem the update have to be forced. There is several means to do that.
Remove and reinstall the module, with composer remove and composer require. However it is not always possible by this means. For example if the module has dependencies. Then a message like the following happens from composer,
Removal failed, drupal/entity_reference_revisions is still present, it may be required by another package. See `composer why drupal/entity_reference_revisions`.
Others obstructions could exist for removing a module. For example, now removing the dependent module, the message could be,

Running composer update drupal/paragraphs
Loading composer repositories with package information
Updating dependencies
Lock file operations: 0 installs, 0 updates, 2 removals
  - Removing drupal/entity_reference_revisions (1.11.0)
  - Removing drupal/paragraphs (1.17.0)
Writing lock file
Installing dependencies from lock file (including require-dev)
Package operations: 0 installs, 0 updates, 2 removals
  - Removing drupal/paragraphs (1.17.0)
Deleting /var/www/ligamen.eu/web/modules/contrib/paragraphs - deleted

In GitDownloader.php line 342:

  Source directory /var/www/ligamen.eu/web/modules/contrib/entity_reference_revisions has unpushed changes on the current branch:
  Branch 1.11 could not be found on any remote and appears to be unpushed

And the second module is not deleted. Thus such a message happens in a remove operation. In some case the release could be downloaded but not installed,

Running composer update drupal/entity_reference_revisions
Loading composer repositories with package information
Updating dependencies
Lock file operations: 1 install, 0 updates, 0 removals
  - Locking drupal/entity_reference_revisions (1.11.0)
Writing lock file
Installing dependencies from lock file (including require-dev)
Nothing to install, update or remove

Here the module is not updated.
Furthermore the idea to write in the info.yml file some arbitrary information for the missing ones seems not working.
If composer remove does not work a sure method is to remove or better move (mv and save) the module folder from contrib/.
An other solution is suggested by @dww in #4 💬 Packaging script information missing Closed: works as designed : use a module that update the info.yml file.

Therefore, if an installation has modules with abnormal info.yml files the update with composer is not trivial.

Moreover, firstly the application maintainer have to know the modules with such a problem. How to do that? For Drupal 10.2 fortunately a simple means exists to get such an information but not regular: see 📌 Handle malformed module info in the translation status form Active

Secondly, does a module with the missing information could be regular and accepted? A modified module version should not have the same version than a release one. And development version to be pushed should have not such information. So it seems possible. And composer foresee such a case since in its documentation for status,

If you often need to modify the code of your dependencies and they are installed from source, the status command allows you to check if you have local changes in any of them.

In the principle such a command allow therefore to found code difference. However how the composer know the release version to compare if this information is missing? Hence this command is not sure for this purpose.

Chris64 → created an issue.

@dqp your insistence to get more light about this subject seems justify. More information got. Not trivial. Some things have to be known about this problem.

Yes, reducing the number of instruction lines. When it is possible.

As first sniffer,
grep -Prn '^\s*([^\s]+)\s=\s\1\s\?\?\s.+$'

Indeed, that is clear. Here the idea was to suggest the principle with a concrete case. The general purpose is necessary but more difficult.

Chris64 → created an issue.