How to develop a dependent composer package without the need to commit or publish changes?

Question

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!

Answer 1

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.