感觉又是被 composer 搞得水深火热的一天

不太了解 php 生态，不过这个项目是感觉用的还挺广泛的。
这 issue

看的人好紧张，不过开发者也挺迅速的

没有特殊情况，只要 composer install 就好了，为啥没事 update

表示受害者之一，上午还好好地用着 composer，傍晚开始想创建个新的 Laravel 项目就一直不成功了，我还以为是网络的原因，浪费几个小时

@vvhhaaattt
@JaguarJack
应该还是影响到了一大批无辜的 laravel 用户

@skymei 确实是这样的，但是上游包出问题始料未及

@lshero 下午想创建新的 Laravel 项目，发现出问题，直奔 Laracasts，果然炸了

Composer 没有 lock 文件的吗？一般为了安全，很多包管理都有 lock 文件来锁版本的。

开发环境 update 就挂了，然后直接锁了上个版本号，就没问题了。。。

线上环境肯定会根据 composer.lock 来处理的，这种小问题，有啥可大惊小怪的

@limingxinleo 说好一键创建项目开箱即用的框架准备创建项目就各种翻车，这还不难受吗？

@lshero 这有啥难受的，这种问题看一眼不就知道哪里的问题了么？花个两分钟，版本退回去就行了。

@lshero 比如这次事故，创建项目发现 psr4 加载出现了问题，composer 直接都提醒了，所以这个问题很好解决。

那 80%应该是 symfony 的版本有问题，毕竟之前没有这种情况，就到官方 github 去看看，果然刚刚发布了新的 release，然后找到版本号，主动切换到上个版本，重新 composer update -o

解决问题。

这一套走下来，不超过 5 分钟就解决了。

@limingxinleo 一般人只会去看 laravel/laravel 中指定包的版本号，symfony 的版本在 laravel/framework 中指定的。开箱即用的话还需要关心 laravel/framework 的依赖吗？

@lshero 好吧，你说得对。

我一直以为我上面说的应该是一个程序员的基本能力。。。。

我去过的公司很多人都不知道 composer.lock 的作用，甚至都不放到代码版本里， 部署就直接运行 composer update

@limingxinleo 你说的确实是 debug 的基本能力，但是在一个团队里架不住总会有短板。所以有些 KPI 项目不就是最看不起的各种造各种轮子，然后用 satis 搞成私有包。假如昨有人提交了一个需求说有新的 CVE 要求你升级 laravel 到某个版本，但是贸然的 update 一下，是不是就该突然觉得生活里导出都是磕磕绊绊了。

@timsims composer.lock 不加入仓库里环境容易不一致，加入后多人用起来有起冲突后好酸爽。

@lshero 所以，如果这些东西都整不明白，直接让领导把版本都锁了就行了，不使用 ^1.0 这种，而是直接 1.0.8 这样

@lshero 不过底层包还是比较尴尬，很难防止 symfony 的这个情况