square / square/invert

File-Based Ownership

Open
#40 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Kotlin
Stars
129
Forks
4
PR merge metrics
No merged PRs in 30d

Description

The initial "unit" was "modules" in #invert and Code References was bolted on later. Code References DO support owner which overrides that of the module it's in (Was required for @TestOwner).

I agree that based on where we are today, we should actually lean towards file-based ownership instead of module based as a default.

Proposed logic:
  • If a CodeReference has an explicit owner attached to it, use it (Nice for custom situations that override file/module based ownership methods).
  • After collection, if no owner is manually added, compute file-based ownership.
  • If file-based ownership doesn't come back to anything, then fall back to module ownership.
Thoughts about a required owner field for CodeReference:

Right now owner :String? is nullable. We could change that to non-null, but it would require updating all collectors to have explicit awareness to add file-based ownership.
Based on this "breaking" change, and because it makes authoring Collectors more complex, I would lean towards keeping it nullable, and use the proposed logic above.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing CodeReference and the collectors that populate ownership. Verify that explicit CodeReference owners take precedence, file-based ownership is computed when no owner is supplied, and module ownership is used only as a fallback while owner remains nullable.

Written by the indexing model from the issue text.

Assessment

Tech stack
kotlin
Domain
devtools
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.