Workspace boundary rules between packages (like `turbo boundaries`)
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- javascript, rust, typescript
Direzione di ricerca
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.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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.
- Lingua principale
- Rust
- Stelle
- 6.5k
- Fork
- 297
- Merge medio
- 20h 18m
- PR unite (30g)
- 236
Preparare l'ambiente
Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di voidzero-dev/vite-plus
-
triage: not actionable
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
voidzero-dev/vite-plus#3296 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
pending triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 63/100
voidzero-dev/vite-plus#3235 ·
I maintainer di solito rispondono entro 1 giorno
-
Docker guide: the runtime stage needs libatomic1 for Node.js 25 and laterForse già presa @kshanxs l’ha presa 9 giorni fa. Apertadocumentation
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
voidzero-dev/vite-plus#3219 · 2 commenti · 1 reazione ·
I maintainer di solito rispondono entro 1 giorno
-
pending triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
voidzero-dev/vite-plus#2882 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Upgrade Upstream Dependencies timed outForse già presa @fengmk2 l’ha presa oggi. Apertaupgrade-deps-timeout
voidzero-dev/vite-plus#3319 · 1 assegnatario ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di voidzero-dev/vite-plus
Issue simili
-
priority: low ☕️ type: bug 🐛
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
I maintainer di solito rispondono entro 1 giorno
-
area:docs documentation good first issue priority:medium
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 78/100
rtk-ai/rtk#4958 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
feature
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
calagopus/panel#285 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
agent-self
Difficoltà 2/5 1-3 ore Idoneità per principianti 62/100
yologdev/yoyo-evolve#1117 · 1 commento ·
-
[Bug]: streamed Responses API flex_unavailable error maps to 500 InternalServerError instead of 429Apertallm translation
Difficoltà 2/5 Meno di un'ora Idoneità per principianti 85/100
BerriAI/litellm#49736 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno