209

This is my composer.json, I want to use Nodge's fork of lessphp project on Github

 "repositories": [{
    "type": "package",
    "package": {
        "version": "dev-master",
        "name": "nodge/lessphp",
        "source": {
            "url": "https://github.com/Nodge/lessphp.git",
            "type": "git",
            "reference": "master"
        },
        "autoload": {
            "classmap": ["lessc.inc.php"]
        }
    }
}],
"require": {
    "php": ">=5.3.3",
    "nodge/lessphp": "dev-master"
},

But I get this error when I run composer update:

nodge/lessphp dev-master -> no matching package found.

I don't know how to require correctly this fork.

Neilime
  • 2,627
  • 2
  • 14
  • 9

8 Answers8

296

The most common (and easiest) way of doing it is using a VCS repository.

All you have to do is add your fork as a repository and update the version constraint to point to your custom branch. Your custom branch name must be prefixed with dev-.

Assuming you forked monolog/monolog and created a branch called bugfix, you would update your composer.json like this:

{
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/igorw/monolog"
        }
    ],
    "require": {
        "monolog/monolog": "dev-bugfix"
    }
}

Note that you don't change the require statement except to specify your bugfix branch. You still reference the upstream package (monolog/monolog), not your personal fork (igorw/monolog), and the branch name is prefixed with dev-. You can read details in the docs

miken32
  • 42,008
  • 16
  • 111
  • 154
Seldaek
  • 40,986
  • 9
  • 97
  • 77
  • 6
    This doesn't seem to work for https://github.com/Polycademy/purl which is a fork of https://github.com/jwage/purl I've been trying to: "repositories": [ { "type": "vcs", "url": "git@github.com:Polycademy/purl.git" } ], and "require": { "jwade/purl": "dev-master", }, But I keep getting: Problem 1 - The requested package jwade/purl could not be found in any version, there may be a typo in the package name. – CMCDragonkai Oct 24 '13 at 07:27
  • 14
    @CMCDragonkai try running `composer show jwade/purl -v` it should tell you why it ignored the dev-master version if it does. – Seldaek Oct 24 '13 at 11:25
  • @CMCDragonkai You must get the right github subversion url clicking un "Subversion" near the repo url field. – Emilio A. L. Jan 31 '14 at 10:28
  • 4
    @seldaek you saved me! thank you! ( My fork was called dev-dev-.. ) didn't know the naming was automatically. – Miguel Stevens Mar 09 '15 at 21:11
  • composer show is the key to find the name of the branch! thanks @Seldaek – Sangar82 May 28 '15 at 13:44
  • 21
    "Read the docs" is a bad answer, a better answer would be to give a concrete example – oskarth Apr 05 '16 at 10:00
  • 8
    Nice to warn about not referencing to personal fork. This saved my day, +1 – edrian Jun 09 '17 at 14:38
  • 5
    Your branch name does not need to add `dev-` you will end up duplicated dev-dev- when you require in composer.json file. This is why our master branch when you required in composer.json, you have added in as `dev-master` – Shiro Dec 20 '17 at 13:56
  • this isn't working for me, and unfortunately i'm using someone else's work so i don't get to rename their branch (and i'm too lazy to fork a fork.. just saying that makes my jaw hurt).. details [here](https://github.com/maknz/slack-laravel/pull/11#issuecomment-360841508) – abbood Jan 26 '18 at 16:58
  • 1
    Any way to _not_ need a GitHub OAuth token for this solution? I'm trying this solution, but it's asking me for an OAuth token to go over the API rate limit. I don't want to need to do that on every environment I deploy to. – CGriffin Feb 01 '18 at 17:10
  • 1
    Apparently, the package name to use in the `require` entry needs to be the one defined in the `name` entry of the fork's `composer.json` file. Fork authors can choose to change or to keep the identifier. – Álvaro González Jul 19 '18 at 11:11
  • thanks @ÁlvaroGonzález I was struggling as the original author changed his name but in composer.json was the original name .. – Matúš Matula Feb 12 '19 at 16:04
  • @CGriffin did you ever figure out how to get around the rate limit? When I composer require using this method it looks like it's hitting every single version, it takes forever, and I hit my rate limit every single time. – Gisheri Aug 29 '19 at 18:18
  • What if a package has the package I'm overwriting as a dependency, then using dev-master doesn't work it says it doesn't match the constraints – Tofandel Aug 08 '22 at 13:50
53

Using VCS works:

"name": "test/test",
"repositories": [{
    "type": "vcs",
    "url": "http://github.com/Nodge/lessphp"
}],
"require": {
    "leafo/lessphp": "dev-master"
},

But if I require a module that has this composer.json, it doesn't work. It installs the original project, not the fork.

Example

"name": "example/example",
"require": {
    "test/test": "dev-master"
},

I should mention again the repository. Is that normal?

Neilime
  • 2,627
  • 2
  • 14
  • 9
  • 1
    same here same problem – Aysennoussi May 23 '14 at 10:01
  • Manually delete the module using "rm -rf" and then "composer update". That worked for me. – Hubert Perron Dec 03 '14 at 14:44
  • 7
    I've used a dozen of forks, and **this never worked**. Here's a working solution: http://stackoverflow.com/a/27970559/183904 – Julien Jan 15 '15 at 18:42
  • 4
    @Julien, I've just used this method and it worked like a charm... The [docs](https://getcomposer.org/doc/05-repositories.md#vcs) are quite clear, you must only remember to put the *dev-* prefix in your custom branch name when requiring the package in question. – mTorres Jan 17 '15 at 10:59
  • 2
    Worked for me... but I want to mention that I needed to use https:// for the URL. – plong0 Apr 24 '15 at 18:34
  • I solved this by "tagging" a new version on my fork - i.e. from 1.1.0 to 1.2.0 - and that allowed me to solve the issue – Laurence Jan 20 '17 at 01:29
47

If you can't get @Neilime answer to work for you, make sure your fork uses a different branch.

For example push your changes to a branch on your fork called my-bugfix, do not added dev- prefix in your branch name but in your composer.json you have to add it. Your composer file will look like:

"repositories":
[
    {
        "type": "vcs",
        "url": "http://github.com/yourname/packageName"
    }
],
"require": {
    "owner/packageName": "dev-my-bugfix"
},
Shiro
  • 7,344
  • 8
  • 46
  • 80
Boedy
  • 6,647
  • 1
  • 21
  • 24
  • 1
    This is ingenious and clear explanation for me ! Thank You ! – Dominik Jul 18 '17 at 20:40
  • 2
    but what if it's someone _else's_ fork? See example [here](https://github.com/maknz/slack-laravel/pull/11#issuecomment-360841508) – abbood Jan 26 '18 at 16:56
  • Also, `name` field in your forked repository's `composer.json` file should stay the same with the original owner. – NecipAllef Mar 23 '18 at 08:27
18

I have tried many options but After I got this post I saw the light and it just worked perfect.

This is what you have to do:

1- Fork The repository

2- Create a branch and make the required modifications.

3- Add the repository label to your composer.json

"repositories": [
     
        {
            "type": "vcs",
            "url": "https://github.com/user/yourforkname"
        }
    ]

4- In the command line inside your project require your fork like this:

composer require vendor/packagename:dev-branchname

And Voilá!!

You have your fork version working

Mohamed Saleh
  • 2,881
  • 1
  • 23
  • 35
Luis Mata B.
  • 312
  • 3
  • 8
7

According to the Composer documentation http://getcomposer.org/doc/05-repositories.md#vcs, it's enough to specify the original repository (not the fork) in the require ("nodge/lessphp" in your case). Composer will then install YOUR fork (look at the code in the vendors)

E Ciotti
  • 4,740
  • 1
  • 25
  • 17
7

So, this is 2019, and most of the answers here are already correct.

If you find yourself however, in a situation where you need to require a particular branch of your fork (that you created), have composer list the available versions/tags first. This saved me a lot of time.

A full example with spatie/laravel-backup package.

First, add repositories key to composer.json. With the url of your fork

"repositories": [{
   "type": "vcs",
   "url": "https://github.com/holymp2006/laravel-backup"
 }]

Get available versions/tags

composer show "spatie/laravel-backup" --all

Choose the version you want from versions in the terminal output, then require that version

composer require spatie/laravel-backup:v5.x-dev
Sam
  • 304
  • 4
  • 12
2

I usually add a "dist" node to the package definition. I never had a problem using it this way.

I can't remember where I got this trick from, though, for any further explanations.

{
    "repositories": [
        {
            "type": "package",
            "package": {
                "version": "dev-master",
                "name": "nodge/lessphp",
                "source": {
                    "url": "https://github.com/Nodge/lessphp.git",
                    "type": "git",
                    "reference": "master"
                },
                "autoload": {
                    "classmap": ["lessc.inc.php"]
                },
                "dist": {
                    "url": "https://github.com/Nodge/lessphp/archive/master.zip",
                    "type": "zip"
                }
            }
        }
    ],
    "require": {
        "nodge/lessphp": "*"
    }
}
user3497737
  • 161
  • 1
  • 2
1

The accepted answer and clarifying answers all worked well for me when I had ex. an application, which needed a dependency I had forked and modified. I’d still use the accepted answer in this case.

However, when I had a package I wanted to distribute myself on Packagist, which also contained a forked and modified dependency, this approach no longer worked.

If someone were to try and install with this config, they’ll still get that same -> no matching package found. error message.

This answer and the linked Composer docs suggest that the repo settings have to be at the top-level composer.json. That means, someone installing this package would have to add that config to their composer.json file too—which adds a lot of unnecessary confusion to the install process.

Instead, I published my fork to Packagist. My understanding is that while forks are frowned upon, this would be considered a maintained fork, since I am using it for this new package.

Hopefully that’s helpful for anyone who has this problem with a package or library they’d like to distribute.

kennethormandy
  • 2,080
  • 14
  • 16