Doctrine\Common\ClassLoader is deprecated.

[freedelta]

Preconditions

1. This error is fired when launching tests in symfony: Doctrine\Common\ClassLoader is deprecated
2. The error comes with Doctrine Common v2.9.0
3. It seems that the ClassLoader in doctrine common is deprecated
   The future of Common 3.0 doctrine/common#826

Steps to reproduce

I think the error comes from the fact that you require doctrine/common in your composer.json

Expected result

Should not use doctrine/common

Actual result

In our logs: Doctrine\Common\ClassLoader is deprecated

[alexislefebvre]

Thanks for your report. Did you see this deprecation with the 1.x or 2.x version of this bundle?

[nataliastanko]

Thanks for your report. Did you see this deprecation with the 1.x or 2.x version of this bundle?

I can see it using doctrine/common 2.9.x-dev
I use liip/functional-test-bundle 2.0.0-alpha6

[alexislefebvre]

I removed the direct dependency in #440 and 3 of the dependencies of this bundle still require doctrine/common:

$ composer why doctrine/common
doctrine/data-fixtures  v1.3.1  requires  doctrine/common (~2.2)         
doctrine/orm            v2.6.2  requires  doctrine/common (^2.7.1)       
symfony/symfony         v4.1.1  requires  doctrine/common (~2.4@stable)  

So, we'll see the deprecation message until these 3 packages remove doctrine/common from their dependencies.

---

We can do the same thing as in symfony/symfony#27609 and require the necessary doctrine components and drop doctrine/common.

[alexislefebvre]

As noted here symfony/symfony#27609 (comment), the parameter weak_vendors can be used to ignore warnings from vendor/. I didn't tested it but it should hide Doctrine deprecations until all the packages are updated to remove this warning.

[Tobion]

This is not caused by LiipFunctionalTestBundle and should get fixed automatically when doctrine/orm 2.6.3 is released, see doctrine/orm#7307

[Tobion]

Reopening as the dependency on doctrine/common should be split like in symfony/symfony#27609

[Jean85]

I've did a quick check using Composer require checker. This is the result, grepping for common:

$ composer-require-checker check composer.json | grep -i "common"
| Doctrine\Common\DataFixtures\Loader                                               |                    |
| Doctrine\Common\DataFixtures\Purger\ORMPurger                                     |                    |
| Doctrine\Common\DataFixtures\Executor\ORMExecutor                                 |                    |
| Doctrine\Common\DataFixtures\Executor\AbstractExecutor                            |                    |
| Doctrine\Common\DataFixtures\ProxyReferenceRepository                             |                    |
| Doctrine\Common\DataFixtures\Purger\PHPCRPurger                                   |                    |
| Doctrine\Common\DataFixtures\Purger\MongoDBPurger                                 |                    |
| Doctrine\Common\DataFixtures\Executor\MongoDBExecutor                             |                    |
| Doctrine\Common\Annotations\Reader                                                |                    |
| Doctrine\Common\EventManager                                                      |                    |
| Doctrine\Common\Persistence\ObjectManager                                         |                    |

It seems to me that any used symbol is due to fixture-related stuff (DataFixtures, Persistence). Only two exceptions are:

• Annotations\Reader: this is used in the query counter:

  LiipFunctionalTestBundle/src/QueryCounter.php

  Lines 60 to 66 in ee1b91e

  	private function getMaxQueryAnnotation(): ?int
  	{
  	foreach (debug_backtrace() as $step) {
  	if ('test' === substr($step['function'], 0, 4)) { //TODO: handle tests with the @test annotation
  	$annotations = $this->annotationReader->getMethodAnnotations(
  	new \ReflectionMethod($step['class'], $step['function'])
  	);

• Common\EventManager: this is used in the ConnectionFactory, so it gives the DoctrineBundle already for granted:

  LiipFunctionalTestBundle/src/Factory/ConnectionFactory.php

  Line 36 in ee1b91e

  public function createConnection(array $params, Configuration $config = null, EventManager $eventManager = null, array $mappingTypes = [])

The problematic thing is the fact that common is still required indirectly by our require-dev, so it's pretty hard to test against it at all:

$ composer why -t doctrine/common
doctrine/common v2.9.0 Common Library for Doctrine projects
├──doctrine/data-fixtures v1.3.1 (requires doctrine/common ~2.2)
│  ├──doctrine/doctrine-fixtures-bundle 3.0.2 (requires doctrine/data-fixtures ~1.0)
│  │  └──liip/functional-test-bundle 2.x-dev (requires (for development) doctrine/doctrine-fixtures-bundle ^3.0.2)
│  └──liip/functional-test-bundle 2.x-dev (requires (for development) doctrine/data-fixtures ^1.3)
├──doctrine/orm v2.6.2 (requires doctrine/common ^2.7.1)
│  └──liip/functional-test-bundle 2.x-dev (requires (for development) doctrine/orm ^2.6)
└──symfony/symfony v4.1.7 (requires doctrine/common ~2.4)
   └──liip/functional-test-bundle 2.x-dev (requires (for development) symfony/symfony ^3.4 || ^4.1)

How should we proceed?

IMHO maybe we could promote PHPUnit to a non-dev dependency (it surely is, since we extend the base test case), add a group to all tests that work around fixtures and exclude them in a single job.

[Jean85]

I did a small tryout of running tests without additional dev dependencies and that's really ugly.. The fixtures requires all the bundles, everything is an implicit / optional dependency... Argh!

[alexislefebvre]

On one hand, we could add a test suite and ensure that some tests work without Doctrine. For example, for projets which use other database bundle like
Pomm https://github.com/pomm-project/pomm-bundle and want to use the helpers for requests or logging users.

On the other hand, I'm pretty sure that almost all the projects that use this bundle use Doctrine for communicating with their database and so we may assume that Doctrine is installed.

(sorry I misclicked and closed this issue)