Update composer.lock

[nagmat84]

@kamil4 has thankfully fixed the long-standing bug about invalid EXIF dates in https://github.com/LycheeOrg/php-exif. This PR updates our dependencies such that his bug fix also finds it way into Lychee.

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[codecov]

Codecov Report

Merging #1285 (0679642) into master (db0c51f) will decrease coverage by 0.96%.
The diff coverage is n/a.

[kamil4]

I've always assumed that Lychee picks up the latest commit of php-exif, based on

Lychee/composer.json

Line 31 in e75ea76

"lychee-org/php-exif": "dev-master",

So that's not happening without updating composer.lock? Bummer...

[nagmat84]

I've always assumed that Lychee picks up the latest commit of php-exif, based on

Lychee/composer.json

Line 31 in e75ea76

"lychee-org/php-exif": "dev-master",

So that's not happening without updating composer.lock? Bummer...

What do you mean by "happening". Nothing is happening there. The composer.json only describes what we would like to have. Then we (as the developers) need to the run ./composer update which creates the file composer.lock.

Composer resolves all the dependency descriptions in all composer.json of all dependencies recursively and tries to find an optimal solution. For example, if we have a dependencies A and B in our dependency tree and both want another dependency C, but A wants C in version 1.1-1.3 and B wants C in version 1.5-1.7, then composer fill fail and complain. The found solution is written into composer.lock and persisted.

Our users only must run composer install. Composer install reads composer.lock and always installs the exact set of dependencies which has been committed by us.

TLTR: Whenever we change anything about our dependencies or just want a newer version, we must run composer update and commit the resulting composer.lock. composer.json is not used for installation.