Skip to content

Releases: vaimo/composer-patches

Allow comments everywhere

16 Aug 12:37
Compare
Choose a tag to compare

Feature

  1. forward-port(3.32.0): allow comments on any level and with any keyword as long as it starts with underscore (_)

Halt on fist patch failure by default

15 Aug 20:07
Compare
Choose a tag to compare

This release changes the default behaviour of the module and removed bunch of old environment values that were introduced before 'composer patch' command was available.

Breaking

  1. logic: installation/update/applying patches fails on first patch failure (used to be activated by COMPOSER_PATCHES_FATAL_FAIL); old default behaviour restorable via setting COMPOSER_PATCHES_GRACEFUL or using --graceful flag
  2. config: removed COMPOSER_PATCHES_REAPPLY_ALL, COMPOSER_FORCE_PATCH_REAPPLY; replaced by 'composer patch:redo'
  3. config: removed COMPOSER_PATCHES_FATAL_FAIL, COMPOSER_EXIT_ON_PATCH_FAILURE; replaceb by COMPOSER_PATCHES_GRACEFUL
  4. config: removed COMPOSER_PATCHES_FROM_SOURCE, COMPOSER_PATCHES_PREFER_OWNER; replaced with --from-source flag on commands (was meant for testing out a patch)
  5. config: removed COMPOSER_SKIP_PATCH_PACKAGES, COMPOSER_PATCHES_SKIP_PACKAGES; never really used for anything, could be achieved via using patcher configuration

Feature

  1. allow patch failures to be passed over gracefully with --graceful flag on 'composer patch:*' commands
  2. allow patch failures to be passed over gracefully with COMPOSER_PATCHES_GRACEFUL flag
  3. allow patch failures to be passed over gracefully with extra/patcher/graceful configuration in root package

Quit wiping local changes

15 Aug 22:17
Compare
Choose a tag to compare

This release introduces additional mechanism of halting the process of applying patches when targeted package has local changes. Previous release just re-installed the package without prompting nor warning the user.

New standard behaviour is to STOP, when this is encountered to avoid potentially wiping out someone's work.

Command behaviour fixes; atomic dev embedded-info patches

14 Aug 18:36
Compare
Choose a tag to compare

Giving users the option to single out certain embedded-info patches as development-only patches by adding @type tag to them with the value of "dev" or "development".

Also includes fixes to doing partial forced re-apply (with redo) and improvements on handing bundled patches when using the before-mentioned command.

Minor fixes to validation command

12 Aug 11:58
Compare
Choose a tag to compare

The command was not usable in non-root package context when the package owned bundle patches

Validation function

12 Aug 09:47
Compare
Choose a tag to compare

Introduces new function that allows developers to double-check that they did not forget to add any of the patch target information in JSON files after including a certain path to the patch owner package. Also includes several new aliases for embedded targeting info and better sub-command support for 'patch' command that used to have way too much responsibility.

Patches with embedded target info

10 Aug 10:38
Compare
Choose a tag to compare

Major step towards getting rid of forcing user to declare information twice.

Allow users to provide a root folder for where their patches live and resolve the targets from the data that is provided within the patch itself (special tags in the patch header).

custom dependencies

18 May 10:48
Compare
Choose a tag to compare

Feature

  • allow multiple 'patches-depend' declarations for different kind of patches (bundle VS normal patch)
  • allow wildcards to be used in target names when defining multiple patches-depends items

neatness

16 May 11:03
Compare
Choose a tag to compare

Feature

  • allow multiple patch-base's to be defined based on vendor or full package name
  • new definition format that consists of description/filename and version restriction
  • allow label to be used as file-name (defined in base-path pattern as {{label}} or {{label-value}})
  • allow items without mutations (like {{label}}) to have strip-rules defined against them
  • don't display label when file name is directly part of the label

Fix

  • array-based values ended up being treated as version constraints (issue with label-version exploder)
  • label-version definition exploder not handling a list of multiple versions correctly
  • bad data type returned when base-path pattern defined and certain parts of the name did not match with any value-strip rule
  • skip flag not correctly moved to the end of the path when using patches-base configuration
  • don't append the base-path pattern with custom extras and expect users to take charge of making sure that the file name is part of the path
  • trim whitespace, slash, colon when patch source starts with space

3.24.1

02 Mar 09:25
Compare
Choose a tag to compare
debug code removed