Workspace boundary rules between packages (like `turbo boundaries`)
Mantenedores costumam responder em até 1 dia
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 5/5
- Tempo estimado
- Mais de uma semana
- Facilidade para iniciantes
- 35/100
- Tipo de issue
- Funcionalidade
- Clareza
- Razoavelmente clara
- Status de atividade
- Ativa
- Stack de tecnologia
- javascript, rust, typescript
Direção de pesquisa
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.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
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.
- Linguagem predominante
- Rust
- Estrelas
- 6.5k
- Forks
- 297
- Merge médio
- 20h 18min
- PRs com merge (30d)
- 236
Preparar o ambiente
Inicia o contêiner de desenvolvimento do projeto no navegador, com a sua própria conta do GitHub.
- Sem Dockerfile nem arquivo Docker Compose
- Sem modelo de pull request
- Ler o guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de voidzero-dev/vite-plus
-
triage: not actionable
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 85/100
voidzero-dev/vite-plus#3296 · 1 comentário ·
Mantenedores costumam responder em até 1 dia
-
pending triage
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 63/100
voidzero-dev/vite-plus#3235 ·
Mantenedores costumam responder em até 1 dia
-
Docker guide: the runtime stage needs libatomic1 for Node.js 25 and laterTalvez já em andamento @kshanxs assumiu há 9 dias. Abertadocumentation
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 84/100
voidzero-dev/vite-plus#3219 · 2 comentários · 1 reação ·
Mantenedores costumam responder em até 1 dia
-
pending triage
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
voidzero-dev/vite-plus#2882 · 2 comentários ·
Mantenedores costumam responder em até 1 dia
-
Upgrade Upstream Dependencies timed outTalvez já em andamento @fengmk2 assumiu hoje. Abertaupgrade-deps-timeout
voidzero-dev/vite-plus#3319 · 1 responsável ·
Mantenedores costumam responder em até 1 dia
Todas as issues de voidzero-dev/vite-plus
Issues semelhantes
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 65/100
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 62/100
Mantenedores costumam responder em até 2 dias
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 65/100
GiganticMinecraft/seichi-portal-backend#1651 ·
Mantenedores costumam responder em até 1 dia
-
Android visitors are offered the Linux .deb on cap.so's homepage and download pageTalvez já em andamento @patrickballard assumiu hoje. Aberta
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
CapSoftware/Cap#3677 · 1 comentário ·
Mantenedores costumam responder em até 1 dia
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
Mantenedores costumam responder em até 1 dia