Skip to main content
Al crear un proyecto (GUI, shell o CLI) primero defines la plataforma (web, CLI, escritorio, móvil), la forma (frontend, API o fullstack, para web) y la arquitectura del repo (repo único, monorepo, polyrepo o metarepo, según la forma); luego eliges tecnologías de un catálogo. No todas están al mismo nivel de madurez ni todas tienen sentido por sí solas: Nexenv modela eso con un status por tecnología, con dependencias entre ellas, y con un filtro de relevancia según la plataforma y la forma que elegiste.

​
Status de una tecnología

Cada entrada del catálogo (src-tauri/src/core/catalog/technologies/*.yaml) declara un status:
StatusSeleccionableQué significa
stableSíProbada; produce un proyecto funcional.
experimentalSí (con aviso)Presente y usable, pero sin garantía completa de las recipes/plantillas asociadas. Lleva un badge exp.
plannedNoDeclarada pero todavía no implementada. Aparece deshabilitada con un aviso amarillo “Próximamente”.
deprecatedNoYa no recomendada; bloqueada para proyectos nuevos.
La regla la aplica una única fuente de verdad en el backend (validate_stack), que usan la GUI, el comando validate y el wizard del CLI. Además, la generación (generate_project) rechaza un stack que incluya tecnologías no usables, así que ni la API ni nexenv new --techs pueden colar una tecnología “próximamente”.

​
Dependencias entre tecnologías

Hay dos tipos de dependencia, ambos codificados en el catálogo:
  • requires (todas): la tecnología necesita otra concreta, que se autoañade al seleccionarla. Ej.: prisma requiere nodejs.
  • requires_any (una de varias): la tecnología solo es usable si al menos una de una lista está seleccionada, y como no se puede elegir cuál por ti, queda no seleccionable hasta que elijas una base. Ej.: Vite necesita un framework frontend (React, Vue, Svelte, Solid o Qwik); los bundlers y los runners E2E siguen la misma regla.

​
Relevancia por plataforma y forma

El catálogo tiene ~90 tecnologías, pero no todas aplican a lo que estás construyendo. En el paso de stack, Nexenv muestra por defecto solo las relevantes para tu plataforma + forma y oculta el resto:
  • Un frontend oculta backends, bases de datos y ORMs.
  • Una API oculta frameworks de frontend y estilos.
  • Móvil oculta bundlers y meta-frameworks web.
  • CLI oculta web, estilos y bases de datos.
Las categorías se ordenan por flujo lógico (runtime → frontend → estilos → backend → DB → ORM → auth → testing → devops), no alfabético. Un toggle “Mostrar todas / Solo relevantes” te deja ver el catálogo completo cuando quieras algo atípico. Lo que ya tengas seleccionado siempre se muestra.

​
Estados de las tarjetas (GUI)

En el paso de stack del wizard, las tarjetas tienen tamaño uniforme y:
  • Sin selección: sin borde.
  • Seleccionada: borde verde (resalta).
  • Sugerida (compatible con tu selección): borde gris plateado.
  • planned: deshabilitada, badge soon, y al pasar el ratón un tooltip amarillo “¡Próximamente!”.
  • Bloqueada por dependencia / incompatibilidad: deshabilitada con un tooltip explicando qué falta (“elige una de…”).
Los starter packs que referencian alguna tecnología no usable se ocultan automáticamente (la disponibilidad la dirige el status del catálogo).

​
En el CLI

El wizard de nexenv new (y el de la shell interactiva, nexenv shell → /new) sigue el mismo modelo que la GUI: plataforma → forma → arquitectura del repo (con las mismas opciones válidas) → perfil → stack. Solo ofrece tecnologías usables; lista las planned como “Próximamente” y las deprecated como aviso, pero no permite elegirlas. Los flags --platform, --type (forma), --repo-arch y --profile permiten saltarse los pasos. nexenv validate <techs...> reporta incompatibilidades, dependencias requires/requires_any sin satisfacer y status no usable.

​
Idiomas

Los textos están internacionalizados (i18n). El idioma por defecto es inglés (“Coming soon”); el español muestra “¡Próximamente!”.