使用作曲家后需要什么文件
我跑了作曲家，以便使用guzzle。这导致了这些目录：
composer
gabrieldarezzo
guzzlehttp
psr
ralouphie
symfony
我注意到gabrieldarezzo/colorizzar/中的文件car.png。整个目录似乎对Guzzle毫无用处，因此我将其删除，并且代码仍然有效。我尝试一次删除其他一些目录，但要删除一个目录，但是代码失败了。有没有办法知道实际需要哪些文件？
评论后进行了编辑：
此问题的目的是询问是否有必要添加所有文件。我将作曲家重新升级到新位置，并安装了6.5.8版。不包括Gabrieldarezzo，因此我必须在某个时候为其他一些软件包跑了作曲家。从所有答复中，我可以看到我的问题的答案是肯定的，它们是必需的。我感谢对此的所有答复。
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?
Edited after comments:
The purpose of this question is to ask if all of the files composer adds are necessary. I re-ran composer to a new location and it installed version 6.5.8. The gabrieldarezzo was not included so I must have ran composer for some other package at some point. From all of the replies I can see that the answer to my question is yes, they are required. I appreciate all of the replies to this.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
该语句毫无意义，而无需谈论 代码仍然有效 - 换句话说，需要哪些文件取决于您实际在做什么。
如果您要求作曲家安装Guzzle，然后编写一个PHP文件，该文件刚刚说
echo“ Hello World”;，那么您可以删除整个供应商目录，显然什么也不会破坏。或者，您可以编写echo \ guzzlehttp \ requestOptions :: wellow_redirects;并删除除vendor/guzzles/guzzlehttp/src/requestOptions.php 以外的所有内容以外的所有内容。从理论上讲，您可以静态地分析一件代码，递归识别哪些代码可以到达，因此最小文件集将是什么。您还可以监视运行的应用程序，并在PHP自动加载器级别甚至在OS / File System级别上查看其打开的文件。
但是问题是您为什么要关心？
重要的是要了解，除非以某种方式引用，否则实际上不会将任何文件读取并加载到内存中。这是自动加载。因此，删除文件不会对应用程序的 compilation 或执行 。
删除文件将减少存储应用程序所需的磁盘空间，但是很少有所需的空间是您可用物品的很大一部分。它还将减少部署它所需的带宽，但是源代码通常会很好地压缩，因此一旦将其捆绑到诸如tar.gz之类的东西中，这种保存通常也微不足道。
可能相关的最终说明是， 这些文件都不应在您的版本历史记录中提交。您应该提交.gitignore 文件）。然后，您可以通过运行
composer.json和composer.lock，并将整个vendor目录标记为“忽略”（例如，在Composer install来获取任何版本使用的确切依赖项，该版本从composer.lock.lock中读取版本。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 writeecho \GuzzleHttp\RequestOptions::ALLOW_REDIRECTS;and delete everything except forvendor/guzzle/guzzlehttp/src/RequestOptions.phpwhere that constant is defined.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.jsonandcomposer.lock, and mark the entirety of thevendordirectory as "ignored" (e.g. in a.gitignorefile). You can then get the exact dependencies used by any version by runningcomposer install, which reads the versions fromcomposer.lock.每当您需要第三方软件包而无需深入审查和跟踪每个文件，其中包含密码安全的评论结果散列，您就可以轻松地遇到所描述的情况。
“随机”删除此类目录的问题是，它不能替换适当的依赖性检查，而只是防止（现在已删除的）代码加载到生产系统上，以分析和在内存中进行分析和执行（或在car.png 出于某些其他原因？）。
现在，在这两个极点之间有很多空间和通常的开发项目，并且运行它们的人还不够重要，即依赖性实际上被彻底审查了，尽管其中大多数人都没有适合特定目的的适合度，并且以非常大胆的字母为准。
但是，如果您要研究的是一个项目，并且发现某些文件看起来很腥，请在项目中向项目报告问题，对您来说意义重大。
有时项目不会（扩展）使用作曲家软件包（概念）并且还有改进的余地（不用说这是对任何项目实践的判断）。例如，排除生产使用中的开发资源。这具有您不需要“随机”删除文件的好处，而是与实际的开发人员和软件分销商合作。
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.pngfor 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
distdistribution 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.