我有一个应用程序A，它有一个composer.json文件，定义了对包p的依赖，这是我自己的新闪亮包。我的包P有一个composer.json文件，它定义了对库L和框架F的依赖关系
有一些问题确实使我的工作流程复杂化：
1）只有使用本地存储库才能定义A对p的依赖关系，如下所述：https://getcomposer.org/doc/05-repositories.md问题是，这迫使我在真正在A.上测试之前，将每一个更改都提交给P
2）参考1）这意味着每次我对p做出更改时，我都必须运行composer update。（我一开始就不想做出更改。）
3）另一方面，当不使用p中的本地存储库时，我无法定义a对p的真正依赖关系，这意味着运行composer install将不会安装p的composer.json文件中定义的依赖关系L和F。
因此，在我的观点中，有两种可能的工作流程：
1）在p中提交更改，在A中提交composer update，并查看更改的结果。
2）不要使用本地存储库作为依赖项，只需将p的composer.json文件中定义的依赖项复制到A的composeer.json文件，即可使用composer install获得依赖项L和F。
基本上，我正在寻找一个开发新composer包的工作流，在那里我可以运行composer install/update来安装所有第三方依赖项，但不需要在我自己的本地包中提交更改来测试更改。
上述问题有什么解决办法吗？
非常感谢！
当我需要同时处理多个包时，我使用的解决方案是在本地注册每个包，在composer install或第一个composer update之后，我从供应商目录中删除该包，并将其符号链接到存储本地"WIP"版本的位置。
例如：
- 在composer.json中，我需要
my_vendor/packageA，它在~/.composer/config.json中本地注册 - 我执行
composer update my_vendor/packageA是为了让composer知道我的新包 - composer安装完我的包后：
- cd vendor/my_vendor&；rm-rf包A&；ln-s../..//软件包A
这会给我留下这样的东西：
- 正在工作/
- packageA/（这是我处理packageA的地方）
- 项目A/
- 应用程序
- src
- 供应商/
- 供应商1/
- vendor2/
- my_vendor/
- 软件包A->../..//软件包A
这允许我：
- 即使从我的供应商目录中更改
packageA - 在
projectA中使用这些更改之前，我不需要提交给packageA
当packageA足够稳定时，符号链接将被删除，一切都将恢复正常，使用VCS/packagist的版本。
随着时间的推移，我尝试了不同的解决方案，我发现以上最适合我。
我可以使用的另一种解决方案是为每个前缀手动注册PSR-0目录：
<?php
$autoloader = require_once __DIR__.'/vendor/autoload.php';
$autoloader->add('MyVendor''Dummy''', '/path/to/dummy-component/src');
// now you can use MyVendor'Dummy as normal.
注：对于PSR-4，有addPsr4()方法。