如何在不需要提交或发布更改的情况下开发依赖的composer包?

2022-01-21 00:00:00 workflow php composer-php dependency-management package-development

我有一个应用程序 A，它有一个 composer.json 文件，它定义了对包 P 的依赖，这是我自己的新闪亮包.我的包 P 有一个 composer.json 文件，它定义了对库 L 和框架 F 的依赖关系.我的包 P 还没有远程存储库，它还没有在 packagist.org 上发布 - 我基本上是在修补它，尝试不同的东西通过在浏览器中运行应用程序 A 并不断修改我的包 P，应用程序 A 所依赖的包.

I have an application A which has a composer.json file defining a dependency on package P, which is my own new shiny package. My package P has a composer.json file, which defines dependencies on library L and framework F. My package P has no remote repository yet and it's not yet published on packagist.org - I'm basically tinkering on it, trying out different things by running application A in the browser and modifying my package P continuously, which application A depends on.

有些问题确实让我的工作流程变得复杂:

1) 定义 A 对 P 的依赖只能使用本地存储库，如下所述:https://getcomposer.org/doc/05-repositories.md 问题是，这迫使我在 A 上实际测试之前将所有更改提交到 P.

1) Defining the dependency from A on P is only possible using a local repository, like described here: https://getcomposer.org/doc/05-repositories.md The problem is that this forces me to commit every change to P before I can actually test it on A.

2) 参考 1) 这意味着我每次提交对 P 的更改时都必须运行 composer update.(我不想提交第一名.)

2) Refering to 1) this means that I have to run composer update everytime I commited a change to P. (Which I don't want to commit in the first place.)

3) 另一方面，当 不 在 P 中使用本地存储库时，我无法定义 A 对 P 的真正依赖，这意味着运行 composer install 不会安装P的composer.json文件中定义的依赖L和F.

3) On the other side, when not using a local repository in P, I can not define a real dependency from A on P which means running composer install will not install the dependencies L and F, defined in the composer.json file of P.

因此，我认为有两种可能的工作流程:

1) 在 P 中提交更改，在 A 中提交 composer update 并查看更改的效果.

1) Commit changes in P, composer update in A and see how the change worked out.

2) 不要使用本地存储库作为依赖项，只需将 P 的 composer.json 文件中定义的依赖项复制 到 A 的 composer.json 文件中能够使用 composer install 来获取依赖项 L 和 F.

2) Don't use local repositories as dependencies and just copy the dependencies, defined in the composer.json file of P to the composer.json file of A to be able to use composer install to get dependencies L and F.

基本上我正在寻找一个工作流程来开发一个新的作曲家包，我可以在其中运行 composer install/update 来安装所有 3rd 方依赖项，但无需自己提交更改用于测试更改的本地包.

Basically I'm searching for a workflow to develop a new composer package, where I can run composer install/update to install all 3rd party dependencies, but without the need to commit changes in my own local packages to test changes.

上述问题有什么解决办法吗?

Is there any solution to the mentioned problems at all?

非常感谢！

推荐答案

当我需要同时处理多个包的情况下，我使用的解决方案是在本地和之后注册每个包composer install 或在第一次 composer update 我从供应商目录中删除该软件包并将其符号链接到我存储本地WIP"版本的位置.

The solution I use when I'm in a situation where I need to work on multiple packages at the same time, is to register each package locally and after composer install or after first composer update I remove that package from vendor directory and symlink it to location where I store the local "WIP" version.

例如:

  • 在 composer.json 中我需要 my_vendor/packageA，它在 ~/.composer/config.json 中本地注册.
  • 我执行 composer update my_vendor/packageA 让 composer 知道我的新包.
  • composer 完成安装我的包后:
    • cd vendor/my_vendor &&rm -rf packageA &&ln -s ../../../packageA .
    • In composer.json I require my_vendor/packageA, which is registered locally inside ~/.composer/config.json.
    • I execute composer update my_vendor/packageA to make composer aware of my new package.
    • After composer finishes installing my package:
      • cd vendor/my_vendor && rm -rf packageA && ln -s ../../../packageA .

      这会给我留下类似的东西:

      Which will leave me with something like:

      • 工作目录/
        • packageA/(这是我在 packageA 上工作的地方)
        • 项目A/
          • 应用
          • src
          • 供应商/
            • vendor1/
            • vendor2/
            • my_vendor/
              • packageA -> ../../../packageA

              这让我:

              • 甚至从我的供应商目录中更改 packageA
              • 在我可以在 projectA 中使用这些更改之前，我不需要提交到 packageA.
              • To change packageA even from inside my vendor dir
              • I don't need to commit to packageA before I can use those changes inside my projectA.

              当 packageA 足够稳定时，符号链接将被删除，一切都会恢复正常，使用来自 VCS/packagist 的版本.

              When packageA will be stable enough, the symlink will be removed and everything will come back to normal, using the version from VCS/packagist.

              随着时间的推移，我尝试了不同的解决方案，我发现上述方法最适合我.

              I tried different solutions over the time and I found that the above works best for me.

              我可以使用的另一种解决方案是为每个前缀手动注册 PSR-0 目录:

              An alternative solution which I use when I can, is to register PSR-0 directories manually, for each prefix:

              <?php

$autoloader = require_once __DIR__.'/vendor/autoload.php';
$autoloader->add('MyVendor\Dummy\', '/path/to/dummy-component/src');

// now you can use MyVendorDummy as normal.

              注意:对于 PSR-4，有 addPsr4() 方法.

              Note: For PSR-4 there is addPsr4() method.

相关文章