Workspace boundary rules between packages (like `turbo boundaries`)
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 35/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- javascript, rust, typescript
Hướng nghiên cứu
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.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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.
- Ngôn ngữ chính
- Rust
- Star
- 6.5k
- Fork
- 297
- Merge trung bình
- 1 ngày 1 giờ
- Pull request đã merge (30 ngày)
- 249
Chuẩn bị môi trường
Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của voidzero-dev/vite-plus
-
triage: not actionable
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
voidzero-dev/vite-plus#3296 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
pending triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 63/100
voidzero-dev/vite-plus#3235 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Docker guide: the runtime stage needs libatomic1 for Node.js 25 and laterCó thể đã có người làm @kshanxs đã nhận 11 ngày trước. Đang mởdocumentation
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
voidzero-dev/vite-plus#3219 · 2 bình luận · 1 reaction ·
Maintainer thường phản hồi trong vòng 1 ngày
-
pending triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
voidzero-dev/vite-plus#2882 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
vp staged reports a saved recovery patch that is missing after restore failure on WindowsCó thể đã có người làm @voidzero-bot đã nhận hôm nay. Đang mở- P3: minor bug triage: fix verified
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 25/100
voidzero-dev/vite-plus#3356 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của voidzero-dev/vite-plus
Issue tương tự
-
Windows docs: pin a tested ConPTY version for Kitty graphics; 1.25.260930003 corrupts large uploadsĐang mở
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 88/100
raphamorim/rio#2021 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
hydro-project/infinity#187 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 77/100
near/near-sdk-rs#1676 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
auto:producer auto:security
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
fritzprix/libr-agent#2595 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
area:fs type:fix
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Tripstack-Corp/spyc#1002 ·
Maintainer thường phản hồi trong vòng 1 ngày