What files are required after using composer-CodePudding

I ran composer in order to use guzzle. It resulted in these directories:

    composer
    gabrieldarezzo
    guzzlehttp
    psr
    ralouphie
    symfony

I noticed the file car.png in the gabrieldarezzo/colorizzar/. That whole directory seemed useless for guzzle so I deleted it and the code still works. I tried deleting some of the other directories, one at a time, but to code failed. Is there a way to know which files are actually required?

CodePudding user response：

That whole directory seemed useless for guzzle so I deleted it and the code still works.

This statement is meaningless without talking about what code still worked - in other words, which files are required depends on what you're actually doing.

If you ask Composer to install Guzzle and then write a PHP file that just says echo 'Hello world'; then you could delete the whole of the vendor directory, and clearly nothing would break. Or you could write echo \GuzzleHttp\RequestOptions::ALLOW_REDIRECTS; and delete everything except for vendor/guzzle/guzzlehttp/src/RequestOptions.php where that constant is defined.

Is there a way to know which files are actually required?

In theory, you could statically analyze a piece of code, recursively identifying which pieces of code were reachable, and therefore what the minimum set of files used would be. You could also monitor a running application and see which files it opened, at the PHP autoloader level or even at the OS / file system level.

But the question is why do you care?

It's important to understand that no file will actually be read and loaded into memory unless it is referenced in some way. This is the purpose of autoloading. So deleting files will not make any difference to the compilation or execution speed of your application.

Deleting the files will reduce the disk space needed to store the application, but it would be rare for the space involved to be a significant proportion of what you have available. It would also reduce the bandwidth needed to deploy it, but source code generally compresses well, so once bundled into something like a tar.gz, this saving is generally also insignificant.

A final note which might be relevant is that none of these files should be committed in your version history. You should commit composer.json and composer.lock, and mark the entirety of the vendor directory as "ignored" (e.g. in a .gitignore file). You can then get the exact dependencies used by any version by running composer install, which reads the versions from composer.lock.

CodePudding user response：

Whenever you require third-party packages without deeply reviewing and track-listing every single file with cryptographically secure content hashes of the reviews outcome, you can easily run into the situation you describe.

The problem with "randomly" deleting such directories is that it does not replace proper dependency checking, but merely prevents the (now removed) code from being loaded onto production systems to be analysed and executed in memory (or in the case of the car.png for some other reason?).

Now between those two poles there is a lot of room and commonly development projects and the people running them aren't important enough that dependencies actually get reviewed thoroughly albeit most of them come without fitness for a particular purpose and a disclaimer in very bold letters.

However if that is a project you look into and you find that some files look fishy, report the issue to the project if you care and it means something to you.

Sometimes projects do not make (extended) use of the dist distribution of a Composer Package (concept) and there is room for improvement (it should go without saying that this is with no judgement of any of those projects practices). E.g. to exclude development resources in production use. This has the benefit that you don't need to remove files "randomly" but you cooperate with actual developers and software distributors.