Workspace boundary rules between packages (like `turbo boundaries`)

Đang mở
#3,295 1 bình luận 1 reaction 0 người được giao Xem trên GitHub

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
Lĩnh vực
cli, tooling

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ả

triage: not actionable
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-cruiser or eslint-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 boundaries on our repo. It works, but it's ours to maintain, and every team leaving turbo would write the same thing.
Additional context
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

Mở trong Codespaces

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.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của voidzero-dev/vite-plus

Tất cả issue của voidzero-dev/vite-plus

Issue tương tự

Thêm issue về Rust

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.