On Deprecation#L129 it assumes vendor dir is always /vendor [1]. As per composer config [2] that behaviour can be changed. In a project i'm working on it happen to be this way:

    "config": {
        "vendor-dir": "libraries"
    },

Any chance that path can be fetched from config or specified on Deprecation::enableWithTriggerError();?

[1]
`

[2] https://getcomposer.org/doc/06-config.md#vendor-dir

I'm suddenly having an issue with my CI builder failing with a runtime exception

The .git directory is missing from /builds/path/to/project/vendor/doctrine/deprecations, see https://getcomposer.org/commit-deps for more information

I've not seen this before, and I noticed that a release was just published, so I'm wondering if there could be a connection.

Instead of just the file and line where the backtrace was triggered it should also show the calling location to allow finding where a deprecation was triggered from.

A more clever solution that finds the first use in a different composer package is probably even better, but out of scope for now.

Please add it

This is the oppositte of expectDeprecationWithIdentifier that VerifyDeprecations trait already has.

The last version tag 0.5.3 is 1 commit behind adding the LICENSE. It would be great if we get at least a 0.5.4 that includes the LICENSE without rushing for the other commits.

We have the following issue on DoctrineBundle CI:

1) Doctrine\Bundle\DoctrineBundle\Tests\DependencyInjection\Compiler\IdGeneratorPassTest::testRepositoryServiceWiring
Undefined array key "file"

/home/runner/work/DoctrineBundle/DoctrineBundle/vendor/doctrine/deprecations/lib/Doctrine/Deprecations/Deprecation.php:189
/home/runner/work/DoctrineBundle/DoctrineBundle/vendor/doctrine/deprecations/lib/Doctrine/Deprecations/Deprecation.php:99
/home/runner/work/DoctrineBundle/DoctrineBundle/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/Driver/AttributeDriver.php:83
/home/runner/work/DoctrineBundle/DoctrineBundle/vendor/symfony/dependency-injection/ContainerBuilder.php:1109
/home/runner/work/DoctrineBundle/DoctrineBundle/vendor/symfony/dependency-injection/ContainerBuilder.php:1234
/home/runner/work/DoctrineBundle/DoctrineBundle/vendor/symfony/dependency-injection/ContainerBuilder.php:1180
/home/runner/work/DoctrineBundle/DoctrineBundle/vendor/symfony/dependency-injection/ContainerBuilder.php:1657
/home/runner/work/DoctrineBundle/DoctrineBundle/vendor/symfony/dependency-injection/ContainerBuilder.php:1134
/home/runner/work/DoctrineBundle/DoctrineBundle/vendor/symfony/dependency-injection/ContainerBuilder.php:1234
/home/runner/work/DoctrineBundle/DoctrineBundle/vendor/symfony/dependency-injection/ContainerBuilder.php:1180
/home/runner/work/DoctrineBundle/DoctrineBundle/vendor/symfony/dependency-injection/ContainerBuilder.php:1078
/home/runner/work/DoctrineBundle/DoctrineBundle/vendor/symfony/dependency-injection/ContainerBuilder.php:1234
/home/runner/work/DoctrineBundle/DoctrineBundle/vendor/symfony/dependency-injection/ContainerBuilder.php:1180
/home/runner/work/DoctrineBundle/DoctrineBundle/vendor/symfony/dependency-injection/ContainerBuilder.php:1657
/home/runner/work/DoctrineBundle/DoctrineBundle/vendor/symfony/dependency-injection/ContainerBuilder.php:1134
/home/runner/work/DoctrineBundle/DoctrineBundle/vendor/symfony/dependency-injection/ContainerBuilder.php:1234
/home/runner/work/DoctrineBundle/DoctrineBundle/vendor/symfony/dependency-injection/ContainerBuilder.php:1180
/home/runner/work/DoctrineBundle/DoctrineBundle/vendor/symfony/dependency-injection/ContainerBuilder.php:1078
/home/runner/work/DoctrineBundle/DoctrineBundle/vendor/symfony/dependency-injection/ContainerBuilder.php:608
/home/runner/work/DoctrineBundle/DoctrineBundle/vendor/symfony/dependency-injection/ContainerBuilder.php:553
/home/runner/work/DoctrineBundle/DoctrineBundle/Tests/DependencyInjection/Compiler/IdGeneratorPassTest.php:121

I get the same error locally and $backtrace[1] only contains:

array(3) {
  ["function"]=>
  string(11) "__construct"
  ["class"]=>
  string(43) "Doctrine\ORM\Mapping\Driver\AttributeDriver"
  ["type"]=>
  string(2) "->"
}

Sometimes you have your own APIs triggering deprecations, because there is no other way using the new functionality yet.

Example in DBAL: We deprecated Driver\Statement::setFetchMode but it is still required to call it from Connection::prepare.

So we would like to avoid triggering the deprecation notice by ignoring the deprecation temporarily for 1 time.

In reaction to a comment from @morozov on a PR adding deprecations to the DBAL 1, here are my thoughts on unfixable deprecations.

Definition

An unfixable deprecation is a deprecation that the user cannot fix without running composer update, and might not necessarily be able to fix by running it.

Why

Unfixable deprecations are arguably noise they cannot act on without a contribution upstream, a release, and a composer update. One might want to mute them, but it can be argued that it can also be an incentive to contribute, or useful information to know what blockers prevent you to upgrade to the next major of some package, regardless of whether you can fix that in your application or not.

What

Let's think of ways we could improve this package by letting users mute deprecations based on their type.

History

We have encountered the issue of having too many unfixable deprecations with @alcaeus on doctrine/persistence while using @trigger_error + Symfony 2 .

Also, following a question asked after a talk on deprecations by Nicolas Grekas , where somebody asked if it would be possible for the phpunit bridge to separate fixable from unfixable deprecations, I contributed to that package and implemented a separation in three types:

• self deprecation: when a package calls its own deprecated API
• direct deprecations: when the root package calls the deprecated API of another package
• indirect deprecations: when the root packages calls n packages which in turn call the deprecated API of a package

As you can see 3, I was forced to add a fourth type for cases when it's unclear what the situation is.

Implementation

Using Composer's getPrefixes() and getPrefixesPsr4() API, one can determine where vendor packages reside, where the sources of the root package reside, and what package each file in a stack trace belongs to. 4
From that, it's most of the time possible to determine a type for each deprecation, and make decisions on how to handle them based on configuration: mute them, fail the build if a type reaches a given threshold, displaying them separately, etc.

Edge cases

Here are some special situations that made that a complex development:

• a deprecation is triggered from STDIN
• a deprecation is triggered from a phar
• a deprecation is triggered by a library loading a configuration file written by the end user, and that file uses deprecated configuration nodes

Vocabulary

It's easy to get confused if you lack the words to express your ideas, and the vocabulary in this RFC can of course be challenged, everyone is encouraged to find alternate wording. Here is a list of names that could be challenged:

• fixable, direct, self
• unfixable, indirect
• root package, application, project

Hi, i updated symfony from 5.2.4 to 5.2.6 and i got this error when trying to save an entity

Here is the log file:

[2021-04-02T21:48:32.877991+00:00] php.CRITICAL: Uncaught Error: Class 'Doctrine\Deprecations\Deprecation' not found {"exception":"[object] (Error(code: 0): Class 'Doctrine\Deprecations\Deprecation' not found at /var/www/html/iVisit/vendor/doctrine/dbal/lib/Doctrine/DBAL/Statement.php:253)"} []
[2021-04-02T21:48:32.932222+00:00] request.CRITICAL: Uncaught PHP Exception Symfony\Component\ErrorHandler\Error\ClassNotFoundError: "Attempted to load class "Deprecation" from namespace "Doctrine\Deprecations". Did you forget a "use" statement for another namespace?" at /var/www/html/iVisit/vendor/doctrine/dbal/lib/Doctrine/DBAL/Statement.php line 253 {"exception":"[object] (Symfony\Component\ErrorHandler\Error\ClassNotFoundError(code: 0): Attempted to load class "Deprecation" from namespace "Doctrine\Deprecations".
Did you forget a "use" statement for another namespace? at /var/www/html/iVisit/vendor/doctrine/dbal/lib/Doctrine/DBAL/Statement.php:253)"} []

We could add a second way for deduplication based on identifier + stacktrace. The stacktrace can be hashed using fingerprinting rules from error tracking tools such as sentry.

Idea, user calls:

Deprecation::includeStacktracesInDeduplication(true);

Then a deprecation is triggered once for every unique stacktrace it was triggered from.

In dev vs prod there are different requirements to overhead of logging, as such it could make sense to make the backtrace length stored with a deprecation configurable. Currently only the last frame is stored.

The VerifyDeprecations trait exists to add assertions about deprecations which is a deprecation-producer task. For deprecation consumers we still need to check how to integrate with PHPUnit.

Instead of complicated in file approaches, we could provide a deprecation class loader that just checks and triggers deprecations and then delegates autoloading further to Composer.

This could hook into Composer as a plugin and generate a map of deprecated classes from all installed packages, and then in your code you would only prepend the autoloader:

if ($isDevMode) {
    spl_autoload_register(['DeprecationLoader', 'loadClass'], true, true);
}

We pass the package name, so we can use that for testing for vendor/{$packageName} in the caller. If that matches, the deprecation should be suppressed.

This would avoid having to first ignore then trigger a deprecation, which might look weird.

This will replace and remove #18 (proposed in #16)

When running PHPUnit and collecting deprecations for existing code there you would want to disable deduplication. Deduplication should be the default configuration, because that is what is better for production.

Both tools should be at their maximum level, with a baseline. Let's work our way up, fixing obvious issues, until we give up and baseline the rest.