Better discoverability for packs

[pounard]

Today, we have packs, and there is, in my opinion, and hard to maintain piece of code that looks up in the vendor directory for all packages that are packs.

I can see many problems with this:

• The lookup algorithm parses composer files and do a lot of filesystem lookup, we can improve that by reading the Composer\InstalledVersions class generated in the vendor/composer/ directory, many projects seem to use it, and it is based upon a cache: it's faster, and its API is clean: it will easier to maintain.
• When we search for classes with the anonymizer classes, we use get_declared_classes(), that's OK in small projects, terrible in big projects.
• Because we use the type entry in composer.json file, other types of packages simply cannot provide anonymizers, or it's up to the user to add all its anonymizer_paths in its configuration.

What I propose:

• First, fix the actual algorithm by using Composer\InstalledVersions.
• Keep it for backward compatiblity (although there is no known pack to be released yet).
• Add a new discovery method, by looking up in {"extra": {"db-tools-bundle:" [class1, class2, ..]}} composer option instead: this way third parties will be able to both provide a package that does something and add anonymizers at the same time.
• Use this new extra option and document it for projects as well (we could register all anonymizers in the main project composer.json file as well) - I don't see the benefits yet, but if parsing it for vendors is possible, then it's also possible for the root project as well.
• Use Composer\InstalledVersions to get list of packages, instead of parsing the file system, this will speed up the lookup. We can also create an ignore list and exclude known vendor names or package names that do not and will never provide any packs for us.
• Provide a static anonymizer registry, with static methods to populate it, pretty much like doctrine/dbal does for database datatypes. Packs could then ship with an autloaded file that simply register their implementations.
• In the Symfony use case, stop parsing the src/ folder, skipping get_declared_classes() completely, and use a compiler pass that find all anonymizers as services instead.

Some random notes:

• I'm not very fond of the extra in composer.json yet, because it forces us to keep parsing json files, but I don't have any better way right now. We can still use Composer\InstalledVersions to get a list of installed package and provide an ignore list (for example symfony/*, drupal/*, phpunit/*) to speed-up the process and read less files.
• The get_declared_classes() algorithm will be required when we'll ship it as a PHAR archive, simply allowing the user to create some directory somewhere with raw PHP files we'll load in order to have all its anonymizers directly available (with the PHAR file, we don't have Composer\InstalledVersions loaded at all). Yet, keeping it solely for this use case and avoiding using it for all others seems like a good idea in my opinion.

I'm going to open a PR for this right now.

[pounard]

Lots of ideas for not that much to do in the end.

Planned fixes:

• avoid unnecessary file system scans by:
  • blacklisting some composer vendors (eg. symfony/*, phpunit/*, ...)
  • using InstalledVersions instead of a file system lookup in vendor/
• hardcode core list of anonymizers in the registry
• few code style fixes and additional defensive programming like checks
• fix unit tests

It's hard to get rid of \get_declared_classes() but we can, at least, condition it to the existence of packs. It will be later very useful if we release a phar archive, the user can then simply drop its custom anonymizers in a random path and will not even need an autoloader.