Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Support hierarchical Diff lenses for multi-part changes

Open
  • Is something wrong?
#622 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Active
Tech stack
typescript
Domain
developer-experience

Research direction

The issue names the Diff sidebar but no source files, tests, or entry points. First, explore the repository to find how Diff lenses are represented and rendered, then consider how hierarchical selection, overlapping ranges, shared changes, counts, and review progress would work. Done is not defined: the issue explicitly opens a design discussion rather than proposing a finished design.

Written by the indexing model from the issue text.

Description

Problem

Diff lenses make a large change easier to review by grouping related parts of the diff. Today, the lenses appear in a flat list. For a PR with several capabilities, each built from smaller implementation and test changes, that list does not show how the parts fit together. A reviewer has to infer the hierarchy from lens names and switch between several lenses to see the scope of one capability.

For example, Sarama PR #3419 adds two related Kafka admin operations: ListOffsets and AlterConsumerGroupOffsets. Each has its own API, implementation, and tests, while some changes are shared. A useful review outline would look like this:

KIP-396 offset management
├── ListOffsets
│   ├── API and result model
│   ├── Broker fan-out and errors
│   └── Unit and functional tests
├── AlterConsumerGroupOffsets
│   ├── API and protocol version
│   ├── Coordinator commit and retry
│   └── Unit and functional tests
└── Shared test setup and imports

ListTopics retry helper change

Possible direction

A collapsible tree in the Diff sidebar could show capability/subfeature relationships while keeping simple changes flat. A reviewer could start with a capability-level overview, then narrow down to an implementation step or its tests without losing the structure of the PR.

The details need more thought: what selecting a parent should show, how counts and review progress should handle overlapping ranges, how shared changes should appear, and when an agent should create a hierarchy. I am opening this issue to discuss the idea rather than to propose a finished design.

Dominant language
TypeScript
Stars
2.9k
Forks
145
Avg merge
17h 29m
Merged PRs (30d)
580

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

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.

More from devdotfast/whiteboard

All issues in devdotfast/whiteboard

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.