我已经开始为一个新的PHP应用程序使用Composer（它使用了一些框架和API，如Laravel、Smarty等），在开发过程中一切都很好。
然而，我不太确定如何在实时生产服务器上部署它。/vendor目录下各个模块的子目录似乎包含了很多我通常不会在应用程序中包含的东西（如演示文件、安装自述文件、文档等）。这是正常的吗，还是这些包的创建者对如何创建Composer包有错误的想法？
有没有一种标准的方法来创建一个干净的应用程序部署，只包括必要的分发文件，而不包括其他不相关的东西，甚至不应该存在（即使是出于安全原因）？
我询问的是使用的最常见的工作流，或者可能是composer.json中的特定命令或配置。
我有两个建议，可以解决您的大部分担忧。
1）
使用composer-update-no-dev只从锁定文件中删除任何用于开发的依赖项。或者在composer.json中调整您的需求以实现同样的目的。
理论上，包开发人员应该保持生产版本的清洁（例如，不包括所有php单元测试）。然而，是的，在供应商库中有很多"cruft"是很正常的，主要是因为构建的概念在PHP中相对不常见，因此"源"one_answers"目标"是混合在一起的。
Demos和readme仍然是组件"分发"版本的必要组成部分，因此如果您没有指定dev，也就是说"我不是在开发这个包，我只是在使用它"，它仍然存在。
它确实感觉缺少了一个composer功能：在这个功能之上的一个级别实际上是一个超级干净的部署缩小包。
2）
将供应商库保持在web根目录之上。
这可以防止任何不必要的浏览供应商库，并消除网站访问者浏览您的库的任何安全问题（如果这是您理所当然担心的）。
例如，我通常使用
domain
/api
/etc
/vendor
/www
/js
/css
/images
/index.php
/foo
/bar.php
其中，www是虚拟主机web根。所有入门级脚本都正常存在于您的web根目录中，并且是../vendor/autoload.php 自动加载的路径
当然，如果你在网站和api中使用laravel，www/可以是laravel根文件夹。
api可以为你的laravel api托管一个单独的vhost，如果它们与"平面"网站分开完成的话。
（我在网络根目录build、docs、src上保留了其他文件夹，用于SASS、JS、Grunt等，etc可以安全地存储任何配置、密码、密钥等）。
3）
如果你仍然对行李不满意，那么正如另一位评论者所建议的那样，你会想看看一个清理东西的构建过程。这可能会变得复杂，难以维护！
例如，您可以构建到本地www部署文件夹（即composer更新，加上任何grunt任务、bower安装、laravel/artisan发布等），然后将其修剪回（您必须设计的自定义脚本），并将其提交到一个单独的存储库中，该存储库代表一个发布的、扁平化的部署目标。这是您将部署到您的网站上的内容。
这必须是自动化的，否则你会在大约第三次之后停止这样做：）
但是。。。你必须问，否则你为什么要削减供应商的libs。磁盘空间？它们没有那么大。总体整洁度？将文件夹视为黑盒，只需阅读API文档即可。即不要看：）