Test and Debug Composer plugins

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.

score 8 · Accepted Answer · answered Aug 21 '18 at 02:05

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.

score 4 · Answer 2 · edited May 23 '17 at 12:24

4

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

edited May 23 '17 at 12:24

Community

1
1

answered Dec 27 '14 at 12:04

derhasi

709
6
7

3

While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. – mishik Dec 27 '14 at 12:26
@mishik I had no option to implement the image. – derhasi Dec 27 '14 at 13:45
@AbcAeffchen, thanks for implementing the image for me. – derhasi Dec 27 '14 at 13:46

score 0 · Answer 3 · answered Dec 27 '14 at 12:25

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!

Test and Debug Composer plugins

3 Answers3