我的公司有一个使用git和composer管理其依赖项的API。主项目有大约50个依赖项，所有这些依赖项都属于公司。其中一些依赖项定期更改代码，其他依赖项几个月都没有更新。
目前，主项目中的composer.json的所有依赖项都指向dev-dev，但我们希望保留dev用于开发目的，并将master用于生产环境。
这意味着composer.json应该包含dev-dev用于devs环境，而dev-master用于prod环境。我们已经考虑使用两个composer（composer.dev.json和composer.prod.json），并且在更新依赖项时，使用以下命令：
COMPOSER=composer.dev.json composer update这样我们就可以根据环境使用这两种方法。我们不喜欢这种方法的地方是，dependencides必须在两个composer中复制，或者换句话说，当开发人员在composer.dev.json中包含依赖项时，他们必须记住也将其添加到composer.prod.json中。这使我们无法使用这种方法。因为我们希望这个过程更加自动化，避免当开发人员忘记在其他 composer 文件中包含依赖关系时出现问题。
考虑到生产部署，管理这类具有如此多依赖关系的应用程序的最佳方法是什么？
如果composer包含一个参数来设置要下载的分支，那将是完美的，类似于这样：
composer update --branch=dev-dev #Development environment
composer update --branch=dev-master #Production environment是的，我知道这不是它应该如何工作，但会解决我们的问题：）
任何想法在这里将不胜感激！
1条答案
按热度按时间i7uaboj41#
问题是什么是主导。如果dev/prod并行rails是主导，你不能跳过它们。有了它，你的问题陈述也很清楚：
我们不喜欢这种方法的地方是依赖项必须在两个composer中复制，或者换句话说，当开发人员在composer.dev.json中包含依赖项时，他们必须记住也将其添加到composer.prod.json中。这使我们无法使用这种方法，因为我们希望该过程更加自动化，并避免开发人员忘记将依赖项包含在其他composer文件中的问题。
Composer文件是包含onlyJSON Text的文件。这并不是魔术，虽然text-diff可能不是最好的实用方法，但编写一个简单的PHP脚本来比较这两个文件的相关部分应该是PHP商店中的一个简单的PHP脚本。
一个简单的
make clean all应该立即显示任何丢失的部分，而您自然地只编辑一个文件。或者换句话说：把这个问题委托给你的构建经理，定义依赖项和目标，然后就可以完成了。使用构建自动化，从你的需求开始。识别痛点可以帮助你找出你的需求在哪里。
这也适用于你的替代方案。如果composer有这个分支功能呢？对不起？你需要创建两个相同的JSON文本文件 * 但是 * 在
composer.json#/require下的一些非常特定的地方你总是交换相同的子字符串？也许我不完全理解你的问题，但是恕我直言，没有必要为composer打补丁：make COMPOSER_BRANCH=devmake COMPOSER_BRANCH=master一个好的构建管理器带有参数化，可以在命令行上处理它们（在您的情况下，甚至可能有一个默认值），只需创建它。