How to Require a Fork With Composer

How to require a fork with composer?

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

Loading a composer package through a Github fork

The composer.json file on your fork still calls the package "spatie/ssl-certificate", so that's the name of the package you need to require.

This should work:

{
    ...
    "require": {
        ...
        "spatie/ssl-certificate": "dev-master"
    },
    ...
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/cnizzardini/ssl-certificate.git"
        }
    ],
    ...
}

If it doesn't, you can rename the package on your own fork by changing the name property in its composer.json file:

{
    "name": "cnizzardini/ssl-certificate",
    "description": "A class to easily query the properties of an ssl certificate ",
    ...
}

Working on forked GitHub repository through Composer

1. Change package constraint in composer.json to use branch instead of tagged version - you can use dev-master for master branch or dev-my-branch for my-branch branch. You may also configure branch alias.

   "require": {
       "some-vendor/some-package": "dev-master",
   }
   

2. Add a repository which points to your fork:

   "repositories": [
       {
           "type": "git",
           "url": "https://github.com/richard/some-package/"
       },
   ]
   

3. Run composer update to install new version from your fork (or composer require "some-vendor/some-package:dev-master" if you don't want to update any other dependencies).

Now you should have sources cloned from your fork in vendor/some-vendor/some-package. You can edit these files and test if changes fits to your app. After you finish your work:

1. Commit changes in your fork and push them to GitHub.
2. Go back to root of your app and run composer update or composer require "some-vendor/some-package:dev-master". This will update your composer.lock file to use latest version of your fork. Then commit changes in your lock and push.

Now if someone will clone your project (or just pull changes) it will get new composer.lock pointing to your fork with specified commit hash - composer install should always install the same version of your fork directly from GitHub.

Requiring a fork with composer that other dependencies should use

Your fork has a branch-alias for master set to 4.1.x-dev, so it doesn't match the 4.0.* requirement.

The solution is to alias the package, by requiring it like this

{
    "repositories": [
        {
            "type": "vcs",
            "url": "http://github.com/rmasters/framework"
        }
    ],
    "require": {
        "php": "5.4.*",
        "laravel/framework": "dev-master as 4.0.0"
    },
    ...
    "minimum-stability": "dev"
}

And indeed those forks should not be on Packagist, I'll contact the owners.

How to require fork of composer repo with conflicting requirements?

You need to alias your new branch as regular numeric branch, so it could be used to resolving requirements of other dependencies.

"zfcampus/zf-content-validation": "dev-alias-and-remove-empty-data as 1.7.x-dev", 

After this Composer will treat your branch as 1.7 line, so it should match ^1.4 constraint.

See Require inline alias section in documentation.

Composer - Using a custom fork of a package dependency

This was actually quite simple. Not too sure why it did not work originally! Instructions below for anyone wondering:

1. Fork the package (i.e. GitHub)
2. Add the repo from your username, to your projects main composer.json as follows:

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

3. Edit the composer.json file within the new fork you created in step 1 (youruser/tntsearch) and create/add to the extras key:

    "extra": {
        "branch-alias": {
            "dev-master": "2.0.x-dev"
        }
    }

This effectively allows you to install your dev-master version, but allow other packages where this is a dependency to request the 2.0 version (in this case). You do need to be careful in this case that you have forked the correct version and any upgrades are correctly managed later down the line, or things may break!

More info on composer alias here

4. Require/Upgrade the package using original package namespace, at the dev-master version.

composer require teamtnt/tntsearch:dev-master

The name spacing and package versions will remain the same as before your fork, but the edits from your fork will be pulled into your project instead.

---

Related Topics