Why a 2.0 rewrite was needed

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

• 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

• Announcing Composer Patches 2.0
• Recipe issue for config devel
• Docs
• Patch man page

Cameron Eagans - cweagans.net cweagans

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

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