Programemos Cosas

  Al ejecutar el CLI composer run dev, lo primero que aparece es Xdebug: [Step Debug] Could not connect to debugging client. Tried: localhost:9003 (through xdebug.client_host/xdebug.client_port). Acto seguido empiezan a correr todos los procesos invocados por Composer, pero después el mismo mensaje de Xdebug aparece periódicamente sin límite. Ese mensaje de Xdebug indica que está intentando iniciar una sesión de depuración pero no encuentra ningún cliente escuchando en el puerto 9003. Aunque no impide que Composer funcione, puede generar ruido constante en la consola. Para solucionarlo, podés desactivar el modo de depuración o configurar correctamente tu cliente (como VS Code o PhpStorm). 🔧 ¿Por qué aparece este mensaje? Xdebug está configurado para iniciar una sesión de step debugging cada vez que se ejecuta PHP. Intenta conectarse a un cliente de depuración (como VS Code o PhpStorm) en localhost:9003 , pero no encuentra ninguno escuchando. Esto suele pasar cuando: No tenés abie...

 La historia corta: Probar con un número de versión específico en composer require paquete versión, para acotar el rango de paquetes y así acortar la salida del log. Cuando a Composer no le especificás un número de versión como en composer require paquete (omitiendo el número de versión), Composer primero va a intentar con la versión más reciente, y cada vez que falle la instalación por un conflicto de requisitos, Composer va a intentar una versión anterior. Este proceso termina o con una versión que se pueda instalar o con una colección de errores, uno por cada versión que falló al instalar. La diferencia entre especificar una versión y no hacerlo es que en el primer caso si falla, la salida del log muestra el error correspondiente a la única versión que intentó instalar, en cambio, en el segundo caso si fallan todos los intentos, la salida del log contiene la colección completa de errores, algo muy difícil de leer. Conclusión: lo mejor es probar con una combinación de ambas forma...

Composer, el gestor de dependencias de PHP, nos ofrece la opción de instalar paquetes globalmente, para que puedan ser ejecutados como cualquier comando de shell, por ejemplo, ls, date, grep. composer global require paquete En Ubuntu 20, Composer instala estos paquetes en ~/.config/composer/vendor/bin. Entonces, solo es cuestión de crear un enlace simbólico:  ln -s ~/.config/composer/vendor/bin/laravel ~/.local/bin/ . Si ejecutas  ls -la .local/bin/  deberías ver un enlace simbólico para el comando laravel. Opción dos: el problema con el primer enfoque es que necesitas crear un enlace simbólico para cada paquete global que instales. Así que, ¿por qué no olvidarnos de este rollo de  ~/bin  y  ~/.local/bin  y agregar la carpeta  bin  de Composer directamente a  $PATH ? Probablemente ya te diste cuenta, pero solo agrega esto a  ~/.profile ,  ~/.bashrc  o  ~/.bash_profile : if [ -d "/home/your-user/.config/composer/vendor...

¿Por qué un proyecto Laravel creado con composer create-project laravel/laravel depende del paquete ably-php pero no se descarga dicho paquete? Esta pregunta apunta a una característica importante de cómo Composer maneja las dependencias: el concepto de suggest (sugerir) en composer.json . Cuando creas un proyecto Laravel con composer create-project laravel/laravel , el paquete principal que se instala es laravel/framework , junto con algunas otras dependencias esenciales. La razón por la que podrías ver que ably-php "depende" (o aparece mencionado) pero no se descarga es la siguiente: No es una dependencia require directa ni transitiva obligatoria: ably-php (el cliente PHP para el servicio de mensajería en tiempo real Ably) no es una dependencia obligatoria para que Laravel funcione. Tu aplicación Laravel no lo necesita para arrancar ni para realizar tareas básicas como routing, ORM, etc. Es una dependencia suggest (sugerida): El paquete laravel/framework (que es el ...