Design workspace and multi-package support
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- rust
- Área
- build-system
Línea de trabajo
Start by reading the existing manifest, lockfile, package discovery, and CLI command-selection entry points; the issue does not name specific files. Draft an agreed workspace manifest and lockfile model, covering member ordering, selection, command behavior, metadata, and compatibility. Done means the design answers the listed questions and includes a staged implementation plan with integration-test fixtures.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Motivation
Vex currently models one package per project root. Larger Wave codebases need multiple related packages with shared commands, one reproducible dependency graph, and efficient builds.
Workspace support affects manifest discovery, lockfile ownership, path dependencies, target directories, metadata, and command selection, so it needs an explicit design before implementation.
Design questions
- How does
vex.wsdeclare workspace members and exclusions? - Does the workspace own one
vex.lock? - How are default members and package selection expressed?
- How do
build,check,run,tree,update, and future metadata behave? - How are duplicate package names and dependency cycles diagnosed?
- How are nested workspaces handled?
Acceptance criteria
- Publish an agreed manifest and lockfile model.
- Preserve single-package behavior and portability.
- Define deterministic member discovery and ordering.
- Define CLI package selection without forwarding raw wavec options.
- Include metadata schema implications.
- Add a staged implementation plan with integration-test fixtures.
- Lenguaje dominante
- Rust
- Estrellas
- 1
- Forks
- 3
- Merge medio
- 23 h 3 min
- PR fusionados (30 d)
- 7
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de wavefnd/Vex
-
Provide an official Meson consumer recipe and incremental C/C++/Rust integration testsPosiblemente ocupada @LunaStev la tomó hace 5 días. Abierto
-
Support reproducible Wave artifacts across source and build directory locationsPosiblemente ocupada @LunaStev la tomó hace 5 días. Abierto
-
Define package aliases and multiple-version coexistencePosiblemente ocupada @LunaStev la tomó hace 5 días. Abiertodependencies discussion feature request wave compatibility
Dificultad 5/5 Más de una semana Aptitud para principiantes 32/100
Todos los issues de wavefnd/Vex
Issues similares
-
Shell `yoyo <verb> <sub>` missing its required argument prints usage and exits 0: `config get`Abiertoagent-self
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
yologdev/yoyo-evolve#1154 ·
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 85/100
eliasstravik/herdr-projects#789 · 1 comentario ·
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 64/100
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Alex-Sebastian-Ene/mind-over-chicken#195 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 2 días