Weave Code
Vendor Patches Laravel Package
symplify/vendor-patches
Symplify Vendor Patches generates vendor patches for your Composer packages with a single command. Copy a vendor file with a .old suffix, edit the original, then run generate to create patch files and auto-configure cweagans/composer-patches.
Symplify Vendor Patches simplifies patching third-party Composer dependencies by generating patch files automatically. Instead of manually creating diffs, you copy a vendor file with a .old suffix, edit the original, and run a single command—the tool produces ready-to-use patches and wires them into cweagans/composer-patches.
- One-command generation via
vendor/bin/vendor-patches generate - Unique, predictable patch names based on the original file path in
/patches - Automatic
composer.jsonconfiguration forcweagans/composer-patches - Safe workflow—original
.php.oldcopies are ignored, so edited code is tested before patching - Compatibility with cweagans/composer-patches v2 through
patches-relockand re-apply steps
Frequently asked questions about Vendor Patches
- What does symplify/vendor-patches do for a Laravel project?
- It is a development-time CLI that diffs a modified vendor file against a .old copy, writes a unified .patch file into /patches, and registers the patch under extra.patches in composer.json for cweagans/composer-patches. It does not load into the Laravel container, service providers, config cache, or request path, so it cannot affect Octane workers, queues, or bootstrapping at runtime. Think of it as the authoring half of a two-tool workflow, with cweagans/composer-patches responsible for applying patches during Composer installs.
- How do I install symplify/vendor-patches in a Laravel project?
- Run composer require --dev symplify/vendor-patches. If patches must apply in production, also require cweagans/composer-patches explicitly and ensure the plugin is allowed in config.allow-plugins. There is no config file or publishable asset; the tool exposes only CLI flags such as --patches-file, --patches-output, and --resolve-from-directory.
- Does symplify/vendor-patches affect Laravel runtime or Octane?
- No. It is inert at runtime and never enters the Laravel service provider graph, config cache, or request lifecycle. The artefact it produces is a plain unified diff plus a Composer config key consumed by cweagans/composer-patches. That makes it a strong architectural fit for Laravel, including Octane and queue-heavy applications, because the tool itself is not executing in production.
- How do I create a vendor patch for a Composer package in Laravel?
- Copy the vendor file you want to change to the same path with an .old suffix, then edit the live file and verify the change works. Run vendor/bin/vendor-patches generate, which creates a uniquely named patch in /patches and adds the cweagans/composer-patches entry to composer.json. With cweagans/composer-patches v2, follow up with composer patches-relock and composer patches-repatch, then composer update --lock and composer install.
- Which Laravel and PHP versions are supported by symplify/vendor-patches?
- The package fits Laravel 10-12, PHP 8.2-8.4, and any Composer 2 project; version 12.2.0 retargeted PHP 8.4 and removed three dependencies. Always verify compatibility on each major bump because the package has a history of monorepo splits and retirements. The runtime patch behaviour depends on your cweagans/composer-patches major, not on Laravel itself.
- Do I need cweagans/composer-patches to use symplify/vendor-patches?
- Yes, for actual patch application you need cweagans/composer-patches. symplify/vendor-patches only generates the diff and writes the extra.patches configuration; it is not a patch applier. If you patch production builds, cweagans/composer-patches must be a non-dev dependency and the deploy image must include patch and git. A non-allowlisted Composer plugin means patches silently do not apply.
- How do vendor patches work with cweagans/composer-patches v2 and patches.lock.json?
- cweagans/composer-patches v2 changed the patch header contract, requiring --- /dev/null to become --- <file-path>, and introduced patches.lock.json. After generating with symplify/vendor-patches, run composer patches-relock to update the lock file and composer patches-repatch to apply the new patches. This v2 migration is the most likely production-breakage vector and is inherited from cweagans/composer-patches, not caused by symplify.
- Will vendor patches apply in production deployments and CI?
- Patches can apply in production builds only if cweagans/composer-patches is a non-dev dependency and the deploy image has patch and git available. macOS often needs gpatch in PATH, while Alpine or BusyBox images may behave differently or fail silently if patch is missing. Decide whether dev/CI-only patching is sufficient or production must apply patches, and validate the deploy platform accordingly.
- What are the risks of using .old files and vendor patches in Laravel?
- The main risk is process, not code: modified vendor files can be overwritten, and committed .old files are stale-by-definition artefacts that invite confusion. Community write-ups often describe a vendor-patches.yaml registry that this package does not have, so scope from the README rather than secondary sources. Keep the patch corpus owned, set a maximum TTL for un-upstreamed patches, and record attribution obligations for modified MIT or Apache code.
- Is symplify/vendor-patches maintained and what are the alternatives?
- Adoption signal is weak at roughly 190 stars and zero dependents, with readme-level maturity and a single-maintainer, monorepo-split history. Treat it as an unowned convenience tool, verify each major bump, and expect churn rather than guaranteed abandonment. Lock-in is low because the output is a standard unified diff; if the package disappears, diff -u can reproduce the patch and the patches keep applying.
Weaver
How can I help you explore Laravel packages today?