• bug fix? no

• new feature? yes

• BC break? maybe?

• The ignoring fourliner makes easier to ignore a whole package with assets in root (see this SO QA)

• The output prefixes makes distinction of the origin output clearer

• bug fix? yes
• new feature? no
• BC break? no

The README.MD example for ignoring whole package doesn't work. true does nothing; [""] works as suggested here: https://forum.nette.org/cs/29055-mpdf-problem-so-spustenim#p189907

• bug report? maybe

The config key is intended to be used by Composer itself, Composer plugins should use the key extra. Using config key does not currently AFAIK cause any issues, but may cause problems in the future.

See https://getcomposer.org/schema.json:

• the config key is described as „Composer options.“
• the extra key is described as „Arbitrary extra data that can be used by plugins, for example, package of type composer-plugin may have a 'class' key defining an installer class name.“

You can then simply run php vendor/bin/composer-cleaner --test which can then be run as part of a standard deploy procedure. Namespaced as DGComposer to avoid confusion and affiliation with Composer itself.

A second set of eyes and some testing would be great here. Thanks.

• bug fix? yes
• new feature? no
• BC break? no

Composer\Util\Filesystem::remove() now expects string as $file parameter:

In Filesystem.php line 41:
                                                                                                                                                                                                                                 
  [TypeError]                                                                                                                                                                                                                    
  Argument 1 passed to Composer\Util\Filesystem::remove() must be of the type string, object given, called in .../vendor/dg/composer-cleaner/src/ComposerCleaner/Cleaner.php on line 101  

BC changes in Composer 2.3.0 release: https://github.com/composer/composer/commit/6da38f83a0d5acc71793f337b525fa2faff9468e#diff-0257f81fd9bc0572b4399acf6ddae947814cd2340a970838a8649b24caa97530R259 https://github.com/composer/composer/commit/6a466a120a404d1c5d492e5ca715841c491517fc#diff-720233bf29e23e314f9436edd8d3d084b4b63e681eeb4267ec5ac9ac93ff6d4eR1

• bug fix? yes
• new feature? no
• BC break? no

When I try to use this plugin within my CI/CD I get the following error:

Fatal error: Uncaught TypeError: FilesystemIterator::__construct() expects parameter 1 to be a valid path, object given in /tmp/builds/devowlio/devowl-wp/plugins/real-media-library/vendor/dg/composer-cleaner/src/ComposerCleaner/Cleaner.php:53
Stack trace:
#0 /tmp/builds/devowlio/devowl-wp/plugins/real-media-library/vendor/dg/composer-cleaner/src/ComposerCleaner/Cleaner.php(53): FilesystemIterator->__construct(Object(SplFileInfo))
#1 /tmp/builds/devowlio/devowl-wp/plugins/real-media-library/vendor/dg/composer-cleaner/src/ComposerCleaner/Plugin.php(40): DG\ComposerCleaner\Cleaner->clean('/tmp/builds/dev...', Array)
#2 [internal function]: DG\ComposerCleaner\Plugin->clean(Object(Composer\Script\Event))
#3 phar:///usr/local/bin/composer/src/Composer/EventDispatcher/EventDispatcher.php(164): call_user_func(Array, Object(Composer\Script\Event))
#4 phar:///usr/local/bin/composer/src/Composer/EventDispatcher/EventDispatcher.php(96): Composer\EventDispatcher\EventDispatcher->doDispatch(Object(Composer\Script\Event))
#5 phar:///usr in /tmp/builds/devowlio/devowl-wp/plugins/real-media-library/vendor/dg/composer-cleaner/src/ComposerCleaner/Cleaner.php on line 53

This happens because FilesystemIterator::__construct expects a string as $path parameter.

Solution:

Use strval to cast SplFileInfo to an absolute path string.

Environment:

$ composer --version
Composer version 1.10.7 2020-06-03 10:03:56
$ php -v
PHP 7.3.18 (cli) (built: May 15 2020 13:51:16) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.18, Copyright (c) 1998-2018 Zend Technologies

No tests added

• bug report? yes
• feature request? no

Description

Not quite sure what is happening. I asked at StackOverflow and it was answered. I don't think this is a feature. https://stackoverflow.com/questions/46195321/composer-removing-random-files-from-package-after-installation/46212934#46212934

Steps To Reproduce

composer require dg/composer-cleaner composer require mpdf/mpdf

The problem is, that all sources are in folder Net, and Victor romoves all them :-(

PACKAGE vendor/pear/net_dns2 deleting .svn deleting LICENSE deleting Net deleting package.php deleting package.xml deleting tests

https://code.google.com/p/netdns2/source/browse/#svn%2Ftrunk%2FNet

• bug report? yes
• feature request? no

Description

Cleaner deletes psr-0 source files

Steps To Reproduce

composer require ircmaxell/random-lib // should give you ^1.2 composer require dg/composer-cleaner // should give you ^0.4

The source files for random-lib will be deleted.

Allow users to preview what would be done by entering a test mode.

Test mode is disabled by default, but can be enabled adding flag -t or --test as the first executable's argument. It can be also enabled by setting the first argument of Cleaner::__construct( boolean ) to true.

Implementation summary:

• add $testMode parameter to the Cleaner::__construct( boolean ) signature
• force -t | --test to be the first argument of executable, but keep BC

I get hundreds of this error on Windows because I don't have attrib in PATH.

'attrib' is not recognized as an internal or external command,
operable program or batch file.

• bug report? no
• feature request? yes

Description

After having installed this package on my project and successfully passed tests. I end up catching (fortunately) an issue with a business important package stripe-php during e2e testing. The cleaner removes a folder called "data" which contains a "ca-certificates.crt" used by the library when actually calling the Stripe API ! The exception thrown end up notifying a Network Error that is uneasy to debug.

This could have been launched to production with a less rigorous testing and impact website badly.

Maybe we could put at least a feature that detects sensitive packages that needs to be ignored by default. And notifying user during install.

Steps To Reproduce

• require stripe/stripe-php
• require dg/composer-cleaner
• Set up Stripe and attempt a createCustomer call for example

• bug fix? no
• new feature? yes

Cleaner currently supports $ignoreMasks only for files & directories from root of package directory. This PR improves matchMask method and adds support for more complex masks. See Cleaner.clean.phpt for example.

Features:

• possibility to ignore only specific items in subdirectories
• possibility to delete items from ignored directories (directories from autoload key in composer.json, etc.)

(Methods collectPaths & matchMask are taken from ftp-deployment, collectPaths is little modified)

PR partially solves issue #13.

• bug report? no
• feature request? yes

Description

I suggest reversing the "mode of operation" of this package, so that it only cleans packages that are included not packages that are excluded. This issue takes the idea a step further than #13.

The current mode of operation can be turned on so that it is obvious by looking at the composer.json that there is indeed a cleaner doing stuff. But the default should be not-cleaning-anything!

Steps To Reproduce

1. install this package into a project
2. wait about 1 year and forget about it
3. install another package with assets and other stuff outside of src directory into the project
4. wonder:
   • why the assets are removed before they get copied intu public dir
   • where is that bower.json that should be there
   • why are there no other files besides src dir and composer.json
   • where is the readme of that other package that would be helpful now
5. bang your head into a wall
6. composer remove dg/composer-cleaner

Sorry, I'm no expert on everything. First i thought it was a feature of composer itself. There was no trace of it. No google results, nothing. Then I searched my composer.json for a configuration that would suggest something why the files are being removed. I noticed they are actually being removed. First I thought they are not even downloaded. In the end I discovered this package. I had not known that it was possible to have a package register a cleaning procedure. Sorry for that. But I believe there are others who might be misfortunate enough to install this package and forget that it's sitting there eating away all the assets, package-management scripts, readmes and all.

• bug report? no
• feature request? yes

Description

new "cleaner-remove" config, opposite of "cleaner-ignore"

Steps To Reproduce

Thoughts on having the converse of "cleaner-ignore"? E.g., a path of files to remove. This could be a path (file or folder) in a library that you always want to clean.

• bug report? no
• feature request? yes

I don't know if this can actually be solved but I think it's worth looking into. Currently if cleaner removed too much stuff, you modify cleaner-ignore. Calling composer update / composer update however does not restore the deleted files.

It would be nice if composer-cleaner could detect that cleaner-ignore was changed and force Composer to reinstall the library.