Skip to content

feat: monorepo support — per-package .bec/rules.yaml (or document the pattern) #82

Description

@DataDave-Dev

Context

Today there is exactly one .bec/rules.yaml, at the repo root. In a monorepo, teams own packages and will want to own their rules (packages/api/.bec/rules.yaml), with different severities per package.

The current workaround — scope rules with paths: ["packages/api/**"] globs — works and is now documented in usage.md's Performance and limits (#77), but it centralizes ownership at the root.

Options to evaluate

  1. Discover nested .bec/rules.yaml files and merge, with the nearest file winning for its subtree (mirrors .gitignore layering). Portability question: what does export mean for a nested rule?
  2. A root-level include: listing package rule files — explicit, no discovery cost.
  3. Do nothing and bless the glob-scoping pattern as the monorepo answer in the docs.

Option 3 is free; 1 is the most ergonomic but touches the frozen file discovery contract, so it needs the deprecation lens even though it is additive.

Acceptance

  • A decision recorded (even if it is option 3)
  • If 1/2: tests for precedence, why, export/import and the hook path
  • Docs updated either way

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions