Як припинити хибні тривоги через попередження про застарілість

Коли PHPStan позначає метод як застарілий (deprecated), ви зазвичай шукаєте йому заміну. Але що, якщо її немає?

Shopware використовувала тег @deprecated для анонсування запланованих змін — наприклад, додавання нового необов'язкового параметра. Інструменти статичного аналізу сприймали ці теги як реальне застарівання і скаржилися на кожен виклик. Шум зростав, розробники почали ігнорувати попередження, і сповіщення втратили свою цінність. Це класичний випадок «крику про вовка».

У Shopware 6.7.14.0 ми розділили ці сигнали.

  • @deprecated — зарезервуйте це для API, які зникнуть або будуть замінені. Ви обов'язково повинні мігрувати свій код.
  • Атрибути BC-change — використовуйте їх для запланованих правок, які зберігають API живим, наприклад, для нових необов'язкових параметрів або змінених типів повернення.

Нові атрибути знаходяться в Shopware\Core\Framework\Deprecation\BCChange. Вони точно вказують, що саме зміниться і на що це вплине.

Ми розділили їх на дві групи:

  • CallSiteCompatibilityChange — впливає на код, який викликає метод.
  • ExtenderCompatibilityChange — впливає на класи, які розширюють або перевизначають метод.

Тепер ви можете підготувати своє розширення до Shopware 6.8 ще до виходу наступного мажорного релізу.

Приклад: метод отримає новий необов'язковий параметр. Додайте цей параметр у свої перевизначення вже сьогодні; код працюватиме як на поточній, так і на майбутніх версіях.

Ця зміна відновлює довіру до попереджень про застарілість.

Три кроки для розробників

  1. Ставтеся до @deprecated як до обов'язкового виправлення; API зникне.
  2. Відмовтеся від широких шаблонів ігнорування, які можуть приховувати реальні проблеми.
  3. Слідкуйте за атрибутами BC-change і впроваджуйте невеликі безпечні оновлення зараз, замість того щоб робити масивну міграцію пізніше.

Джерело: https://dev.to/shopware/when-deprecated-cries-wolf-making-shopwares-next-major-upgrades-easier-983