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.

Deprecated: SilverStripe\Config\Collections\MemoryConfigCollection implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in /var/www/html/vendor/silverstripe/config/src/Collections/MemoryConfigCollection.php on line 13

Unfortunatly we can’t control the error_reporting from SilverStripe since it is set in the kernel of the framework.
So we are forced to hack the Kernel which is rather unfortunate.

In the SilverStripe Slack channel someone proposed to use composer-patch which will apply a patch to a given vendor dependency during composer install.
This is quite cool because you don’t need to fork the dependency and take care of getting upstream changes.

So i went this path down and it looks like in this gist:
https://gist.github.com/ivoba/d8c4379236149a8c42e1922ae98a93e3

Basically you have to install composer patch:

composer require cweagans/composer-patches

Create the patch and add the patch file to your project.
You can create a patch by cloning the package i.e. silverstripe/framework into IntelliJ / PHPStorm, apply the change and under Git -> Patch create the patch file.

Then add it to composer.json so the patch can be applied on next composer install.

"extra": {
       "patches": {
            "silverstripe/framework": {
                "Fix SilverStripe deprecations error_reporting for PHP 8.1": "./fix-deprecation-error_reporting.4.10.4.patch"
            }
       }
    }

Now we have patched the error_reporting and the deprecation warnings are supressed.
Once SilverStripe fully supports PHP8.1 we then can remove this patch.

And as we are all lazy, we like generators that scaffold a basic php package layout and luckily there are several out there.
They all differ a bit, so pick your favorite.

I personally like the https://github.com/thephpleague/skeleton package template.
However its branded for the League and you would have to replace all occurences of phpleague with your namespace, which is kinda cumbersome.

So i wrote a yeoman generator which automates this, Check it out here: https://github.com/ivoba/generator-phpleague-skeleton
The generator will inquire your personal and package infos and basically just replace the counterparts in the phpleague skeleton.

If you are a yeoman fanboy, as i am :), there are two more, worth to mention:

https://github.com/T1st3/generator-composer
and
https://github.com/juliangut/generator-barephp

The package layout here doesnt differ much, the main difference is that they come with a grunt build.
So you can use grunt to run f.e. phpDoc generation, phplint, phpunit or all at once on your package with f.e. grunt test.

If you dont like yeoman and want to keep it PHP, the slides i mentioned above show two alternatives:

https://github.com/jonathantorres/construct
https://github.com/franzliedke/studio

Studio seems to be more than a normal generator though. Its rather a managment tool for developing packages.
So if you look for a generator only, Construct is probably the candidate here.

"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