Question

I'm developing a custom composer installer for proprietary software and I'm not really sure about how I'm supposed to test and debug it.

Composer loads plugins only when specified as dependency, so I create a test project which defines the plugin as a dependency, like this:

{
    //...
    "repositories": [
        {
            "type":"git",
            "url":"/path/to/gitrepo"
        }
    ],
    "require":{
        "myvendor/my-plugin":"dev-master"
    }
}

The problem is that composer uses only the latest committed version, which means that if I want to test something I have to commit it first. This leads to a lot of "useless" one line change commits (like "oh I forgot a comma there"), which I don't really want to have in my git repo history.

I suppose there has to be a better way, but I didn't find one. Ideally I would define a directory as a repository (which would the be my working directory), but as far as I know there is nothing like a "directory" type repository.

Was it helpful?

Solution

For development, it is best to reference your in-progress work as path type. In the main application, set up a package in repositories like this:

"repositories": [
    {
        "type": "path",
        "version": "dev-master",
        "url": "/home/user/log-viewer"
    }
],

Then require your plugin

composer require louisitvn/log-viewer:dev-master

They key here is to require your package as dev-master. The output may look like this:

$ composer require louisitvn/log-viewer:dev-master
Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Installing louisitvn/log-viewer (dev-master)
    Symlinked from /home/user/log-viewer

As you can see, Composer makes a symlink in vendor/ for the plugin rather than cloning it and you are always on top of the latest changes in your working directory.

OTHER TIPS

You can simply edit the code of the vendor package locally. When later composer wants to update this package, it will ask you how to deal with the modified files. In that case you simply can choose s for stashing your changes. Also see this stackoverflow for clarifying meaning of the available options.

After updating the package, your changes will get reapplied.

See the screen for an example dialog: enter image description here

For this purpose i use tags and --force push to library repo. So in my project i have something like

{
    //...
    "repositories": [
        {
            "type":"git",
            "url":"/path/to/gitrepo"
        }
    ],
    "require":{
        "myvendor/my-plugin":"dev-tag"
    }
}

When i do some changes i my library repo, i retag last commit with dev-tag tag and then

git push origin master --force --tags

So my tag is actual to last library commit. After that i do only

composer update

And i have all library code in my project.

Dont use this workflow with tags used in production code!

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top