正在播放:Composer 入门简介
更新时间:2年前
最好用的 PHP 依赖管理工具
标 题 | 时 间 |
---|---|
Composer 入门简介 | 02:21 |
一切都从安装开始 | 03:27 |
使用 composer require 安装 composer 包 | 05:58 |
composer install 和 composer update 初探 | 04:58 |
composer.json composer.lock 文件与 install 和 update 命令的关系 | 05:16 |
如何在开发环境和部署环境下载不同开发包 | 05:30 |
使用 Composer dumpautoload 生成自动加载文件 | 03:09 |
通过composer create-project 创建新的项目 | 04:23 |
开发包的版本号的^号和~号是怎么一回事儿 | 03:49 |
如何使用 composer 第三方开发包的功能 | 06:21 |
composer autoload 自动加载初探 | 07:00 |
通过 PSR-4 把自定义的 class 文件引入到composer 自动加载中 | 08:12 |
通过 classmap 将自定义的类文件引入到 composer 项目 | 06:32 |
通过 files 加载方式实现全局可调用的函数 | 07:13 |
通过 composer 运行 php 脚本 | 03:20 |

yang 2020-07-20 21:41:36
老哥,讨论个问题, composer 打个比方,项目之前安装了一个包a, 这个包依赖包b, 且限制了版本 后面,我们想安装包c ,这个包c 也 依赖包b, 但是 要求 版本 是 最新的, 包a,限制了包b的版本, 这个时候 包c ,安装不上,包b 更新 也只能小版本更新,不能升到最新,这个问题,如何处理好些?

codinget 2020-07-20 22:37:16
这种情况出现的概率是有的,Laravel 框架版本推进的时候就遇到了这样的问题,最后解决方案就是更为严格的语义化的版本控制,核心原则就是包的质量首先要保证,所依赖的开发包必须严格按照语义化的版本控制规范进行版本的演进,不然依赖陷阱的问题早晚会出现,而且一旦出现,很多工作完全无法推进。Laravel 演进到现在,咱们就会发现,它越来越多得依赖自己的开发包,而逐步摆脱其他的开发包,核心原因就是第三方包的不确定性。

yang 2020-07-20 22:39:39
那请问现在这个问题,有什么好的解决方案么? 可以强行更新B包把,但是 对 a包 的 使用 可能 会有影响

codinget 2020-07-20 22:48:13
如果指定版本和最新版本的接口已经发生较大变化,那基本就没法解决了,或者纯靠运气。保险的方式就是用最新版的,而a包的话,自己在项目中创建一个Service 目录,在Service目录中把a包的核心代码拷贝过来,封装一个只供自己项目使用的项目内部包,让这个包调用最新的b包提供的接口,保证项目能运行起来。这种方案用的还是比较多的,尤其老项目升级的时候,过去的很多包都用不了了,就自己封装内部的包(这种也算不上是包,因为只供自己使用)

yang 2020-07-20 22:51:52
如果强制更新B包呢,因为 是 由a依赖 安装的, json中 并没有 包B , 执行 composer update B ,也会被限制版本, 是要 修改 lock 文件么?

codinget 2020-07-20 22:55:36
如果大版本没有发生改变的话或许可行,因为核心的接口并没有发生变化,你可以先安装C包,然后再安装A包,改变顺序之后,有可能安装成功,也是碰运气。最早valet出过这种问题,改变安装顺序就安装上了

yang 2020-07-20 22:57:47
只能这样啊,我还以为可以 强制 把 包B 升到最新, 然后 a有问题的话,在解决a包的问题

暂无相关资源