Please follow the PSR-2 coding standards which are used by Composer.

and your new feature should be tested.

Btw, you are breaking tests here as by default, you are excluding everything

you still need to add tests for the blacklist feature

Hey @stof, hey @hosiplan,

@JohnDoe007 was so friendly to fix the CS and unit test issues. Thanks @JohnDoe007! (just fyi, he`s a team mate of me and we worked together on this feature).

Why we need this feature?
We use Composer to handle out dependencies with it.
We generate our autoloading map with -o (optimizing mode).
During this mode all available classes will be mapped into one big array for faster autoloading lookup,
In this array, some classes for unit tests are included.
In a big environments this could be a possible problem or a way to further optimizations.
This feature is a kind of optimization. It tries to exclude all UnitTest-Files with the introduction of an "exclude"-Folder.
@JohnDoe007 provided a small example how to use this feature in his own composer.json.
The named patterns will be executed during the autoload map creation.

Here you can find a minimal example how to reproduce this: https://gist.github.com/andygrunwald/4994295

I got a small chat with @Seldaek about this "feature" over twitter: https://twitter.com/andygrunwald/status/304163183541772288

If you got further notices / changes about this feature, let us know.
What do you think about this?

I think this is counterproductive. There should be no tests in autoloader. The question is - how did they get there in the first place? I think excluding them, by not including them, is better approach.

But hey, if it won't broke any existing library... it's ok I guess.

@hosiplan As you can see in the discussion from twitter with me and @Seldaek there is a regular expression to exclude all files which ends with Test.php (see https://github.com/composer/composer/blob/master/src/Composer/Autoload/AutoloadGenerator.php#L126)

This regular expression is not very "aggressiv" and in a Tests/-Folder there ar emuch more files as *Test.php
See example https://gist.github.com/andygrunwald/4994295 to reproduce :)

@hosiplan the test is not in the autoloader. In it in the autoloader generator (which is generating the autoloader configuration when you run composer install or composer dump-autoload)

@hosiplan is correct that you should not configure any autoload for the test files in your package definition, however in some cases like symfony bundles and others, tests are within the psr-0 mapped folder. In this case the ability to exclude them from generated classmaps would be a good thing.

Hello!
I guess I fixed all your issues regarding optimization of the blacklist pattern and the coding styleguide (psr-2) breaks and added a test for the exclude function.
In our case (symfony 2 app with in most cases sf2 related libraries added) we can save more then the half size of the classmap file (2500 entries instead of about 5300 by excluding tests-folders, sample-folders, etc).

@Parad0X probably this could be interesting for you

hmmm... any idea why there is no new travis build?

Isn't it better to have both a whitelist and blacklist approach? Although the blacklist would at least solve issues we have with eZ Publish 5.

@patrickallaert if you say the blacklist solves your problem then it can't be a bad solution. I think using blacklist and whitelist together could be really confusing?
and which is the use case where a blacklist and whitelist is necessary?

Don't get me wrong @JohnDoe007, I +1 this PR. Just that I see a use case for whitelisting: if you just want to cherry-pick some files or directories, it is just easier to select those rather than excluding everything else.

@patrickallaert if you just want a few files/directories, you can do it with "classmap":" ["file.php", "dir/"] already. And if you need to whitelist some things inside a blacklisted dir, I'd suggest you seriously need to rework your project structure :)

@JohnDoe007 @Seldaek The need is indeed just to include some files/directories, so this is already implement. I was not aware of that since I'm not the guy touching that part of eZ Publish.
For sure, whitelisting inside blacklisting is just evil.

So +1.

I prefer integration of Finder component from symfony (#1406):

"classmap": ["src/*Bundle/", "src(/[^/]+(?<!test|Tests|foo/bar))*"]

and/or add support for complex configuration (http://symfony.com/doc/current/components/finder.html):

"classmap": ["src", {"in": ["vendor"], "depth": "2", "not-path": "..."}, {"in": ["lib"], "name": "*.cls"}]

Please rename it to a more descriptive name, eg. exclude-from-classmap. Current naming leads to confusion:

"autoload": {
    "psr-0": {"Acme": "src"},
    "exclude": ["Tests"]
}

$autoloader->findFile('Acme\Tests\FooTest'); // returns /.../src/Acme/Tests/FooTest.php

@hason I agree about the exclude name, it is not the clearest. Maybe classmap-exclude? Otherwise exclude-from-classmap is fairly clear too.

IMO it's easier to do this blacklist of explicit pathes than to integrate finder stuff because not everyone is familiar with it and not everyone can write lookahead regexes without shooting themselves in the foot :)

@rk3rn3r reviewed again and I wrote down one issue, apart from that it should also be rebased again if possible. But I think then it's good to merge. Sorry for the delay, many things to review.

Come on @rk3rn3r , go go go.

What happened with this feature?

@klapifoch nothing yet. We (@trivago / @rk3rn3r / me) are now responsible.
We will try to take care of this feature, rebase it against the current master and push the new version.

Just give us a few more days to solve this. Ok?
Thanks and you will get new information soon :)

Hey @stof, @Seldaek,
can you review it again? @msiebeneicher has updated this PR against the current master.
It would be cool if we can (finally) merge this feature. If you need anything else, please let us know.

The state was tested against the unit tests and the test case https://gist.github.com/andygrunwald/4994295 by @andygrunwald with the following composer-json:

{
  "require": {
    "doctrine/doctrine-bundle": "v1.0.0"
  },
  "autoload": {
    "exclude-from-classmap": ["/Tests/"]
  }
}

Result:

• 790 classes in classmap with current composer version
• 738 classes in classmap after this change

Not merged yet?

@andygrunwald @rk3rn3r Another thing that's missing for an easy merge is including it in the doc/04-schema.md in the autoload docs.

Unrelated: @klapifoch can you be more of an obnoxious and ungrateful person please?

@Seldaek If have updated the doc/04-schema.md and integrate a desciption.

I checked the whitelist handling again and i'm not sure if the logic make also sense for the blacklist handling:

With the "exclude-from-blacklist" you are free to define pattern to avoid classes in the classmap. If we extend the "user pattern" with the directories (and namespaces for psr-0), like the whitelist functionality, it's possbile to produce wrong or invalid patterns (if somebody use "^ - Start of string or line" for example).

It's looks like some of the unit tests failed because of temporary connections problems to "pear.phpmd.org"!?

@Seldaek It wasn't my intention to be annoying, it is just a feature i want to use in a project.
Sorry.

@Seldaek: We reintegrated the current master again to our fork.

Any update here?

I guess 2.5y is a pretty long time, sorry about that, but we got there :) Finally took the time to merge this and try it out, tweaked things a bit because it was matching stuff a bit too greedily for my taste. Now you have to specify exact paths from package root to things you want to exclude, I see that it's not always the easiest think it's better that way rather than accidentally matching too much. We can always add support for wildcards or such later on if really needed. Thanks @rk3rn3r

So I added support for wildcards after all, see 6c16510

So when exluding test files from the autoload optimization, it means test classes might not be available anymore. So it is similar to using exclusion via gitattributes. But IMO using gitattributes is the better approach as this will actually also make the package considerably smaller. And developers still have a choice with --prefer-dist vs --prefer-source.
See symfony/symfony#16397 (comment)