Talking Drupal #536 - Composer Patches 2.0

Jan 19, 2026

Cameron Eagans, an engineering leader and full-stack software engineer, dives into the world of Composer Patches 2.0. He explains the evolution of patching dependencies, highlighting the transition from Drush Make to Composer. Their conversation covers the benefits of clear workflows and new features like patches.lock.json for better patch management. Cameron also discusses the complexities of user workflows and the importance of community contributions. Plus, he shares insights on balancing convenience with supply-chain risks in dependency-defined patches.

Ask episode

AI Snips

Chapters

Transcript

Episode notes

INSIGHT

Declarative, Traceable Dependency Patching

Composer Patches lets you declaratively apply changes to dependencies so your project runs without upstream changes.
It replaces ad-hoc patch folders with ordered, documented patch definitions inside composer.json for clarity and traceability.

ANECDOTE

Originated From An NBC Drupal Port

Cameron built the first composer-patches proof of concept for an NBC Drupal 8 distribution migration.
The plugin emerged to replace heavy Drush Make patch reliance during that porting effort.

INSIGHT

Scale Exposed Hidden Fragility

Wide adoption revealed brittle implicit behaviors and rare failure modes that were hard to reproduce.
2.0 focuses on explicit workflows, better tests, and clearer guarantees to avoid breaking many users' setups.

Get the Snipd Podcast app to discover more snips from this episode

Get the app

Today we are talking about Patching Drupal, Composer, and Composer Patches 2.0 with guest Cameron Eagans. We'll also cover Configuration Development as our module of the week.

For show notes visit: https://www.talkingDrupal.com/536

Topics

What is Composer Patches 2.0
Exploring Community Dynamics in Composer Patches
The Genesis of Composer Patches
The Decision to Use GitHub
Broadening Composer Patches Beyond Drupal
The Evolution to Composer Patches 2.0
Understanding Workflow Complexities
Refining User Experience in 2.0
New Features and Enhancements in 2.0
Navigating Controversial Changes in 2.0
The Role of Dependency Patches
Introducing patches.lock.json
Best Practices for Patch Management
Transitioning to Git Patching
Exploring New APIs in Composer Patches 2.0
Understanding Capabilities and Events
Transitioning to Composer Patches 2.0
Future of Composer Patches and Community Contributions

Resources

Guests

Cameron Eagans - cweagans.net cweagans

Hosts

Nic Laflin - nLighteneddevelopment.com nicxvan John Picozzi - epam.com johnpicozzi Andy Giles - dripyard.com andyg5000

MOTW Correspondent

Martin Anderson-Clutz - mandclu.com mandclu

Brief description:
- Do you maintain modules that provide configuration files? There's a module that can help manage them.
Module name/project name:
- Configuration Development
Brief history
- How old: created in Apr 2014 by chx, though recent releases are by Joachim Noreiko (joachim)
- Versions available: 8.x-1.11, which works with Drupal 9.3, 10, and 11
Maintainership
- Actively maintained
- Security coverage
- Test coverage
- Number of open issues: 36 open issues, 7 of which are bugs
Usage stats:
- 2,391 sites
Module features and usage
- The module really provides three useful features. First, it can ensure specific configuration files are automatically imported on every request, as though the contents were pasted into the core "single import" form
- Second, it can automatically export specific configuration objects into files whenever the object is updated. You provide a list of filenames and the module will derive the objects that need to be exported.
- Finally, it provides a drush command that can be used to generate all the necessary configuration files for a specific project. You put a list of the files into the project's info.yml file, and then with a single command a fresh copy of all the specified files will be generated and placed directly into the project's configuration folder.
- For obvious reasons this is not something you should ever have enabled in production, so definitely a best practice to pull this in using the require-dev composer command