Evitando que las advertencias de depreciación den falsas alarmas
Cuando PHPStan marca un método como depreciado, normalmente buscas un reemplazo. ¿Pero qué pasa si no existe ninguno?
Shopware utilizaba la etiqueta @deprecated para anunciar cambios planificados, como la adición de un nuevo parámetro opcional. Las herramientas de análisis estático trataban esas etiquetas como depreciaciones reales y se quejaban de cada llamada. El ruido aumentó, los desarrolladores empezaron a ignorar las advertencias y las alertas perdieron su valor. Es el clásico caso de "gritar lobo".
En Shopware 6.7.14.0 hemos dividido las señales.
@deprecated– reserva esto para las APIs que desaparecerán o serán reemplazadas. Debes migrar tu código.- Atributos de cambio de BC (BC-change attributes) – úsalos para ajustes planificados que mantienen la API activa, como nuevos parámetros opcionales o tipos de retorno alterados.
Los nuevos atributos se encuentran en Shopware\Core\Framework\Deprecation\BCChange. Te indican exactamente qué cambiará y a quién afecta.
Los hemos dividido en dos grupos:
- CallSiteCompatibilityChange – afecta al código que llama a un método.
- ExtenderCompatibilityChange – afecta a las clases que extienden o sobrescriben un método.
Ahora puedes preparar tu extensión para Shopware 6.8 antes de que llegue la próxima versión principal.
Ejemplo: un método ganará un nuevo parámetro opcional. Añade ese parámetro a tus sobrescrituras hoy mismo; el código funcionará tanto en la versión actual como en las futuras.
Este cambio restaura la confianza en las advertencias de depreciación.
Tres pasos para desarrolladores
- Trata
@deprecatedcomo una corrección obligatoria; la API desaparecerá. - Elimina los patrones de ignorado genéricos que puedan ocultar problemas reales.
- Mantente atento a los atributos de cambio de BC y aplica actualizaciones pequeñas y seguras ahora, en lugar de una migración masiva más adelante.
Fuente: https://dev.to/shopware/when-deprecated-cries-wolf-making-shopwares-next-major-upgrades-easier-983