Eric L. Barnes presentó Laravel Vet el 15 de septiembre de 2026. El paquete beta del equipo de Laravel muestra los archivos que una instalación o actualización escribiría en vendor/ y guarda los estados aprobados en vet.json. El plugin de Composer actúa después de las instalaciones y detiene una actualización antes de escribir archivos nuevos. Su modelo sigue la idea de cargo vet en el ecosistema Rust. Los paquetes aprobados quedan registrados y solo vuelven a revisión cuando cambian.

composer require laravel/vet --dev
./vendor/bin/vet --init
composer update
./vendor/bin/vet

Vet puede enviar el diff de cada paquete a un agente de programación instalado en el equipo local. Entre los agentes compatibles están Claude Code, Codex, Gemini y opencode. El agente devuelve PASS, FAIL, WARN o SKIP. PASS indica que la revisión terminó sin señalar un ataque. FAIL identifica un archivo y explica el problema. WARN marca una revisión incompleta, por ejemplo cuando un archivo es demasiado grande, contiene datos no textuales o no recibió respuesta. SKIP indica que Vet no envió archivos porque no había cambios o porque no pudo leer los archivos del paquete. Un paquete no confiable produce un código de salida distinto de cero y puede detener un build. La herramienta funciona en cualquier proyecto con composer.json, incluidos Laravel, Symfony, WordPress y PHP sin framework.

Vet requiere PHP 8.4 o posterior y se instala como dependencia de desarrollo. La inicialización marca como confiables los paquetes que ya están en vendor/ y los registra en vet.json. En el ejemplo del artículo, el archivo contiene 125 paquetes. Este paso registra los archivos existentes en el disco sin auditarlos. Las actualizaciones posteriores se comparan con esa base.

En un ejemplo, carbonphp/carbon-doctrine-types pasa de 3.1.0 a 3.2.0 con dos archivos modificados. En src/Carbon/Doctrine/DateTimeImmutableType.php, el tipo de retorno cambia de DateTimeImmutable a CarbonImmutable. En src/Carbon/Doctrine/DateTimeType.php, cambia de DateTime a Carbon. Vet detiene la escritura de los archivos nuevos. ./vendor/bin/vet -v muestra los cambios para una revisión manual y ./vendor/bin/vet inicia la revisión con un agente.

En otra ejecución, Claude revisa tres paquetes con 58.1 KB de cambios. La actualización de acme/logger, de 1.2.0 a 2.0.0, modifica 12 archivos. El agente devuelve FAIL porque src/Ship.php lee .env y envía su contenido a telemetry.example.com. La actualización de acme/tooling, de 4.1.0 a 4.2.0, cambia ocho archivos. Recibe WARN porque añade dos comandos y el agente no leyó resources/schema.php, un archivo de 612.4 KB. Para carbonphp/carbon-doctrine-types, el resultado es PASS después de revisar dos archivos y encontrar tipos de retorno más precisos.

Vet selecciona por defecto los paquetes con resultado PASS. El desarrollador puede ajustar la selección después de revisar los informes y pulsar Enter para guardar las decisiones. Los resultados del agente no modifican vet.json por sí solos. Vet guarda el archivo junto a composer.json, y el artículo recomienda confirmarlo en el repositorio. Una entrada usa el esquema 4 e incluye una versión del paquete y un hash. El ejemplo contiene la versión 3.2.1 y el hash tree-v2:0f158f3b909fc01e691ed5f5121186056232b049031e7d3a914676d49881ece5. El hash cubre todos los archivos del paquete. Por eso, cualquier cambio en un archivo exige otra revisión aunque el número de versión no cambie. El build falla hasta que todos los paquetes quedan aprobados.

El artículo sitúa Vet en el contexto de varios incidentes recientes de la cadena de suministro. Menciona el bloqueo de malware y las políticas de dependencias de Composer 2.10, además de un paquete npm de Axios que distribuyó un troyano de acceso remoto. Vet sigue en beta y su comportamiento puede cambiar antes de la primera versión estable. También se menciona Heimdall, que aplica una política de antigüedad mínima a las dependencias de Composer. La documentación completa está en el repositorio de GitHub laravel/vet.