使用 Composer 时清理应用程序部署答案

【问题标题】：Clean application deployment when using Composer使用 Composer 时清理应用程序部署
【发布时间】：2014-11-12 20:03:56
【问题描述】：

我已经开始将 Composer 用于一个新的 PHP 应用程序（它使用了一些框架和 API，例如 Laravel、Smarty 等），并且在开发过程中一切都很好。

但是，我不太确定如何在实时生产服务器上部署它。 /vendor 目录下各个模块的子目录似乎包含很多我通常不会包含在应用程序中的东西（例如演示文件、安装自述文件、文档等）。这是正常的，还是这些包的创建者对如何创建 Composer 包有错误的想法？

是否有一种标准方法来创建一个干净的应用程序部署，该部署只包括必要的分发文件，而不包括其他不相关甚至不应该存在的东西（即使出于安全原因）？

我问的是最常用的工作流程，或者可能是 composer.json 中的特定命令或配置，我应该考虑实现这一点。

【问题讨论】：

我猜你可能会在部署之前清理每个供应商包中的不必要文件，但我真的不认为这值得麻烦。不确定它如何影响安全性，因为这些文件不应该暴露给除您自己的应用之外的任何人。
是的，显然我可以自己清理它们，但 Composer 的全部意义在于自动安装和配置依赖项。每次更新时我都必须这样做。我想知道是否有任何更自动化的标准方法可以做到这一点。我在其他语言中使用过其他依赖管理系统（如 Java 的 Maven），通常它们不包含不应该与应用程序捆绑的实际分发的内容。如果您想访问单独引用它们的演示文件或 API HTML 文档，则将它们包含在应用程序中是没有意义的。
您显然会在部署脚本中自动执行清理过程。但是，是的，每次依赖项更新时，您都需要更新它。不，没有其他真正的方法。包作者应注意不要包含不必要的内容。

【解决方案1】：

我会提出两条建议来解决您的大部分担忧。

使用 composer update --no-dev 仅从您的锁定文件中删除任何用于开发的依赖项。或者在 composer.json 中调整您的要求以达到同样的效果。

理论上，包开发者应该保持生产版本更干净，（例如，不包括所有的 phpunit 测试）。但是，是的，在供应商库中有很多“杂乱无章”是很正常的，主要是因为构建的概念在 PHP 中相对不常见，因此“源”和“目标”混杂在一起。

演示和自述文件仍然是组件“分发”版本的必要部分，因此如果您指定 no-dev，它们仍然存在，这只是说“我不是在开发这个包裹，我只是在消费”。

感觉确实缺少了一个 composer 功能：在此之上的一个级别确实是一个超级干净的部署缩小包。

将您的供应商库保持在 Web 根目录之上。

这可以防止对供应商库的任何不必要的浏览，并消除网站访问者在浏览您的库时的任何安全问题（如果这是您真正担心的问题）。

例如我通常使用

domain
    /api
    /etc
    /vendor
    /www
        /js
        /css
        /images
        /index.php
        /foo
            /bar.php

www 是虚拟主机 Web 根目录。所有入门级脚本都在您的 Web 根目录中，自动加载路径为 ../vendor/autoload.php

如果您将 Laravel 用于您的网站以及 api，那么 www/ 当然可以是 laravel 根文件夹。

如果您的 laravel API 与“平面”网站分开完成，api 可以为您的 laravel API 托管一个单独的虚拟主机。

（我在 Web 根目录上方保留了其他文件夹 build、docs、src 用于 SASS、JS、Grunt 等，etc 可以安全地存储任何配置、密码、密钥等）。

如果您仍然对包袱不满意，那么正如其他评论者所建议的那样，您需要查看一个可以清理问题的构建过程。这可能会变得复杂且难以维护！

例如您可以构建到本地 www 部署文件夹（即作曲家更新，加上任何 grunt 任务、凉亭安装、laravel/artisan 发布等），然后将其修剪回来（您必须设计的自定义脚本），并将其提交到单独的表示已发布的扁平化部署目标的存储库。这就是您将部署到您的网站的内容。

这必须是自动化的，否则你会在大约第三次之后停止这样做:)

但是...您必须问为什么还要修剪供应商库。磁盘空间？他们没那么大。整体整洁？将文件夹视为黑匣子，只需阅读 API 文档即可。即不要看:)

【讨论】：