如何开发一个依赖的composer包而不需要提交或发布更改？ [英] How to develop a dependent composer package without the need to commit or publish changes?

问题描述

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

有一些问题使我的工作流程变得复杂：

1）只有使用本地存储库才能定义A对A的依赖关系，如下所示： https://getcomposer.org/doc/05-repositories.md 问题是，这迫使我

2）参考1）这意味着我必须运行 composer update 每次我对P进行更改（我不想在第一时间提交。）

3）另一方面，当不是在P中使用本地存储库时，我不能在P上定义A的真正依赖关系，这意味着运行 composer install 将不会安装在P的composer.json文件中定义的依赖项L和F.
$ b

，在我的对手中有两种可能的工作流程：

1）提交P，

2）不要使用本地存储库作为依赖关系只需将P的composer.json文件中定义的依赖关系复制到A的composer.json文件即可使用 composer install 要获取依赖项L和F。

基本上我正在寻找一个工作流来开发一个新的composer包，其中我可以运行 composer install /更新以安装所有第三方依赖项，但不需要在自己的本地包中提交更改以测试更改。

有任何解决方案

解决方案

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

例如：

• 在composer.json中，我需要 my_vendor / packageA ，其在〜/ .composer / config.json 中本地注册。


• 我执行 composer update my_vendor


• 作曲家完成安装我的软件包后：
  
  
  
  • cd vendor / my_vendor&&& rm -rf packageA&& ln -s ../../../packageA。
  
  

将给我留下类似的东西：

• working_dir /
  
  
  
  • packageA / >这是我在packageA上工作的地方）
  
  
  • projectA /
    
    
    
    • app
    
    
    • src
    
    
    • vendor /
      
      
      
      • vendor1 /
      
      
      • vendor2 /
      
      
      • my_vendor /
        
        
        
        • packageA - > ../../../ packageA
        
        
      
      
    
    
  
  

b $ b

这允许我：

• 要更改 packageA 在我的供应商dir


• 我不需要提交 packageA > projectA 。

当packageA足够稳定时，符号链接将被删除，正常，使用VCS / packagist的版本。

我尝试了不同的解决方案，我发现上面的效果最好。
$ b

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

 <？php 
 
 $ autoloader = require_once __DIR __。'/ vendor / autoload.php'; 
 $ autoloader-> add（'MyVendor\\Dummy\\'，'/ path / to / dummy-component / src'）; 
 
 //现在你可以正常使用MyVendor \Dummy。 
  

注意：对于PSR-4，有 addPsr4（）方法。

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.

There are some problems which really complicate the workflow for me:

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) 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) 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.

So, in my oppinion there are two possible workflows:

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

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.

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?

Thanks a lot!

解决方案

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.

For example:

• 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:

• working_dir/
  • packageA/ (this is where I work on packageA)
  • projectA/
    • app
    • src
    • vendor/
      • vendor1/
      • vendor2/
      • my_vendor/
        • packageA -> ../../../packageA

This allows me:

• 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.

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.

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 MyVendor\Dummy as normal.

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

这篇关于如何开发一个依赖的composer包而不需要提交或发布更改？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！