Upgrade phpunit/php-file-iterator from 1.3.3 to 1.3.4

I'll agree that this is vital. symlinks are quite common and making them invisible when running tests is a bit surprise.

+++ b/composer.lock
@@ -774,16 +774,16 @@
-                "url": "git://github.com/sebastianbergmann/php-file-iterator.git",
-                "reference": "1.3.3"
+                "url": "https://github.com/sebastianbergmann/php-file-iterator.git",
+                "reference": "acd690379117b042d1c8af1fafd61bde001bf6bb"

Hm. Why are we referencing a specific commit hash here and not a version?

Changed the php-file-iterator version in composer.json, did composer update phpunit/php-file-iterator, and here's the patch.

A maintainer might only add the composer.json change and then do a full update themselves.

Also, you can see the latest available versions of stuff on packagist: https://packagist.org/packages/phpunit/php-file-iterator

The .lock file is supposed to be generated by composer. It'll be obliterated the next time you run composer update. This version of php-file-iterator is, actually, a dependency of Drupal, so therefore we write that down in composer.json.

The .lock file is generated by composer. It's purpose in life is to store the dependency information generated when you type composer update. If it's present, typing composer install will cause composer to read the lock file and not have to work out the dependencies, which can be time-consuming. It gets over-written when you do another update. http://getcomposer.org/doc/01-basic-usage.md#composer-lock-the-lock-file

Whether the dependency is satisfied by a git hash or a file download or whatever is determined by the package. We don't care about that, which is why we don't care about the .lock file, other than it being there.

If the project requires a certain version of a package, it should go in the composer.json file. That way it's explicit that for things to work, you need this version of the package. We want contrib to be able to use PHPUnit, so therefore we need this version of php-file-iterator or later.

If Drupal decides it doesn't want to use PHPUnit any more, then it's a matter of deleting two lines in composer.json instead of one. Ideally, all this would be documented in the composer.json file, but json doesn't like comments.

Also: php-file-iterator is pretty cool. It's not like Drupal ever needs to recursively find files based on suffixes. :-) We could be using php-file-iterator, since it's already there.

This looks fine everywhere, but this does not apply anymore as you basically have to rerole composer changes everytime any dependency is updated.

Have a quick look at #2105821-8: Updated Symfony CMF's Routing Component to v1.1.0

Your patch basically reverts all the changes done in that composer files, so I am wondering whether you have a recent composer version.

Your description sounds really a lot like major, to be honest:

Major: For issues which have significant repercussions, but do not render the whole system unusable.

but yeah actually I just wanted to look up the definition of critical/major, so I don't change it.

Thank you, so the changes made by cosmicdreams was actually wrong.

I reran the process of updating to the new php-file-iterator and can confirm that the patch only contains expected changes.

Committed 6a89adc and pushed to 8.x. Thanks!