Composer-patches is a handy Composer plugin that applies diff patches to specific packages during installation.

Basically, you store a diff patch in your project, specify which vendor package it should be applied to in your composer.json, and the plugin will apply the patch to the original code of the vendor package after it got installed by composer.

The documentation provides detailed instructions on how to set up the plugin.
In short, you need:

• Install the plugin (we’re using the v2 beta) with:
  composer require cweagans/composer-patches:^2.0.0-beta2
• Create a patch. The plugin relies on Git as the patcher, so you can use Git to generate the patch file. (See below)
  However, I recommend using another package to create the patch file:
  https://github.com/symplify/vendor-patches
  This package provides an opinionated but reasonable way to create and store your patches. vendor-patches takes care of the correct paths in the patch file, which might not be immediately obvious: Pathes should be relative to the vendor package root and not relative to your projects root dir.
• Add the patch instructions to your composer.json by including a patches section under extra. For example:

"extra": {
  "patches": {
    "oxid-esales/oxideshop-ce": {
      "Disable user registration due to spam attacks": "./patches/disable-registerUser.patch"
    }
  }
}

On your next composer install the vendor package will be patched and the vendor’s
code will be altered according the patch.

Some notes: If you encounter the error:

Could not apply patch! Skipping. The error was: Cannot apply patch disable-registerUser.patch

You might have incorrect paths in your patch file. As mentioned above, the paths need to be relative to the vendor root directory, not your project’s root directory.
So to manually create the diff patches, run this command:

diff --git a/source/Application/Component/UserComponent.php b/source/Application/Component/UserComponent.php

This is wrong usage from project root dir:

diff --git a/vendor/oxid-esales/oxideshop-ce/source/Application/Component/UserComponent.php b/vendor/oxid-esales/oxideshop-ce/source/Application/Component/UserComponent.php

Happy patching! :)

Then upgrade to Composer 2.4 and say hi to composer dump.
This version introduced a new command composer bump which will update your composer.json file to the precise version which is pinned in the composer.lock file.
It basically will sync the composer.json with the composer.lock versions and will keep the caret version constraints, so you can still make minor or patch version upgrades.

This will have the effect that the version constraints are hardenend and you will not be able to install versions lower than the currently installed version.
With not updated versions in composer.json file you will not have a precise version base and could install lower versions than actually required.

Another benefit is that you can more easily read the currently installed version number of your dependencies.
Otherwise you would need to grep through the composer.lock file which is much less readable and cumbersome.
Some IDEs like PHPSTORM are helping here though by adding the installed version behind the dependency constraint in the composer.json file in the editor pane (see below).

Before composer bump:

After composer bump:

Note that composer dump is benefical on projects but should be avoided in libraries because it could accidently limit the versions in which can you use the library.

Also it might be a good idea to have a option on composer update to integrate composer bump functionality.

"repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/ivoba/SomeBundle.log"
        }
    ]

But there are some traps, especially when you are mentally already weekend bound:

When working in a team, take care that you dont add your fork as a private repo.
This happens when you use the @ notation like ‘git@github.com‘. Its tempting because it will be the clone url on github when you are logged in, which is very likely.
If you do so your team mates will get errors like this:

Failed to execute git clone --no-checkout 'git@github.com:ivoba/SomeBundle.git' [...] && git remote add composer 'git@github.com:ivoba/SomeBundle.git' && git fetch composer

So better change it to the notation of public repositories like ‘git://github.com‘ but take care that you change the whole path and not only the protocol like:

git://github.com:ivoba/SomeBundle.git

This will look in port “ivoba” ;) and you will get an error like:

fatal: Unable to look up github.com (port ivoba) (Servname not supported for ai_socktype)

If you try the same with https you will still fail with:

Cloning into bare repository [...]                                                         
  fatal: Unable to find remote helper for 'https'

So the correct path for public repos is:

git://github.com/ivoba/SomeBundle.git[/code]
or

https://github.com/ivoba/SomeBundle.git