top-think
是否在准备放大招？半年木有更新了，6.1大版本？
https://github.com/top-think/framework/issues/2638 只求升级下：league/flysystem，1.0和很多包冲突了。。自己又太菜，无法自己开个分支。
这个就算实现了，也有点偏门，还得看官方的意思。
我的思路就是，把本身对flysystem的使用的方法做个抽象接口，然后做一个对此的composer扩展，比如叫think-flysystem,v1,v2,v3, 每个版本都对应相应的flysystem。
这样应该不影响框架上层的使用。如果需要切换flysystem的版本，先切换think-flysystem的版本就好了。
最近没精力做，而且影响太大，得慎重。最终也得官方出面。
@augushong 官方6x版本，LTS 结束都不会更新了。。 有时候，想装别人的扩展。。 一碰有flysystem v2或以上的，就不行。。 我认为的就修改flysystem目录中的3个文件，无论的：长痛不如短痛，一劳永逸的词。只能说说而已了。。
@yzh52521 本地测试可以用，应该木有问题。 你再装下你的。https://github.com/yzh52521/thinkphp-filesystem-cloud 开个v2的分支，进行flysystem v2 化，进行测试，OK，就O了。
但是使用了flysystem v1的用户是不能升级的，依赖会冲突的。尤其是一些二开后台，早就集成了很多第三方的存储。
你说的也对，可以做成扩展，但是 官方框架集成了 除非框架移除这个
是的，这个方法有点偏门，但是并没有什么问题。 而且框架本身就把很多通用方法独立成扩展了，比如：think-helper。 这样做也比较符合框架的调性。 也不需要很大的决心，毕竟不会影响旧的生态。
现在 不升级 composer 安装框架 总是 提示 Found 1 security vulnerability advisory affecting 1 package.
但是使用了flysystem v1的用户是不能升级的，依赖会冲突的。尤其是一些二开后台，早就集成了很多第三方的存储。
关于无缝升级，只是本地，完全OK。。如果是第三方，可以在发布版本的时候告知，已升级flysystem ^v2 至于官方是否合并的事，我就说了嘛，长痛不如短痛/一劳永逸 或 墨守成规 的抉择了。
不是你说的这样的。 你其实也完全可以fork一份仓库，然后再composer指定自己的源。不再用官方的源。对于一个项目来说是完全可以的。
这也不是墨守成规，也不是发个通知就完事了的。
不是你说的这样的。 你其实也完全可以fork一份仓库，然后再composer指定自己的源。不再用官方的源。对于一个项目来说是完全可以的。
这也不是墨守成规，也不是发个通知就完事了的。
可以这样吗？我菜鸟额。。
官方的有些扩展 还依赖框架的 比如 topthink/think-trace topthink/think-multi-app 这些也得自己去fork一份的
不需要，这个是composer的一个特性，如果你只定制了think-framework的几个文件，那么这样写就行：
{
"repositories": [
{
"type": "git",
"url": "[email protected]:ulthon/framework.git"
}
],
}
这里只是举个例子，这样composer会加载ulthon/framework而不是公共仓库里的代码。 你可以试试。
我这里的链接是假的，你换成你自己的fork的版本。
fastadmin就是这么搞的。你可以看一下他的代码，他的composer.json。 composer的文档里也有说明。 你自己有问题有需求，现在有方案，那就立即动手啊。
fastadmin就是这么搞的。你可以看一下他的代码，他的composer.json。 composer的文档里也有说明。 你自己有问题有需求，现在有方案，那就立即动手啊。
那是不是，不能同步更新官方的：top-think/framework了？每次官方更新：framework，我都得更正拉取下？