This is happening on both Composer install\update after I've initially updated the patches file. The next time I run an install or update however the package is reinstalled and patched as expected.

This is the terminal output when the package is not reinstalled:

The extra section of my composer.json

"extra": {
        "installer-paths": {
            "web/core": ["type:drupal-core"],
            "web/modules/contrib/{$name}": ["type:drupal-module"],
            "web/profiles/contrib/{$name}": ["type:drupal-profile"],
            "web/themes/contrib/{$name}": ["type:drupal-theme"],
            "drush/contrib/{$name}": ["type:drupal-drush"]
        },
        "merge-plugin": {
            "include": [
                "web/modules/custom/*/composer.json"
            ],
            "recurse": true,
            "replace": false,
            "merge-extra": false
        },
        "patches-file": "composer.patches.json"
    }

and my composer.patches.json

{
  "patches": {
    "drupal/devel": {
      "Patch title": "https://www.drupal.org/files/issues/wrong_dependencies_are-2629828-6.patch"
    }
  }
}

When running composer install, I expect the composer.lock file to be respected, but instead, the patches defined in composer.json are always used. This isn't critical by any stretch, but it's not consistent with the way composer works.

Proposal:

• Respect composer.json during composer update
• Respect composer.lock during composer install

I tried it with file:///patches/mypatch.patch but this do not work with parse_url. Therefore I believe we need here a better way.

Patches gets outdated, is it possible to restrict one patch to one version and make sure it doesn't apply to newer ones?

README says it's not required, but couldn't find if it's still be possible.

If patch1.diff and patch2.diff both modify the same file, patching will fail. As a user, I should be able to manually apply both patches, and then somehow tell composer-patches about the result of applying both patches. At this point, composer-patches would generate a new diff, store it in the repository and tell the user to commit it to VCS. For future composer install operations, composer patches would then use the pre-resolved version that's stored in the repository.

After patching a module, unless you remove the directory where the patched module is located, there is a message about "the package has modified files" which you have to discard or the module will fail to download and be re-patched. Below is an example:

`Gathering patches for root package.
Gathering patches for dependencies. This might take a minute.

• Updating drupal/ajax_comments dev-8.x-1.x (44b6bf2 => 44b6bf2)
  The package has modified files:
  M ajax_comments.module
  M src/Utility.php
  Discard changes [y,n,v,d,s,?]? n
  Update failed (Update aborted)
  Would you like to try reinstalling the package instead [yes]? yes
• Removing drupal/ajax_comments (dev-8.x-1.x)
  The package has modified files:
  M ajax_comments.module
  M src/Utility.php
  Discard changes [y,n,v,d,?]? y
• Installing drupal/ajax_comments (dev-8.x-1.x 44b6bf2)
  Cloning 44b6bf2
• Applying patches for drupal/ajax_comments`

Hi, I'm trying to use an external file to install patches, but they are only installed if I set them into the composer.json.

My extra section:

My external file:

composer.json and composer.patches.json are in the same folder. If I move the code in the composer.patches.json in the extra section it works perfectly. I don't know what I'm doing wrong...
Sorry for my bad english and thanks for any help.

i applied some core patches which works for the composer setup.
Then i added a own patch and added this:

http://patches.wondrous.ch/files/acquia_cloud_undefined_index_secret.patch

This patches 1 line in core which fixes a notice on acquia hosting.
Composer Patches always tells me that the patch can not be applied, could you perhaps tell me why?

The File is on Amazon s3, does it need a special mime type or something?

In Patches.php:104 there is a return statement when no patches or patches-file key is found in the root-level extra key of composer. This means that patches that are defined in required packages are not read or applied (this is done at line 107). In order to get patches in required packages to apply, we must add "patches": {} in the extra section of the root-level composer.json file.

If this is desired behavior, an exception should be thrown explaining what is expected.

https://www.drupal.org/files/issues/drupal-migrate_skip_on_value-2711949-2.patch

I'm using drupal-composer/drupal-project and when I try to apply the patch listed above, it creates it as web/core/core/core/modules/migrate/src/Plugin/migrate/process/SkipOnValue.php, etc.

After patching a module, unless you remove the directory where the patched module is located, there is a message about "the package has modified files" which you have to discard or the module will fail to download and be re-patched. Below is an example:

`Gathering patches for root package.
Gathering patches for dependencies. This might take a minute.

• Updating drupal/ajax_comments dev-8.x-1.x (44b6bf2 => 44b6bf2)
  The package has modified files:
  M ajax_comments.module
  M src/Utility.php
  Discard changes [y,n,v,d,s,?]? n
  Update failed (Update aborted)
  Would you like to try reinstalling the package instead [yes]? yes
• Removing drupal/ajax_comments (dev-8.x-1.x)
  The package has modified files:
  M ajax_comments.module
  M src/Utility.php
  Discard changes [y,n,v,d,?]? y
• Installing drupal/ajax_comments (dev-8.x-1.x 44b6bf2)
  Cloning 44b6bf2
• Applying patches for drupal/ajax_comments`

See composer-patches-plugins updated documentation

Hi, I'm curious if you use http://github.com/drupal-composer/drupal-core and whether you have a way of handling patches using this this component.

In addition to the patch title and URL, there should be an optional checksum to verify the file. This is critical for security particularly when applying patches from d.o or other external sources.

Drupal make supported this with md5.

After patching a module, unless you remove the directory where the patched module is located, there is a message about "the package has modified files" which you have to discard or the module will fail to download and be re-patched. Below is an example:

`Gathering patches for root package.
Gathering patches for dependencies. This might take a minute.

• Updating drupal/ajax_comments dev-8.x-1.x (44b6bf2 => 44b6bf2)
  The package has modified files:
  M ajax_comments.module
  M src/Utility.php
  Discard changes [y,n,v,d,s,?]? n
  Update failed (Update aborted)
  Would you like to try reinstalling the package instead [yes]? yes
• Removing drupal/ajax_comments (dev-8.x-1.x)
  The package has modified files:
  M ajax_comments.module
  M src/Utility.php
  Discard changes [y,n,v,d,?]? y
• Installing drupal/ajax_comments (dev-8.x-1.x 44b6bf2)
  Cloning 44b6bf2
• Applying patches for drupal/ajax_comments`

This should be done after #12

Need a way to update the patches we're tracking in composer.lock, but not mess with lib versions or anything else. Possibly something like composer update --patches.

Drupal core is in web/. After applying patch https://www.drupal.org/files/issues/2673628-17.patch (from https://www.drupal.org/node/2673628) the patch correctly applies but I'm getting also a duplicate file in web/core/b/core/modules/system/src/Tests/Update/CustomStorageEntityDefinitionUpdateTest.php. I suspect "b" comes from an incorrect usage of system patch command (missing probably the -p1?) but the patch is correctly applied, the file is also present in the right location.

Note that In my case the patch is applied, not from d.o, but from local filesystem.

Relevant composer.json lines:

  ...
  "require": {
    "composer/installers": "^1.0.20",
    "cweagans/composer-patches": "~1.0",
    ...
    "drupal/core": "8.1.7",
    ...
  }
  ...
  "extra": {
    "installer-paths": {
      "web/core": ["type:drupal-core"],
      ...
    },
    "patches": {
      "drupal/core": {
        ...
        "Ignore custom storage field definition removals/additions @see https://www.drupal.org/node/2673628": "patches/2673628-17.patch"
      },
      ...
    }
    ...
  }
...

I might be in the minority but my primary workstation is a Windows machine. I believe this is causing parts of this plugin to not work.

I'm working on a Drupal 7.x project in which I'm trying to use the Twitter module. There's a documented bug, with patch, posted here:

https://www.drupal.org/node/2584363

When I attempt to apply that patch through this plugin, I get the following:

https://www.drupal.org/files/issues/trying_to_get_property-2584363-5_0.patch (Property of non-object)
cd "web/sites/all/modules/contrib/twitter/" && GIT_DIR=. git apply --check "-p1" "/tmp/575f098747286.patch"
'GIT_DIR' is not recognized as an internal or external command,
operable program or batch file.

Best I can tell, the GIT_DIR is redundant to the cd command. If I remove the GIT_DIR clause directly from the plugin source, the patch works.

Hello,

We work with vagrant and use composer to install drupal, modules and patch. I test cweagans/composer-patches in replacement of netresearch/composer-patches-plugin. I've change the composer.json file and generated composer.lock.

The problem: when we make the conversion of an other vagrant machine where we have recovered json and lock file of composer, after clear the cache of composer, the first composer install fail. The second works, the error doesn't reappear. Here the log of my error:

composer install --verbose

Gathering patches for root package.
Removing package drupal/addressfield so that it can be re-installed and re-patched.
Deleting sites/all/modules/contrib/addressfield/ - deleted
Removing package drupal/views so that it can be re-installed and re-patched.
Deleting sites/all/modules/contrib/views/ - deleted
Removing package drupal/chosen so that it can be re-installed and re-patched.
Deleting sites/all/modules/contrib/chosen/ - deleted
Removing package drupal/globalredirect so that it can be re-installed and re-patched.
Deleting sites/all/modules/contrib/globalredirect/ - deleted
Removing package drupal/search_api_elasticsearch so that it can be re-installed and re-patched.
Deleting sites/all/modules/contrib/search_api_elasticsearch/ - deleted

pre-install-cmd: XXXComposerScripts\PlatformInstall::preventGitReset
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Analyzed 247 packages to resolve dependencies
Analyzed 582 rules to resolve dependencies
Gathering patches for root package.
Gathering patches for dependencies. This might take a minute.
Found 2 patches for drupal/search_api_elasticsearch.
Found 2 patches for drupal/chosen.
Found 1 patches for drupal/addressfield.
Found 3 patches for drupal/views.
Found 1 patches for drupal/globalredirect.
No patches found for XXX/drupal-composer-project-patches.

• Downloading drupal-7.35.zip from http://ftp.drupal.org/files/projects/drupal-7.35.zip
  Downloading: 100%
  Extracting drupal-7.35.zip to /vagrant/src/

No patches found for drupal/drupal.

• Installing drupal/addressfield (7.1.1)
  Downloading: 100%
  Extracting archive

  • Applying patches for drupal/addressfield

  [ErrorException]
  Array to string conversion

Exception trace:
() at /vagrant/src/sites/all/vendor/cweagans/composer-patches/src/Patches.php:227
Composer\Util\ErrorHandler::handle() at /vagrant/src/sites/all/vendor/cweagans/composer-patches/src/Patches.php:227
cweagans\Composer\Patches->postInstall() at n/a:n/a
call_user_func() at phar:///usr/local/bin/composer/src/Composer/EventDispatcher/EventDispatcher.php:152
Composer\EventDispatcher\EventDispatcher->doDispatch() at phar:///usr/local/bin/composer/src/Composer/EventDispatcher/EventDispatcher.php:112
Composer\EventDispatcher\EventDispatcher->dispatchPackageEvent() at phar:///usr/local/bin/composer/src/Composer/Installer.php:606
Composer\Installer->doInstall() at phar:///usr/local/bin/composer/src/Composer/Installer.php:230
Composer\Installer->run() at phar:///usr/local/bin/composer/src/Composer/Command/InstallCommand.php:131
Composer\Command\InstallCommand->execute() at phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Command/Command.php:257
Symfony\Component\Console\Command\Command->run() at phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php:874
Symfony\Component\Console\Application->doRunCommand() at phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php:195
Symfony\Component\Console\Application->doRun() at phar:///usr/local/bin/composer/src/Composer/Console/Application.php:146
Composer\Console\Application->doRun() at phar:///usr/local/bin/composer/vendor/symfony/console/Symfony/Component/Console/Application.php:126
Symfony\Component\Console\Application->run() at phar:///usr/local/bin/composer/src/Composer/Console/Application.php:82
Composer\Console\Application->run() at phar:///usr/local/bin/composer/bin/composer:43
require() at /usr/local/bin/composer:25

Thank you.

The error is happening to me in multiple environments. On a Linux server, on a vagrant machine and windows. This is the log

  - Installing drupal/google_map_field (dev-8.x-1.x 1823e1d)
    Cloning 1823e1d790a592d1258ae99c34beae5d6cda57de
Executing command (CWD): git clone --no-checkout 'https://git.drupal.org/project/google_map_field' 'web/modules/contrib/google_map_field' && cd 'web/modules/contrib/google_map_field' && git remote add composer 'https://git.drupal.org/project/google_map_field' && git fetch composer
Executing command (web/modules/contrib/google_map_field): git branch -r
Executing command (web/modules/contrib/google_map_field): git checkout '8.x-1.x' --
Executing command (web/modules/contrib/google_map_field): git checkout -B '8.x-1.x' 'composer/8.x-1.x' --
Executing command (web/modules/contrib/google_map_field): git reset --hard '1823e1d790a592d1258ae99c34beae5d6cda57de' --

    REASON: Required by root: Install command rule (install drupal/google_map_field dev-8.x-1.x)

  - Applying patches for drupal/google_map_field
Checking CA file /etc/ssl/certs/ca-certificates.crt
    https://www.drupal.org/files/issues/undefined_method_checkPlain-2629530-4.patch (node/2629530 - Call to undefined method checkPlain)
Downloading https://www.drupal.org/files/issues/undefined_method_checkPlain-2629530-4.patch
   Could not apply patch! Skipping.

I have a patch I want to apply to sites/default/default.settings.php (D8 project). Is there any way to currently do that?

Applying the patch against drupal/core won't work, because it is only the contents of the core directory. It is actually the drupal-project/drupal-scaffolding package that is responsible for updating the scaffolding files (basically anything from the standard Drupal distribution outside the core directory). (Patching against it also is not what's needed, because it actively downloads the scaffolding files; the package itself is just the code to figure out what to download).

When patching a dependency/module, then later you update the patch URL (to point to a newer patch) and run "composer update", it will try to apply the new patch to the cached previously patched download rather than applying it to a fresh download.

For example:

"patches": {
    "drupal/core": {
        "2655104 - List unmet dependencies instead of just failing":
        "https://www.drupal.org/files/issues/list-missing-dependencies-2655104-19.patch"
    }
},

then do "composer install". This works. Now edit the composer.json to be:

"patches": {
    "drupal/core": {
        "2655104 - List unmet dependencies instead of just failing":
        "https://www.drupal.org/files/issues/2655104-51.patch"
    }
},

then do "composer update". This will fail to apply the patch. From what I can tell, it is trying to apply the updated patch to the previously patched version that is in the composer cache, rather than re-downloading and applying from scratch.

If I do a "composer clear-cache" and THEN do a "composer update", then it works.

Edited: Using v1.5.0 of composer-patches

We following workflow does not work.

1. Install module composer require drupal/views
2. Add patch file for drupal/views to composer.json
3. Run composer install or composer update does not matter
4. Patch was not applied.

After patching a module, unless you remove the directory where the patched module is located, when you re-run Composer Update you will get a message about "the package has modified files" which you have to discard or the module will fail to download and be re-patched. Below is an example:

Gathering patches for root package.
Gathering patches for dependencies. This might take a minute.
  - Updating drupal/ajax_comments dev-8.x-1.x (44b6bf2 => 44b6bf2)
    The package has modified files:
    M ajax_comments.module
    M src/Utility.php
    Discard changes [y,n,v,d,s,?]? n
    Update failed (Update aborted)
    Would you like to try reinstalling the package instead [yes]? yes
  - Removing drupal/ajax_comments (dev-8.x-1.x)
    The package has modified files:
    M ajax_comments.module
    M src/Utility.php
    Discard changes [y,n,v,d,?]? y
  - Installing drupal/ajax_comments (dev-8.x-1.x 44b6bf2)
    Cloning 44b6bf2

  - Applying patches for drupal/ajax_comments

Tracking ticket for changes that should go into 2.0 that would be BC breaks.

• Default behavior should be to end execution if a patch cannot be applied (#31)
• Change patch format in composer.json to allow for other patch attributes (#24)

When a patch cannot be applied, the build simply continues with a warning being output. On automated systems, this is hard to catch. This is a critical issue, as these patches can be used to fix security problems, for instance. Instead, in case of failures, the process should exit with a non-zero error code.

This causes issues when drupal/drupal (version 7) is patched as everything resides in whatever location Drupal has been installed in.

As far as I know it is not possible to run Drupal itself as a dependency, so we would need something like https://github.com/winmillwill/drupal-tangler to resolve this issue. Do you have any other working solutions to this issue?

Steps to reproduce:

• Add a dependency to your root package which contains patches
• Add a new patch to that dependency
• Run composer update my/dependency in your root package

Expected:
New patch is applied

Actual:
New patch is not applied

After patching a module, unless you remove the directory where the patched module is located, there is a message about "the package has modified files" which you have to discard or the module will fail to download and be re-patched. Below is an example:

`Gathering patches for root package.
Gathering patches for dependencies. This might take a minute.

• Updating drupal/ajax_comments dev-8.x-1.x (44b6bf2 => 44b6bf2)
  The package has modified files:
  M ajax_comments.module
  M src/Utility.php
  Discard changes [y,n,v,d,s,?]? n
  Update failed (Update aborted)
  Would you like to try reinstalling the package instead [yes]? yes
• Removing drupal/ajax_comments (dev-8.x-1.x)
  The package has modified files:
  M ajax_comments.module
  M src/Utility.php
  Discard changes [y,n,v,d,?]? y
• Installing drupal/ajax_comments (dev-8.x-1.x 44b6bf2)
  Cloning 44b6bf2
• Applying patches for drupal/ajax_comments`

I don't want to require the "scripts" section in users' composer.json. I want it to work if a user only requires it.

I'm trying to install a couple of drupal modules, one of which I suspect has never been tested for installation with composer as it simply can't work in it's current state.

s3fs and s3fs_cors

Both of these require the aws s3 sdk, and as is implied, s3fs_cors depends on s3fs.

Anyway, the requirements in each is as follows:
s3fs:
"require": { "aws/aws-sdk-php": "^3.18" },

s3fs_cors
"require": { "aws/aws-sdk-php": "~3.3.8" },

Of course this leads to a long error list from composer like this:

• Can only install one of: aws/aws-sdk-php[3.3.8, 3.20.1].

Where those two requirements are conflicting

My proposal to get round this would be to patch the composer.json of s3fs to allow a newer version of the aws adk, so have a patch in place to do this which simply changes the requirement to ~3.18

The problem there of course is that the patch is not applied until the end (and I have tested it in isolation, the patch is applied), and it makes no difference.

How can I tell composer to run the patch first and then install the dependencies? Otherwise the only way to get this working would be to fork the package, but that would be last resort.

Output from composer install

> DrupalProject\composer\ScriptHandler::checkComposerVersion
Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Removing cweagans/composer-patches (1.0.0)
  - Installing cweagans/composer-patches (1.5.0)
    Loading from cache

  - Installing drupal/core (8.1.10)
    Loading from cache

Applying patch: Helper class for toolbar module (fetching from https://www.drupal.org/files/issues/drupal-toolbar_helper_class-2808647-2.patch)
fatal: bad config line 1 in file config
fatal: bad config line 1 in file config
patch: unrecognized option `--no-backup-if-mismatch'
usage: patch [-bCcEeflNnRstuv] [-B backup-prefix] [-D symbol] [-d directory]
             [-F max-fuzz] [-i patchfile] [-o out-file] [-p strip-count]
             [-r rej-name] [-V t | nil | never] [-x number] [-z backup-ext]
             [--posix] [origfile [patchfile]]
       patch <patchfile
patch: unrecognized option `--no-backup-if-mismatch'
usage: patch [-bCcEeflNnRstuv] [-B backup-prefix] [-D symbol] [-d directory]
             [-F max-fuzz] [-i patchfile] [-o out-file] [-p strip-count]
             [-r rej-name] [-V t | nil | never] [-x number] [-z backup-ext]
             [--posix] [origfile [patchfile]]
       patch <patchfile


  [Exception]
  Cannot apply patch https://www.drupal.org/files/issues/drupal-toolbar_helper_class-2808647-2.patch


install [--prefer-source] [--prefer-dist] [--dry-run] [--dev] [--no-dev] [--no-custom-installers] [--no-autoloader] [--no-scripts] [--no-progress] [--no-suggest] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--ignore-platform-reqs] [--] [<packages>]...

Is there any way to apply a patch the root of the project, not specifically targeting a package.
Currently I couldn't any documentation about this.
Is this supported in any form or way?

I tried to download a certain commit directly from http://cgit.drupalcode.org/. The patches plugin skips the URL with "Could not apply patch! Skipping."

The code in Patches::getAndApplyPatch can't handle the url. I used http://cgit.drupalcode.org/drupal/patch/?id=7393e427390570e770579fe9119e0d577b753578 for example

Hi there, first of I wanted to say thanks for the awesome repo!

Given the following composer.json file:

https://github.com/drupalwxt/drupal_wxt/blob/master/composer.json

When I run composer install everything gets installed correctly and in addition modules are correctly patched. In this composer.json file you will notice the line: "drupalwxt/wxt": "dev-8.x-2.x" this in turns calls this composer.json file:

https://github.com/drupalwxt/wxt/blob/8.x-2.x/composer.json

Given the above works I was curious why doing the following doesn't work and composer fails to see any patches.

In the same directory after everything is installed / scaffolded I then run:

composer require drupalwxt/wxt_search:dev-8.x-1.x

Which does download all of the correct modules but there is no patch applied.

https://github.com/drupalwxt/wxt_search/blob/8.x-1.x/composer.json#L40

I was wondering if there was something I was perhaps missing or misunderstanding :)

If I set up package A with a patch, and package B with the same patch, and set package A to require B, the URLs are merged into an array. This causes composer install to bail with an array to string conversion.

The last stable release was over 7 months ago, and there have been some pretty significant commits since then. There also haven't been any commits in over a month now, which indicates to me that the current build is probably relatively stable.

It would be nice to get a new tagged release, so that folks don't have to kill kittens by relying on an unpinned dev branch or commit ref of composer-patches.

The class Composer\Script\PackageEvent is deprecated and should be replaced with Composer\Installer\PackageEvent:

Deprecation Notice: The callback cweagans\Composer\Patches::postInstall declared at /.../cweagans/composer-patches/src/Patches.php accepts a Composer\Script\PackageEvent but post-package-install events use a Composer\Installer\PackageEvent instance. Please adjust your type hint accordingly, see https://getcomposer.org/doc/articles/scripts.md#event-classes in phar:///.../composer/src/Composer/EventDispatcher/EventDispatcher.php:308

This is a dependency of #16 if we move forward there, but it may be useful on its own.

I have a patch like the following:

            "drupal/core": {
                "Add option to disable settings.php hardening": "patches/drupal/1232572.43-sites-dir-hardening.patch"
            },

If that patches line is in an dependency, composer-patches looks for the file in the patches directory of the root package, instead of in the vendor directory of the package that adds the patch.

URL patches work around this nicely, but aren't great in scenarios where a patch is private or isn't accepted upstream.

If you ever need to patch a dependencies composer.json file it will act like this:

1. You run composer update
2. The dependencies are determined and downloaded.
3. The patches are applied

As you can see, if your patch changes a dependency, it won't be reflected in your vendor file. Therefore, as it stands, this method of patching appears to be ineffective for patching dependency composer files.

I do not understand how to patch ckeditor.
I did:
"patches": { "drupal/ckeditor": { "patches-file": "patches/ckeditor.patch" } }
but it does not work
(good job)

After patching a module, unless you remove the directory where the patched module is located, there is a message about "the package has modified files" which you have to discard or the module will fail to download and be re-patched. Below is an example:

`Gathering patches for root package.
Gathering patches for dependencies. This might take a minute.

• Updating drupal/ajax_comments dev-8.x-1.x (44b6bf2 => 44b6bf2)
  The package has modified files:
  M ajax_comments.module
  M src/Utility.php
  Discard changes [y,n,v,d,s,?]? n
  Update failed (Update aborted)
  Would you like to try reinstalling the package instead [yes]? yes
• Removing drupal/ajax_comments (dev-8.x-1.x)
  The package has modified files:
  M ajax_comments.module
  M src/Utility.php
  Discard changes [y,n,v,d,?]? y
• Installing drupal/ajax_comments (dev-8.x-1.x 44b6bf2)
  Cloning 44b6bf2
• Applying patches for drupal/ajax_comments`

Patch reports should let the developer know which (if any) patches failed to apply.

When installing Drupal 8 using the following command

composer create-project drupal-composer/drupal-project:8.x-dev d8 --stability dev --no-interaction 

I get this fatal error caused by composer-patches

PHP Fatal error:  Class 'Composer\Installer\PackageEvents' not found in /home/codio/workspace/d8/vendor/cweagans/composer-patches/src/Patches.php on line 67              

Fatal error: Class 'Composer\Installer\PackageEvents' not found in /home/codio/workspace/d8/vendor/cweagans/composer-patches/src/Patches.php on line 67   

Right now, all patches are downloaded unconditionally every time they're applied. We should download them once and store them in the Composer cache. If we store the SHA-1 of the patch in composer.lock, and then save the patch as $sha1OfPatch.patch in the cache dir, offline installs with patches are possible.

Obviously, this wouldn't need to happen for local patches - only ones where we'd normally download them.

I have added a patch to simplesamlphp/simplesamlphp package in my composer.json.

1. Store patch file in a patches dir in the root of my project: patches/Redirect_to_port_80_after_log_out-fix_incorrect_assumption_to_append_port.patch
2. Modify composer.json to implement the patch:

        "patches": {
          "simplesamlphp/simplesamlphp": {
            "Fixes 220-Redirect_to_port_80_after_log_out": "patches/220-Redirect_to_port_80_after_log_out-fix_incorrect_assumption_to_append_port.patch"
          }
        }

When I run composer install the patch applies successfully.

bevan@ubuntu:/var/www/doris$ composer install
Gathering patches for root package.
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Gathering patches for root package.
Gathering patches for dependencies. This might take a minute.
  - Installing simplesamlphp/simplesamlphp (v1.14.8)
    Loading from cache

  - Applying patches for simplesamlphp/simplesamlphp
    patches/220-Redirect_to_port_80_after_log_out-fix_incorrect_assumption_to_append_port.patch (Fixes 220-Redirect_to_port_80_after_log_out (https://trello.com/c/fnFHhxlp))

Generating autoload files
> DrupalProject\composer\ScriptHandler::buildScaffold
> DrupalProject\composer\ScriptHandler::createRequiredFiles

However when I run composer install with -vvv it failes with "fatal: can't open patch"

bevan@ubuntu:/var/www/doris$ composer install -vvv
...
Found 1 patches for simplesamlphp/simplesamlphp.
  - Installing simplesamlphp/simplesamlphp (v1.14.8)
Reading /home/bevan/.composer/cache/files/simplesamlphp/simplesamlphp/9a9b73a3c28c15015cf72b899bb3b6ec557d0f39.zip from cache
    Loading from cache
    Extracting archive
Executing command (CWD): unzip '/var/www/doris/vendor/simplesamlphp/simplesamlphp/467203b662269e344ef226b083c391a0' -d '/var/www/doris/vendor/composer/c6841079' && chmod -R u+w '/var/www/doris/vendor/composer/c6841079'

    REASON: Required by the root package: Install command rule (install simplesamlphp/simplesamlphp v1.14.8)

  - Applying patches for simplesamlphp/simplesamlphp
    patches/220-Redirect_to_port_80_after_log_out-fix_incorrect_assumption_to_append_port.patch (Fixes 220-Redirect_to_port_80_after_log_out (https://trello.com/c/fnFHhxlp))
cd '/var/www/doris/vendor/simplesamlphp/simplesamlphp' && GIT_DIR=. git apply --check '-p1' 'patches/220-Redirect_to_port_80_after_log_out-fix_incorrect_assumption_to_append_port.patch'
Executing command (CWD): cd '/var/www/doris/vendor/simplesamlphp/simplesamlphp' && GIT_DIR=. git apply --check '-p1' 'patches/220-Redirect_to_port_80_after_log_out-fix_incorrect_assumption_to_append_port.patch'
fatal: can't open patch 'patches/220-Redirect_to_port_80_after_log_out-fix_incorrect_assumption_to_append_port.patch': No such file or directory

So verbose output suggests that composer performs a Executing command (CWD): cd '/var/www/doris/vendor/simplesamlphp/simplesamlphp, although as the patch applies when not in verbose mode, I can speculate this CD command isn't performed when not verbose.

I have open the files that the patch modifies, and confirmed that the page does indeed apply, it's not a false positive.

In the same way that Composer includes a "require" command, so that you can run composer require cweagans/composer-patches instead of editing composer.json to insert the dependency, it would be really nice if composer-patches provided a way to patch packages from the command line.

I could see this either taking the form of a patch command, or an additional patch parameter to the require command (if Composer lets you modify built-in commands... not sure).