保持 composer.json 更新和维护

Posted 2023-03-07

【中文标题】保持 composer.json 更新和维护

【英文标题】：Keeping composer.json updated and maintained

【发布时间】：2015-06-19 11:17:38

【问题描述】：

这是一个似乎有点难以找到相关信息的主题。我是否需要更新/面向未来的 Symfony 附带的 composer.json 文件，因为〜近似版本与实际的最新版本越来越远？

这只是礼仪或偏好的事情吗？我希望不会，因为作为开发人员，维持标准已经够难了。我想在composer.jsonrequire 中看到一些关于版本读取和指示方式的具体规则。

例如当我的 composer.json 显示时我该怎么办

"require": 
    "symfony/symfony": "~2.4",
    "doctrine/orm": "~2.2,>=2.2.3",

但要下载 Doctrine 7.4 和 Symfony 4.3？这个可以吗？还是我需要维护我的 composer.json 文件？

Composer.lock 你说是为了这个？什么是 composer.lock？这是一个我不需要调整的文件，没有兴趣看，也不想编辑。这就是我对 composer.lock 的结论。

与 symfony 兼容吗？像这样的条目让我有点生气，"knplabs/knp-menu-bundle": "2.0.*@dev",@dev？我很想看到它消失了。以及我怎么知道哪些包是哪个，即我怎么知道我是否需要像“2.0.*@dev”(which has the version, and a phase tag (dev)), or“dev-master”`这样的名称（没有说明版本号，我想我喜欢这个最好的，但是你会遇到复杂的版本不匹配问题，所以这可能根本不是一个好的标准），那里没有标准。

（请注意，我不需要解释为什么这个包只能作为@dev 使用，我知道它还没有完成。这不是我的意思）。

回到保持 composer.json 文件本身的更新，它真的归结为必须谷歌搜索这些包中的每一个，每隔几个月，查看包 gist、npm 和 git hub repo 文档，只是为了找到那个难以捉摸的版本号，猜测它是否冒着风险，您正在查看正确的网站，最新的代码版本，然后在您验证它与所有其他软件包兼容之后用该数字更新您的 composer.json 文件？我的意思是，这不是包管理器应该为我做的吗？

我见过的关于版本兼容性信息的最佳文档是http://bootstrap.braincrafted.com/getting-started.html#requirements 的图表。如果当前所有的主流开源包都可以采用这样的兼容性图表思想，那就太好了，至少如果它们能够被composer.json安装，其中确实有一个实现的版本检查系统。

所以我不应该定期关注 composer.json 以确保它包含正确的版本号吗？我的意思是，它很容易被忽略，但我认为这将是致命的，而不是忽略它就是我刚刚创建这篇文章的原因。维护 composer.json 的正确方法是什么，有哪些可用资源？

反正我在任何地方都找不到默认的 composer.json 文件吗？很高兴为每个新的 Symfony 版本看到一个，这样我就可以轻松更新最重要的默认 Symfony 至少需要 X。

其他相关问题

php，真的，我完全忽略了 PHP，感谢您指出这一点。这样就说明了兼容的版本。请注意，我删除了问题的 PHP 部分，并将其修改为使用 Doctrine 和 Symfony 的示例。

至于声明 ~2.4 不会安装任何超过 2.x 的东西，我想这就是你所说的，这就是我希望听到的。很高兴知道这一点！

测试套件，我没有在 Symfony 包中使用过。到目前为止，我一直依赖网络驱动程序。

啊，--prefer-lowest? 这验证了什么，我指定的版本至少相互兼容？

因此，在您的下一点上，您在兼容性图表注释下方提到，如果它是依赖项，则它属于必需部分，如果它不是依赖项，则不应将其放在 required 中，而只需将文件直接添加到 @ 987654330@?

您问拥有默认 composer.json 文件的目的是什么。如果我有一个参考，我会知道在过去两年中慢慢进入我的配置的编辑并没有完全导致我现在正在经历的破坏。我只是想看到一些坚实的基础，甚至可能恢复我的文件，删除供应商和网络，以及作曲家安装/更新以查看是否重新开始工作，然后一次添加一个包。我现在不能这样做，因为我无法参考我所拥有的东西来反对有效的东西。

你是说我可以用 composer init 生成一个新鲜的吗？我完全忘记了这一点。好点子。

您在composer init 下方提出的关于语义版本控制主要版本增量的另一点。我没有意识到这是一种标准做法，当出现不兼容时跳转到下一个数字块。我不知道为什么我过去没有关联它。

【参考方案1】：

你有一个中心的，非常错误的句子：

例如当我的 composer.json 说“需要”时我该怎么办： "php": ">=5.3.3", “symfony/symfony”：“~2.4”，但下载的是 php 7.4 和 symfony 4.3？这个可以吗？还是我需要维护我的 composer.json 文件？

错了，Composer 不会安装任何版本的 PHP，但如果使用的版本与声明的不兼容，则会警告您。它不会安装无法与您安装的 PHP 版本一起运行的软件包。

错误的是，当声明“~2.4”时，这意味着不安装 3.0 及更高版本，因此永远不会安装 symfony 4.3。

但是是的，您需要维护您的 composer.json。您应该定期检查至少两件事，也许三件事：

您的软件是否使用最新的允许软件包运行？例如。运行 composer update，然后你的测试套件 - 它应该可以工作。 您的软件是否以最低要求的版本运行？例如。运行 composer update --prefer-lowest，然后你的测试套件 - 它应该可以工作。 您的软件是否以任意组合的软件包版本运行 - 例如使用 composer.lock 文件中记录的组合？

如果您发现任何不兼容性，您可能应该尝试排除这些版本。

我也希望看到对分支的依赖成为过去。取决于发布的开发版本只是稍微不那么糟糕。但只要最常见的安装说明告诉用户“需要 dev-master”，这不会很快发生。社区仍然需要接受良好的教育，了解为什么使用分支是一件坏事。

我不认为你提到的兼容性图表增加了任何有用的东西。没有可选依赖项之类的东西。如果需要，它属于“必需”部分。如果不需要，则没有依赖关系。如果另一个包可以与这个包一起使用，并且将它们放在一起是主应用程序的任务 - 这是应用程序开发人员管理的任务。

为什么我在任何地方都找不到默认的 composer.json 文件？很高兴看到每个新的 symfony 版本都有一个，这样我就可以轻松更新最重要的默认 symfony 至少需要...

这样做有什么目的？默认的 composer.json 可能会通过运行 composer init 并回答问题来创建，即添加名称、描述、许可证、开发人员联系人和 - 可选 - 一些依赖项。语义版本控制的重点是不兼容的更新被明确标记为主要版本增量，允许您在更新时不安装它们。如果你说你可以使用 Symfony 2.3 版，你应该期望 Symfony 2.99 版也能运行你的应用程序。

问题在于功能蔓延 - 您可能会不小心使用兼容的功能，例如Symfony 2.5，它会在 2.3 中被遗漏并违反您的最低版本要求。这就是 --prefer-lowest 在您的自动化测试中的用途：您应该调查测试是否失败，如果失败是由于最低版本要求中缺少功能而导致的，则更新您的版本要求 - 或者修复错误使用的功能的代码如果这是目标，则不在最低要求的版本中。

【讨论】：

斯文，非常感谢，你成功了！我的回复太长了，请在OP中看到，如果有的话，请与您的cmet一起在这里反弹。谢谢。