Download the PHP package iweb/composer-patches without Composer
On this page you can find all versions of the php package iweb/composer-patches. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download iweb/composer-patches
More information about iweb/composer-patches
Files in iweb/composer-patches
Package composer-patches
Short Description Applies a patch from a local or remote file to any package that is part of a given composer project. Patches can be defined both on project and on package level. Optional support for patch versioning, sequencing, custom patch applier configuration and patch command for testing/troubleshooting added patches.
License MIT
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package composer-patches
Vaimo Composer Patches
Applies a patch from a local or remote file to any package that is part of a given composer project. Patches can be defined both on project and on package level in package config or separate JSON file. Declaration-free mode (using embedded info within patch files) is available as well.
The way the patches are applied (the commands, pre-checks) by the plugin is fully configurable (including the actual commands that are executed to apply the patch) from the composer.json of the project.
Note that the plugin is kept on very old PHP version as legacy software is usually the most common context where patches are needed.
Full Documentation
- Basic Usage - Defining patches via configuration files or embedded metadata
- Advanced Usage - Advanced usage options when defining patches
- Configuration - Configuration options for the patch applier
- Commands - Details on the CLI commands that ship with the plugin
- Error Handling - Handling encountered errors
- Development - Details on the development workflow of the plugin
- Examples - Examples on usage of the plugin
- Changes - List of changes/fixes per plugin release
Quick Start
Composer packages can be targeted with patches in two ways:
- Embedded metadata (recommended default approach)
- JSON declaration and embedded (recommended for remote patches)
Usage: Embedded Metadata
Contents of patches/changes.patch:
Full list of tag options (that cover all features of the plugin can be found HERE).
Note that tags cover most of the features of the module so every explanation given for the json declaration of the patches applies for tags as well.
Usage: JSON Declaration
Contents of patches/changes.patch:
Applier Configuration
The way patches are applied can be manipulated by changing the configuration of the patcher or by introducing additional patch appliers.
In most cases there should not be much of a need to reconfigure the module as it does ship with reasonable defaults. The appliers supported by default: patch, git.
More information on said topic can be found HERE.
Upgrades
When upgrading the module, one might encounter odd crashes about classes not being found or class constructor arguments being wrong.
This usually means that the class structure or constructor footprint in some of the classes have changed after the upgrade which means that the plugin might be running with some classes from the old and some classes from the new version.
Due to the fact that the patcher kicks in very late in the process of installing a project (before
auto-loader generation), developers are advised to re-execute composer install.
Ideally, plugins should always be updated with explicit --no-plugins flag added to the composer update
call to avoid issues that plugin usage with potentially mixed logic from two different plugin releases
being in use.
All versions of composer-patches with dependencies
ext-json Version *
composer-plugin-api Version ^1.0 || ^2.0
drupol/phposinfo Version ^1.6
seld/jsonlint Version ^1.7.1
vaimo/topological-sort Version ^1.0