joachim
joachim

Reputation: 30761

how do I work on a library that's included with Composer?

I maintain a package which is intended as a library for other apps, managed by Composer.

I don't understand how I am meant to work on my package, without Composer getting in the way and overwriting my work all the time.

What I want to have is this:

- some_app - vendor - my_package

where my_package is a git clone that is under MY control, where I can make test branches, push to github, etc, etc, and Composer does NOT overwrite it or change the currently checked-out commit.

BUT I want Composer to notice my package for its autoloader, and to consider its requirements satisfied for some_app to run, and composer updates on some_app to run properly.

How do I do this?

Upvotes: 0

Views: 105

Answers (1)

greg_1_anderson
greg_1_anderson

Reputation: 196

Composer does not support the exact feature that you are asking for. As a plugin of some other app, you cannot modify anything in vendor and expect it to stay. Composer will compose the entire contents of vendor directly from the information in the composer.json file. Post-processing is not allowed, unless you have directives in the composer.json file to declare hooks.

So, the right way to do this is to use a mechanism provided by the application to manage the required dependencies for your plugin. Symfony flex is one example of a Composer plugin mechanism; RoboPHP has a different one.

If the application you are attempting to extend does not support allowing its plugins to declare Composer dependencies, you could potentially create your own composer.json file, stored in some location the application does not know about, and use that to generate your own separate vendor directory with its own autoload.php file. You could then manually include your own autoload file, which would allow PHP to then include any class file contained in your vendor directory. If your plugin's dependencies are not used by the main application, and do not appear anywhere in the main application's vendor directory (including all of the dependencies of dependencies, and their dependencies, and so on), then this will work. If there is any overlap between the dependencies in your plugin and the dependencies of the main application, though, then you might find that this solution works some of the time, and fails horribly in difficult-to-diagnose ways at other times. For an explanation as to why having multiple autoload files is such a bad idea, please see the blog posts The Trouble with Two Autoloaders and Fixing the Composer Global Command.

Upvotes: 1

Related Questions