por Abrimos un proyecto PHP y el editor colorea el código, pero no encuentra una clase de vendor, no sabe qué versión de PHP utilizamos o no se detiene en un punto de interrupción. En ese momento importa bastante poco que la herramienta tenga miles de extensiones si las tres cosas que necesitamos no están configuradas.
Para elegir un editor o IDE en Linux conviene mirar cómo vamos a trabajar con el proyecto. Una aplicación pequeña, una base de código con Symfony y un repositorio que sólo se ejecuta dentro de un contenedor no plantean las mismas necesidades.
Vamos a comparar opciones y, después, a comprobar lo que debería funcionar en cualquiera de ellas antes de dar por preparado el entorno.
PhpStorm: cuando queremos las herramientas integradas
PhpStorm reúne navegación de código, refactorización, Composer, pruebas y depuración en una misma aplicación. Tiene sentido cuando dedicamos buena parte del día a PHP y preferimos configurar esas piezas desde el propio IDE en lugar de buscar una extensión para cada tarea.
Eso no significa que baste con abrir la carpeta. Debemos seleccionar el intérprete del proyecto y comprobar que coincide con el que realmente lo ejecuta. Si el código corre en un contenedor, utilizar por comodidad un PHP local de otra versión puede ocultar errores o señalar problemas que no existen en ese entorno.
Para un intérprete local, abrimos los ajustes de PHP y seleccionamos el ejecutable correspondiente. La documentación de PhpStorm muestra dónde consultar la versión detectada y el archivo de configuración. La integración de PHPUnit permite utilizar el framework instalado en el proyecto, con su configuración, en lugar de una copia global sin relación con él.
PhpStorm es propietario. Antes de elegirlo revisamos las condiciones de licencia aplicables a nuestro uso en su web oficial. No es una alternativa libre por funcionar en Linux, y una licencia gratuita para un caso concreto tampoco cambia ese hecho.
VS Code: elegir también las extensiones
Si utilizamos varios lenguajes y queremos mantener el mismo editor, VS Code es otra opción. Su soporte básico de PHP no equivale a instalar un IDE especializado completo. Podemos ampliar el análisis de código, la navegación y la depuración con extensiones, pero hay que revisar cuáles necesitamos y quién las mantiene.
En particular, el corrector de sintaxis de PHP necesita encontrar un ejecutable. La configuración oficial de PHP en VS Code permite indicar su ruta:
{
"php.validate.executablePath": "/usr/bin/php"
}
Esa ruta es un ejemplo. Si el intérprete está en otro lugar, ponemos el ejecutable real. Configurar aquí el linter no configura automáticamente el intérprete que utilizará una extensión de pruebas o una sesión de depuración.
También conviene distinguir Code – OSS, la distribución de Microsoft y cada extensión. No comparten necesariamente licencia ni condiciones de uso. Si queremos priorizar software libre, revisamos el conjunto, no sólo el nombre del editor. En la guía de instalación de VS Code en Linux está explicada esa diferencia.
NetBeans y Eclipse PDT como alternativas libres
Apache NetBeans y Eclipse PDT siguen siendo opciones a considerar cuando queremos un IDE libre. No hace falta descartarlos por no utilizar el editor más comentado, pero tampoco elegirlos sólo por una lista de características.
Con NetBeans comprobamos que la distribución o los componentes instalados incluyen soporte PHP. Abrimos un proyecto representativo y revisamos si reconoce sus dependencias, permite navegar por las clases y encaja con su configuración de pruebas.
Eclipse PDT añade las herramientas de PHP a Eclipse. Es especialmente razonable si ya trabajamos dentro de ese entorno. Su página de proyecto documenta navegación, validación, depuración con Xdebug y soporte para PHPUnit. La instalación debe incluir PDT, no sólo una descarga de Eclipse pensada para otro lenguaje.
NetBeans se publica bajo Apache 2.0 y PDT bajo la licencia de Eclipse correspondiente al proyecto. Aun así, las extensiones que añadamos pueden tener sus propias condiciones. En ambos casos revisamos también la versión de Java que exige la distribución descargada, sin copiar requisitos de un tutorial antiguo.
Comprobar PHP antes de culpar al editor
Desde una terminal del proyecto ejecutamos:
php -v
php --ini
composer --version
Así vemos qué PHP y qué configuración utiliza esa terminal, y si Composer está disponible. Si el comando no existe o indica otra versión, el problema no se resuelve cambiando el tema del editor.
En un proyecto descargado de un repositorio de confianza, leemos primero su documentación. Si ya incluye composer.lock, el comando habitual para recuperar sus dependencias es:
composer install
No lo sustituimos por composer update para intentar que aparezca vendor. El segundo puede cambiar las versiones resueltas y modificar el archivo de bloqueo. La documentación de Composer explica esa diferencia.
Tampoco ejecutamos Composer con sudo como solución general a un error de permisos. Y recordamos que un proyecto puede definir scripts o plugins ejecutables durante la instalación, por lo que no es un comando inocuo sobre cualquier carpeta descargada.
Con las dependencias disponibles, abrimos la raíz del proyecto, donde están composer.json y la configuración de las pruebas. Abrir únicamente src puede dejar fuera información que el analizador necesita.
Una prueba pequeña que nos dice más que el autocompletado
Para comprobar la ejecución básica podemos guardar un archivo ejemplo.php:
<?php
declare(strict_types=1);
function precioConIva(float $base, float $porcentaje): float
{
return round($base * (1 + $porcentaje / 100), 2);
}
$total = precioConIva(100.0, 21.0);
printf("Total: %.2f\n", $total);
Después comprobamos sintaxis y ejecución:
php -l ejemplo.php
php ejemplo.php
La salida de este ejemplo es Total: 121.00. Podemos utilizarlo para poner un punto de interrupción en el cálculo y ver el valor de $base y $porcentaje. Es un ejercicio de configuración, no una función preparada para resolver todos los requisitos monetarios de una aplicación real.
Para las pruebas del repositorio utilizamos su propio comando. Si usa PHPUnit instalado mediante Composer, normalmente encontraremos el ejecutable en vendor/bin/phpunit. Antes de configurarlo en el IDE comprobamos que funciona desde la terminal con el intérprete correcto y la configuración del proyecto.
Si Xdebug no se detiene
Primero comprobamos que la extensión está cargada en el PHP que estamos ejecutando:
php --ri xdebug
Si dice que no está presente, instalar una extensión del editor no basta. Xdebug tiene que existir también en el intérprete. Cuando está instalado, su guía de depuración paso a paso explica la activación del modo de depuración y el inicio de una sesión.
Es Xdebug quien inicia la conexión hacia el cliente de depuración del IDE. Si todo está en el mismo ordenador suele ser más sencillo que cuando PHP está en otro equipo o contenedor. En ese segundo caso revisamos la dirección del cliente y la correspondencia entre las rutas del código, sin abrir puertos públicos como arreglo rápido.
Si funciona por terminal pero no desde el navegador, comprobamos también la configuración de PHP-FPM o Apache. No tienen por qué cargar el mismo php.ini que la línea de comandos.
Con cuál me quedaría según el proyecto
Para un proyecto PHP grande, con refactorizaciones frecuentes y depuración, empezaría comparando PhpStorm con una alternativa libre sobre el propio repositorio. Si ya utilizamos VS Code para varias tecnologías, comprobaría primero si una selección pequeña de extensiones cubre el trabajo sin conflictos.
NetBeans o Eclipse PDT tienen sentido si buscamos un IDE libre y su integración nos resulta cómoda. La elección no debería obligarnos a cambiar los comandos que ejecuta el resto del equipo ni a instalar dependencias diferentes sólo para que el editor muestre menos avisos.
Antes de decidir, haría cuatro comprobaciones: abrir una clase de una dependencia, ejecutar una prueba, detener un ejemplo con el depurador y cambiar un nombre viendo qué archivos toca. Si esas tareas funcionan bien con nuestro proyecto, tenemos una base mucho más útil que cualquier clasificación de «los mejores».
