Workspace boundary rules between packages (like `turbo boundaries`)
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- javascript, rust, typescript
Línea de trabajo
Begin in the Vite+ Rust source where the vp check command is implemented and where workspace packages and their package.json/vite.config.ts are parsed. Study the turbo boundaries docs and the three checks (relative imports, undeclared deps, tag rules) to model the graph. Add a --boundaries mode with tag config from vite-plus field or root config, then write integration tests on a sample monorepo.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Description
As a developer moving a monorepo from Turborepo to Vite+, I want to declare which workspace packages may depend on which, and have a Vite+ command fail when a package breaks that, so our architecture rules keep being enforced in CI after turbo is gone.
We run turbo boundaries as a required CI step. Each package's turbo.json declares tags (backend, frontend, app), and the root has two rules:
"boundaries": {
"tags": {
// a backend package must never end up in a frontend bundle
"backend": { "dependents": { "deny": ["frontend"] } },
// apps are dependency sinks, no app imports another app
"app": { "dependents": { "deny": ["app"] } }
}
}
It also flags a file that imports a package not declared in its own package.json (cannot import package 'x' because it is not a dependency), which catches imports that only work because of hoisting. On our repo (88 packages, about 4,400 files) it runs in under a second.
Vite+ has nothing equivalent that we could find, so this is one of the things keeping turbo in our toolchain.
Suggested solution
Tags on workspace packages and allow/deny rules between them, checked against both package.json dependencies and actual imports. vp check seems like the natural home since it's already the CI gate, or a separate vp check --boundaries if it shouldn't run by default.
Config would sit naturally in the root vite.config.ts, with tags per package. Packages without a vite.config.ts (most of ours: NestJS backends and libraries) would need somewhere to put their tags, maybe a vite-plus field in package.json.
Alternative
- Path-based lint rules in the style of ESLint's
import/no-restricted-paths. They work on file paths, not package tags, so we'd keep a hand-written list per package. dependency-cruiseroreslint-plugin-boundaries. Both work, but it's one more tool to configure, which is what we're trying to get away from.- What we did in the meantime: a ~340-line script that does turbo's three checks (relative imports leaving the package, undeclared package imports, tag rules over the dependency graph) and gives the same result as
turbo boundarieson our repo. It works, but it's ours to maintain, and every team leaving turbo would write the same thing.
Additional context
- Turborepo docs: https://turborepo.dev/docs/reference/boundaries
- Nx has the same idea as
@nx/enforce-module-boundaries.
Validations
- Read the Contributing Guidelines.
- Confirm this request is for Vite+ itself and not for Vite, Vitest, tsdown, Rolldown, or Oxc.
- Check that there isn't already an issue requesting the same feature.
- Lenguaje dominante
- Rust
- Estrellas
- 6.5k
- Forks
- 297
- Merge medio
- 20 h 18 min
- PR fusionados (30 d)
- 236
Preparar el entorno
Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.
- Sin Dockerfile ni archivo de Docker Compose
- Sin 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 voidzero-dev/vite-plus
-
triage: not actionable
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
voidzero-dev/vite-plus#3296 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
pending triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 63/100
voidzero-dev/vite-plus#3235 ·
Los mantenedores suelen responder en 1 día
-
Docker guide: the runtime stage needs libatomic1 for Node.js 25 and laterPosiblemente ocupada @kshanxs la tomó hace 9 días. Abiertodocumentation
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
voidzero-dev/vite-plus#3219 · 2 comentarios · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
pending triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
voidzero-dev/vite-plus#2882 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
Upgrade Upstream Dependencies timed outPosiblemente ocupada @fengmk2 la tomó hoy. Abiertoupgrade-deps-timeout
voidzero-dev/vite-plus#3319 · 1 asignado ·
Los mantenedores suelen responder en 1 día
Todos los issues de voidzero-dev/vite-plus
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
Los mantenedores suelen responder en 1 día
-
Rename SerVtdExt to ServtdExtAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
Los mantenedores suelen responder en 2 días
-
Android visitors are offered the Linux .deb on cap.so's homepage and download pagePosiblemente ocupada @patrickballard la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
CapSoftware/Cap#3677 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
DioxusLabs/blitz#1371 ·
Los mantenedores suelen responder en 1 día