使用 AWS EB cli 部署 laravel 5：UnexpectedValueException - 无效的版本字符串答案

【问题标题】：Deploying laravel 5 with AWS EB cli: UnexpectedValueException - Invalid version string使用 AWS EB cli 部署 laravel 5：UnexpectedValueException - 无效的版本字符串
【发布时间】：2015-07-30 01:06:33
【问题描述】：

所以我正准备几个月来第一次部署一些更改，但我得到了这个错误：

  [UnexpectedValueException]                                                  
  Could not parse version constraint ^1.2.2: Invalid version string "^1.2.2"

经过一番挖掘，我在 composer.lock 文件中找到了这一行：

{
    "_readme": [
        ...
    ],
    "hash": "NotTellingYou",
    "packages": [
        {
         ...
        },
         ....
        "require": {
                "nikic/php-parser": "^1.2.2",
                "php": ">=5.3.3",
                "symfony/console": "~2.1",
                "symfony/filesystem": "~2.1",
                "symfony/finder": "~2.1"
            },

但是 ehhh... 那么如何使字符串“正确”呢？我知道最新版本是 1.3，但我可以更改它吗？运行composer update时不应该是自动的吗？

【问题讨论】：

标签： amazon-web-services deployment composer-php laravel-5

【解决方案1】：

更改“nikic/php-parser”：“^1.2.2” 到 "nikic/php-parser": "1.*",

【讨论】：

工作就像一个魅力。我在主 composer.lock 中手动将每个包含“^”的实例重写为“x.*”，然后我又开始运行了。谢谢！
这不是同一个版本。原版希望至少使用 1.2.2 版，并允许兼容更新。您的替换允许 1.x 类型的每个版本，而不检查 1.1 或 1.0 是否具有软件所需的所有功能。现在这不是问题，但是一旦安装了需要较低版本的 PHP 解析器的第三个包，它就会成为问题。至少您可以使用正确的替换：~1.2,>=1.2.2。
啊，好吧。下次会这样做。我认为只要不是重大变化，最新版本总是会向后工作，例如1.2 -> 2.0

【解决方案2】：

更新您正在使用的 Composer 版本。使用^操作符的功能是在2014年12月加入的，所以现在大家应该已经拿到了更新版的Composer

composer self-update

这是防止不兼容问题的关键。请注意，Composer 仍在开发中，并且有一些 alpha 版本。使用它意味着也定期更新它。

【讨论】：

啊，我猜这意味着 AWS 使用的是过时的版本。从 git 推送我的应用程序时，AWS 会运行作曲家更新。如果他们有旧版本，那么他们用新语法报告错误是有道理的（或者它是否称为语义？）我今天已经运行 composer self-update 3 次，然后是 composer update，所以我确定我已经完成了迄今为止。
只是想说我忘记在 AWS 上更新我的实例环境。更新后也有了最新版本的composer，我不用再修改了。
有关此问题的原因和解决方案的更多详细信息，请参阅 AWS PHP 开发博客上的 Reduce Composer Issues on Elastic Beanstalk。