The Php Times

Los RFCs de deprecación para PHP 8.6 han sido aprobados. Aunque ningún código se rompe en la nueva versión, las funciones obsoletas generan advertencias fácilmente pasadas por alto—especialmente cuando los paquetes externos las desencadenan en rutas de código frecuentemente ejecutadas.

En proyectos con logging en nivel Notice (común en configuraciones Laravel), cada llamada deprecada inunda los logs, aumentando el consumo de disco y los costos de ingesta. Los equipos a menudo diagnostican esto como un problema de infraestructura en lugar de modernización, retrasando la solución real.

El punto central de fricción son los paquetes externos. El código propio se actualiza rápidamente, y herramientas como Rector automatizan gran parte del trabajo. Las dependencias externas sin versiones PHP-8.6-ready continúan emitiendo advertencias hasta que el mantenedor publique una corrección—un cronograma fuera del control directo.

Un enfoque práctico: habilitar E_DEPRECATED como error en CI antes del despliegue. Esto detecta deprecaciones durante las pruebas, no después de llegar a producción. Una implementación mínima convierte advertencias a excepciones:

error_reporting(E_ALL); set_error_handler(function ($errno, $errstr, $errfile, $errline) { if ($errno === E_DEPRECATED || $errno === E_USER_DEPRECATED) { throw new \ErrorException($errstr, 0, $errno, $errfile, $errline); } return false; });

Esto convierte las advertencias de deprecación en errores de prueba estrictos, previniendo que saturen silenciosamente los logs de producción. El debate comunitario sigue abierto: implementar compuertas CI estrictas para deprecaciones, o tolerar el ruido hasta que haya recursos para la corrección.