DevMan para Visual Studio Code

Elige las versiones de desarrollo de cada proyecto y abre su terminal sin salir de VS Code.

Ejecutar y configurar sin carpeta

Instala, registra y activa runtimes globales desde el panel DevMan aunque no tengas una carpeta abierta. Usa Configuración para cambiar las ubicaciones de runtimes y paquetes.

Pulsa Ejecutar archivo con DevMan en un archivo Java, Python, Node, PHP, Ruby, Go, JAR, DLL o proyecto .NET. El asistente Ejecutar archivo, proyecto o script… también admite npm, Maven, Gradle y ejecuciones guardadas. La terminal muestra la salida en vivo; puedes detener la tarea. Preparar Uvicorn o Puma en el proyecto instala las dependencias explícitamente dentro del entorno del proyecto. Consulta la guía de ejecución.

Requisitos

• Visual Studio Code 1.96 o posterior, versión de escritorio.

• Instala el VSIX 0.5.0 correspondiente al sistema y arquitectura del host: Windows, Linux o macOS, x64 o ARM64.

• Una carpeta de trabajo de confianza. En SSH, WSL o contenedores, instala la extensión correspondiente al host remoto.

El VSIX incluye DevMan CLI 1.9.0 y su motor .NET autocontenido. No necesitas instalar DevMan Desktop, una CLI separada ni .NET. Al activarse verifica SHA-256 y prepara el motor en el almacenamiento privado del usuario de VS Code. Esta preparación funciona sin conexión ni elevación de permisos. Los runtimes que quieras descargar sí necesitan conexión y conservan sus propios requisitos.

El motor se actualiza con la extensión; no se modifica una CLI instalada por separado. Comparte el inventario y la configuración de ~/.devman con DevMan Desktop. Los runtimes y paquetes conservan las ubicaciones elegidas en DevMan. El motor privado está bajo globalStorage/gbvaldez.devman/cli del host de VS Code. Las versiones anteriores permanecen allí para no reemplazar ejecutables abiertos.

Instalar

1. Abre Extensiones en VS Code (Ctrl+Shift+X).

2. En el menú …, elige Instalar desde VSIX… y selecciona tu paquete, por ejemplo devman-0.11.0-win32-x64.vsix.

3. Abre el panel DevMan de la barra lateral.

4. El motor se prepara automáticamente. Si falla, abre Salida → DevMan y ejecuta DevMan: Actualizar para reintentar. Opcionalmente puedes elegir una CLI 1.9.0 o posterior mediante DevMan: Seleccionar ejecutable de DevMan.

También puedes usar code --install-extension devman-0.11.0-win32-x64.vsix. Después de actualizar, recarga la ventana y abre terminales nuevas.

Agregar un runtime que ya tienes

Ejecuta DevMan: Agregar runtime existente, elige Java, Python, Node.js, .NET, Go, Maven, Gradle, PHP o Ruby, selecciona su carpeta y escribe un alias único, por ejemplo oracle-21, python-empresa o dotnet-trabajo.

La instalación aparece como Externo. Puedes usarla en un proyecto (se guarda el alias en .devman.json) o activarla globalmente para tu usuario. Al quitar su registro, sus archivos se conservan. Registrar no activa globalmente ni cambia las variables del usuario; activar globalmente sí actualiza los accesos y variables correspondientes.

Se valida que existan los ejecutables necesarios; en Unix también sus permisos de ejecución. No se ejecuta el binario durante el registro ni se comprueba automáticamente su versión real, arquitectura o licencia. El alias es un identificador, no una versión detectada. Java requiere un JDK con java y javac; en macOS acepta el paquete .jdk o Contents/Home. Python puede usar una instalación o un entorno virtual con python/python3; PyPy sin esos ejecutables no es compatible automáticamente. Para .NET selecciona la carpeta que contiene dotnet, no una subcarpeta sdk/<versión>: si contiene varios SDK, global.json y las reglas de .NET siguen determinando el SDK elegido. Usa la raíz real del runtime en lugar de una carpeta general de accesos como /usr/bin.

Los alias admiten de 1 a 80 letras ASCII, números, puntos, +, guiones y guiones bajos; se rechazan nombres reservados y duplicados dentro del mismo runtime. El alias debe registrarse en cada equipo donde uses ese proyecto. Si mueves o eliminas la carpeta original, tendrás que volver a registrarla.

Un Python diferente para cada proyecto

1. Abre la carpeta del proyecto.

2. En DevMan → Proyectos, elige Elegir versión para el proyecto.

3. Selecciona Python y una versión instalada. Si hace falta, elige Instalar otra versión….

4. DevMan guarda la versión en .devman.json.

5. Abre una terminal nueva con + o tu atajo habitual y comprueba python --version.

Ejemplo del archivo generado:

{

  "schemaVersion": 2,

  "managed": {

    "python": "3.14.7",

    "node": "24"

  }

}

Cada terminal recibe el entorno de su proyecto. Si cambias .devman.json, abre una terminal nueva. exit cierra esa terminal. Entrar a otra carpeta con cd dentro de una terminal ya abierta no vuelve a seleccionar runtimes.

Terminales nuevas con el entorno del proyecto

Al detectar versiones en .devman.json, DevMan configura DevMan: Proyecto como perfil predeterminado del espacio de trabajo. Las terminales nuevas abiertas con +, Terminal → Nueva terminal o el atajo correspondiente usan las versiones del proyecto. No necesitas pulsar el botón de DevMan cada vez.

En Windows este perfil abre CMD mediante devman shell, con AutoRun desactivado para conservar la prioridad de los runtimes. En Linux y macOS usa la shell que selecciona DevMan CLI. Las terminales ya abiertas conservan su entorno: mostrar una terminal existente con un atajo no la actualiza.

Con varias carpetas, se usa el proyecto del editor activo; cuando no se puede determinar, aparece un selector. El cambio se guarda en terminal.integrated.defaultProfile.windows, .linux o .osx del espacio de trabajo, sin modificar la configuración global del usuario.

Para desactivarlo, ejecuta DevMan: Restaurar el perfil de terminal anterior o desmarca devman.autoProjectTerminal. DevMan guarda el perfil anterior para restaurarlo. Si eliges manualmente otro perfil predeterminado, respeta esa elección; puedes reactivarlo con DevMan: Usar DevMan en las terminales nuevas.

Funciones

| Acción | Dónde encontrarla |

| --- | --- |

| Ver los nueve runtimes e instalaciones | Panel Runtimes instalados |

| Consultar el catálogo e instalar | Icono de descarga de un runtime |

| Elegir una versión para un proyecto | Panel Proyectos o clic en una versión instalada |

| Abrir la configuración y autocompletar JSON | Icono de configuración del proyecto |

| Abrir una terminal con el entorno del proyecto | +, atajo de nueva terminal, icono de DevMan o perfil DevMan: Proyecto |

| Activar una versión global | Menú contextual de una versión instalada; solicita confirmación |

| Desinstalar una versión | Menú contextual; muestra la ruta y proyectos abiertos afectados |

| Ejecutar scripts de .devman.json | Scripts del panel Proyectos, como tareas de VS Code |

| Diagnosticar y ver rutas de paquetes | Menú del panel de runtimes o paleta de comandos |

| Consultar fallos | Salida → DevMan, botón Mostrar detalle y Abrir logs de DevMan |

Con varias carpetas abiertas, las acciones solicitan el proyecto correspondiente o usan la carpeta del elemento seleccionado. La barra de estado muestra la carpeta del editor activo y sus versiones declaradas.

Scripts

{

  "schemaVersion": 2,

  "managed": { "python": "3.14.7" },

  "scripts": {

    "test": { "command": "python", "args": ["-m", "unittest"] }

  }

}

Pulsa test en el panel del proyecto. Se ejecuta devman run test en una tarea con salida propia. Los scripts solo se ejecutan cuando los solicitas.

Configuración y compatibilidad

devman.executablePath permite indicar opcionalmente una ruta absoluta a una CLI 1.9.0 o posterior. Es una configuración del usuario/equipo; un repositorio no puede reemplazar el ejecutable mediante .vscode/settings.json. Si está vacía, usa el motor incluido en el VSIX. En Windows reconoce el lanzador estándar devman.cmd y usa directamente el .exe al que apunta. Una ruta explícita inválida produce un error; no se reemplaza silenciosamente.

Los procesos se ejecutan con argumentos separados, sin construir comandos de shell. Las rutas con espacios se conservan. La extensión se desactiva en espacios de trabajo no confiables y en sistemas de archivos virtuales; no es una extensión web para vscode.dev.

El código de la extensión admite Windows, Linux y macOS. La descarga y los requisitos de cada runtime dependen de DevMan y del host: PHP y Ruby siguen siendo experimentales; Ruby en Unix puede necesitar herramientas de compilación. La extensión conserva el comportamiento de devman shell de la plataforma. Las extensiones de depuración o lenguaje, como Python o Java, mantienen su propia selección de intérprete/SDK; esta extensión configura las terminales y ejecuciones de DevMan.

La instalación de un runtime se realiza en segundo plano y muestra su progreso en Salida → DevMan. Espera a que termine antes de cerrar VS Code. Los comandos de consulta tienen tiempo de espera; una instalación puede tardar más y no tiene un límite fijo.

Desarrollar y probar

El código de la extensión usa JavaScript sin dependencias npm de producción. Empaquetar la edición autónoma requiere .NET 10, Python, Node.js y PowerShell 7. Primero restaura la solución con dotnet restore DevMan.sln --locked-mode desde la raíz. El script genera seis VSIX con CLI autocontenida y manifiesto SHA-256; se firma el apphost de macOS cuando se empaqueta en macOS. La edición para Linux usa glibc; Alpine/musl no está incluido.

npm test

npm run check

pwsh ../../scripts/build-vscode.ps1

Para probar en una instancia de desarrollo:

code --extensionDevelopmentPath=/ruta/DevMan/extensions/vscode /ruta/proyecto

test/extension-host.js comprueba activación, comandos, árboles, CLI real y una terminal integrada que escribe la versión de Python. Requiere un perfil/carpeta de pruebas aislados, DEVMAN_TEST_CLI y un Python ya instalado (DEVMAN_TEST_PYTHON, por defecto 3.14.7). Se ejecuta con --extensionTestsPath=/ruta/DevMan/extensions/vscode/test/extension-host.js. El test modifica únicamente la configuración del perfil y proyecto de pruebas. Los tests de procesos y el host de VS Code necesitan un entorno que permita crear procesos y sus canales IPC.

Referencias de implementación

• API de árboles de VS Code

• API de terminales y tareas

• Confianza del espacio de trabajo

• Empaquetado e instalación de VSIX

Configuración de almacenamiento

Abre DevMan: Configuración: runtimes, paquetes y cachés desde la paleta de comandos, o pulsa el engranaje en la cabecera de Runtimes.

• Elige la carpeta base para nuevas instalaciones, descargas y caché del catálogo.

• Activa o desactiva las ubicaciones administradas de paquetes; elige una base común y excepciones para NuGet, npm, pip, Maven, Gradle, RubyGems/Bundler, Composer y Go.

• Usa Examinar…, Comprobar permisos y Guardar sin editar JSON ni ejecutar comandos.

• Puedes restaurar los valores predeterminados de paquetes o copiar las cachés de la configuración anterior. La copia admite cancelación y conserva los originales.

• Los errores aparecen en el panel con Mostrar detalle del error, y también en Salida → DevMan.

Esta configuración pertenece al usuario del host donde se ejecuta la extensión y se comparte con Desktop y CLI. En SSH/WSL se refiere al host remoto. No se guarda en .vscode/settings.json ni en .devman.json.

Las instalaciones existentes conservan su ubicación. Guardar una sección no borra cambios pendientes de la otra. Abre terminales nuevas después de guardar paquetes y reinicia Desktop después de cambiar la carpeta de runtimes. Comprobar permisos puede crear carpetas vacías. npm conserva node_modules y Composer conserva vendor en el proyecto; pip cambia únicamente su caché.

Extensiones de lenguajes y depuradores

devman.syncEditors está activado por defecto. Usa la versión local del runtime y, si no está fijada, la versión global activa. DevMan: Sincronizar runtimes con las extensiones permite revisar/aplicar la selección. Se conservan los ajustes manuales y las selecciones virtuales de Python. Consulta Salida → DevMan para ver conflictos y límites; guardar una versión no fuerza reemplazos de configuraciones ajenas.

| Integración | Comportamiento |

|---|---|

| Python | API pública para seleccionar el intérprete por carpeta. Una selección existente se conserva en la sincronización automática; la selección explícita desde DevMan puede adoptar el Python base. Los entornos virtuales existentes se conservan. |

| Java | Registra el JDK del proyecto en java.configuration.runtimes e indica el JDK para importar Gradle. Conserva el JRE interno del servidor Java y las reglas de pom.xml/toolchains. |

| Node.js | Proporciona ejecutable y entorno al depurador cuando launch.json no define runtimeExecutable/runtimeVersion. No modifica configuraciones attach. |

| Go | Configura go.alternateTools y las variables de sus herramientas si no hay ajustes manuales. Una selección privada del SDK en la extensión Go puede tener prioridad. |

| PHP | Configura las rutas de validación/depuración cuando la extensión instalada ofrece esas opciones; Xdebug sigue siendo necesario. |

| Maven/Gradle | Configura la ruta de Maven, JAVA_HOME, el repositorio y las opciones de importación de Gradle. Conserva los wrappers y scripts del proyecto. |

| C# | Configura el entorno del servidor C# y de depuración coreclr. Conserva global.json y el runtime interno del servidor. C# Dev Kit puede requerir reiniciar todas las ventanas de VS Code desde una terminal DevMan para detectar el SDK; no garantiza el cambio de SDK de un servidor ya iniciado. Para distintos SDK por carpeta, usa ventanas separadas. |

| Ruby LSP | Ofrece el Ruby global como fallback si no existe configuración manual. La selección del gestor de versiones o la selección privada de Ruby LSP conserva prioridad. Ruby LSP no expone un ajuste público por carpeta equivalente al de Python; la sincronización de Ruby local requiere su selector o iniciar VS Code desde ese entorno. |

Al desactivar devman.syncEditors, se restauran los valores que DevMan cambió si aún conservan el valor aplicado. No se borran cambios posteriores del usuario. Las rutas absolutas añadidas a la configuración de VS Code corresponden al host actual; revisa esos archivos antes de compartirlos entre equipos.

Dependencias por proyecto

En el árbol de proyectos, pulsa Dependencias del proyecto, o ejecuta DevMan: Configurar dependencias del proyecto. Puedes elegir ubicaciones habituales, paquetes locales o paquetes y cachés locales. La opción se guarda en .devman.json:

"packageStorage": { "mode": "project", "includeCaches": true }

• npm conserva node_modules y Composer conserva vendor; no redirige instalaciones explícitamente globales de esas herramientas.

• NuGet usa .devman/packages/nuget/packages; para proyectos .NET detectados se añade NuGet.Config conservando fuentes y rechazando rutas manuales incompatibles. Variables o propiedades explícitas de MSBuild/NuGet pueden tener prioridad.

• Maven, Gradle, Go y Ruby guardan dependencias bajo .devman/packages. Maven y Gradle no separan completamente repositorio/dependencias de otras cachés.

• Python utiliza .venv. Si no existe, DevMan lo crea con el Python seleccionado al preparar el entorno; requiere venv y ensurepip. Un .venv existente no se reconstruye ni cambia de versión automáticamente. Un fallo de creación se marca y se informa para evitar reutilizar un entorno incompleto.

• Se agregan .devman/packages y .venv al .gitignore. Los cambios se aplican a nuevos procesos DevMan; vuelve a ejecutar restore/install. No se trasladan ni eliminan paquetes al cambiar de modo.

CLI, desde la raíz del proyecto:

devman config project-packages project

devman config project-packages project --shared-caches

devman config project-packages shared

devman config environment

config environment resuelve runtimes y variables en JSON; puede preparar .venv cuando el proyecto tiene paquetes locales. Desktop ofrece los mismos modos en Proyectos, seleccionando una fila y guardando la ubicación de dependencias.

Servidores y aplicaciones (0.6)

En la sección Servidores y aplicaciones, instala versiones de Tomcat/WildFly o registra una carpeta externa. Crea instancias por proyecto eligiendo versión, JDK y puerto. El menú de cada instancia permite iniciar, detener, reiniciar, abrir el navegador, consultar logs y agregar WAR/EAR con el servidor detenido.

El tipo command ejecuta aplicaciones de los runtimes seleccionados en DevMan (por ejemplo Node, Uvicorn, .NET o PHP). Las dependencias deben estar instaladas y el comando debe permanecer en primer plano. Los procesos se inician solo cuando lo solicitas, bajo tu usuario. Requiere el motor 1.4 incluido o un CLI externo 1.4 o posterior. Consulta configuración, ejemplos y límites.

Las instancias de servidores pueden administrarse sin abrir una carpeta en VS Code: el comando solicita la carpeta de la aplicación y la muestra en la vista de servidores durante la sesión. La configuración se guarda allí en .devman.json.

Compilar y desplegar aplicaciones

En Servidores y Aplicaciones, abre el menú de una instancia Tomcat/WildFly y selecciona Compilar / desplegar aplicación. Funciona con instancias globales incluso sin una carpeta abierta en VS Code.

• Maven: selecciona la carpeta con pom.xml. Ejecuta mvn clean package con los runtimes de DevMan del proyecto, o los globales si no hay selección local.
• Gradle: selecciona la carpeta con build.gradle o build.gradle.kts. Ejecuta gradle clean assemble.
• HTML: selecciona únicamente la carpeta pública con index.html (por ejemplo dist). DevMan genera el WAR; no incluye archivos ocultos salvo .well-known, ni node_modules, bin u obj, y rechaza enlaces.
• WAR/EAR existente: selecciona el archivo directamente.

Los builds limpian las salidas anteriores para evitar desplegar un paquete obsoleto. El proyecto Java debe estar configurado para producir WAR/EAR y ser compatible con el servidor/JDK elegidos. Si aparecen varios paquetes, puedes escoger uno. Un JAR ejecutable se inicia desde Ejecutar archivo o proyecto; no se convierte automáticamente en WAR.

Primero se prepara el paquete. Después se solicita confirmar Desplegar e iniciar o Solo desplegar. Detener una instancia afecta a todas las aplicaciones que contiene. El reemplazo conserva el paquete anterior, su carpeta expandida (Tomcat) o marcadores (WildFly) en deployment-backups dentro de la carpeta de la instancia. Estas copias permanecen hasta que las elimines manualmente. Un fallo de compilación no detiene el servidor.

Los logs del build están en <proyecto>/.devman/run/<sesión>/console.log; su ruta aparece en Salida. Consulta también los logs del servidor para verificar que la aplicación se desplegó correctamente. Para HTML llamado sitio, abre http://127.0.0.1:PUERTO/sitio/; el nombre ROOT usa /. Las aplicaciones Java pueden definir otro contexto.

CLI equivalente:

devman servers prepare-deploy /ruta/public html sitio
devman servers prepare-deploy /ruta/proyecto maven web
devman servers prepare-deploy /ruta/proyecto gradle web
# Usa el archivo devuelto en artifacts; detener afecta a toda la instancia:
devman servers --global stop web
devman servers --global deploy-replace web /ruta/sitio.war
devman servers --global start web

Omite --global y ejecuta desde la carpeta que define la instancia para trabajar por proyecto. deploy conserva su comportamiento sin sobrescritura; deploy-replace autoriza explícitamente reemplazar con respaldo.

Tomcat: HTML en vivo y WAR en caliente (0.11.0)

HTML en vivo: clic derecho sobre una instancia → Activar HTML en vivo (Tomcat). Selecciona la carpeta pública con index.html y un nombre de sitio, por ejemplo hola-dev. DevMan conserva una copia del sitio fuera de webapps y crea un Context de Tomcat para servirla. Guarda los cambios y refresca el navegador: se sincronizan altas, modificaciones y borrados de archivos públicos. No necesitas crear un WAR ni reiniciar la instancia. La publicación inicial puede tardar unos segundos en ser detectada por Tomcat.

El origen debe contener solo archivos públicos. Se permiten HTML/CSS/JS/JSON, imágenes, fuentes y otros recursos estáticos habituales. Se excluyen archivos ocultos (excepto recursos permitidos de .well-known), node_modules/bin/obj, WEB-INF/META-INF, JSP y código de servidor. Los enlaces se rechazan. Si un WAR ya usa ese nombre, elige otro para conservarlo. La carpeta original no se sirve directamente.

El menú Detener sincronización HTML pausa las copias; el sitio sigue publicado con la última copia. Cerrar o recargar la ventana de VS Code también detiene la sincronización: actívala de nuevo al volver. Ante un error se pausa y se muestra el detalle; tras resolverlo, vuelve a activarla. Una copia en curso puede terminar después de solicitar la pausa. La recarga automática del navegador es opcional al activar el sitio.

WAR en caliente: en Compilar / desplegar aplicación, prepara o selecciona el WAR y elige En caliente (sin detener Tomcat). El WAR completo se coloca mediante un reemplazo de archivo, con respaldo del anterior; Tomcat detecta el cambio y administra la recarga. La aplicación actualizada puede tener una breve interrupción y perder sesiones; las otras aplicaciones no se detienen. Si falla el arranque de la aplicación, revisa sus logs; el respaldo permite volver a publicar el WAR anterior, pero no hay rollback automático tras un fallo de Tomcat.

Requiere la configuración de instancia de DevMan (Catalina/localhost, webapps, autoDeploy activo); un Context personalizado con el mismo nombre se conserva y se pide otro nombre. No usa Tomcat Manager ni requiere configurar credenciales. Este modo en caliente es específico de Tomcat; WildFly conserva el flujo con parada. Desktop ofrece una casilla para WAR en caliente; la vigilancia al guardar se realiza desde VS Code.

CLI (cada sync-html hace una sincronización; la extensión mantiene la vigilancia):

devman servers --global sync-html web /ruta/public hola-dev
devman servers --global deploy-hot web /ruta/api.war

Omite --global y usa la carpeta de la instancia para trabajar por proyecto. Estos comandos no inician ni detienen el servidor; si está detenido, inícialo cuando corresponda. Los eventos se registran en los logs de diagnóstico de DevMan. Los detalles de despliegue/arranque aparecen en los logs de Tomcat.

Recarga automática del navegador

Al activar HTML en vivo, elige Recargar el navegador automáticamente o Actualizar el navegador manualmente. La opción sugerida se configura con devman.liveHtml.autoReload. Para cambiar un sitio activo, vuelve a activarlo con la misma carpeta y nombre y elige la otra opción.

Abre el sitio, o recarga una vez una pestaña que ya estaba abierta, para cargar el cliente de desarrollo. Después, guardar HTML, CSS, JavaScript o recursos públicos sincroniza los archivos y recarga las pestañas que tengan abierto ese sitio. No modifica los archivos de origen; solo las copias publicadas de HTML/HTM reciben un script. Funciona también en subcarpetas y en el contexto ROOT. El navegador consulta una pequeña señal en el mismo Tomcat, aproximadamente cada segundo, sin puertos ni extensiones adicionales. Solo se publica una nueva señal después de completar la sincronización y cuando hay cambios. Una sincronización sin cambios no recarga la página.

Desactivar la opción retira el script de las copias publicadas y notifica una última recarga a las pestañas anteriores. Detener la sincronización o cerrar VS Code deja la última copia publicada; las pestañas abiertas pueden seguir consultando la señal, pero no hay nuevos cambios que disparen recargas. La recarga completa puede perder el estado de formularios. Una política CSP que bloquee scripts o conexiones del mismo origen puede impedir el funcionamiento; DevMan no la modifica.

CLI: devman servers [--global] sync-html-reload <instancia> <carpeta> <sitio> hace una sincronización con recarga; sync-html la deja en modo manual. La vigilancia continua sigue a cargo de VS Code.