Feature: flattenEmptyDirectories: support end-truncation for the whole flattened path instead of per-segment truncation
Maintainers usually reply within 1 day
@JoeJoeflyn is already working on this.
Since Aug 8, 2026.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 65/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- typescript
- Domain
- frontend
Research direction
Start at the useFileTree entry point and trace how flattenEmptyDirectories renders flattened path segments; then locate the related tests. Determine how to support an end-truncation option while preserving per-segment truncation as the default. Done means the whole flattened path can truncate at the end and the existing default behavior remains unchanged.
Written by the indexing model from the issue text.
Description
Prerequisites
- I have searched for duplicate or closed feature requests
- I have read the contributing guidelines
Proposal
Currently when
flattenEmptyDirectories: true is
enabled, each path segment is
individually wrapped in a Truncate
component, resulting in display
like:
a... / b... / c... / dd... / ...
We'd like to support an option to
truncate the whole flattened path
at the end, like:
aaa / bbb / ccc /...
This is more readable and matches
how most file explorers (e.g. VS
Code) handle deep nested paths.
Proposed API:
useFileTree({
flattenEmptyDirectories: true,
flattenedSegmentsTruncation:
'end', // 'per-segment' (default) |
'end'
})
Or alternatively a CSS variable /
data attribute that consumers can
use to override the truncation
strategy via unsafeCSS.
Motivation and context
When flattenEmptyDirectories: true
is enabled and the tree is rendered
in a narrow container (e.g. a
sidebar panel pushed to the right
edge), the per-segment truncation
produces a very poor visual result
— every segment gets clipped
individually, leaving a string of
disconnected ellipses like a... /
b... / c... / dd... / .... This
makes the path nearly unreadable
and wastes space with repeated ...
markers.
VS Code handles this well by
truncating the entire flattened
path as a single string at the end
(aaa / bbb / ccc /...), which keeps
as much of the path visible as
possible and is far easier to scan
at a glance. Supporting
end-truncation for the whole path
would bring @pierre/trees in line
with this established UX pattern
and significantly improve usability
in space-constrained layouts.
- Dominant language
- TypeScript
- Stars
- 6.2k
- Forks
- 226
- Avg merge
- 1d 12h
- Merged PRs (30d)
- 34
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
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from pierrecomputer/pierre
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
pierrecomputer/pierre#1187 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
pierrecomputer/pierre#1150 · 3 comments ·
Maintainers usually reply within 1 day
-
Bug: Dragging a selection past the edge of an editable CodeView collapses it, then stops it growingOpenbug
Difficulty 4/5 3-5 days Newbie friendliness 35/100
pierrecomputer/pierre#1189 ·
Maintainers usually reply within 1 day
-
Bug: WebKit crashes when drag-selecting text that auto-scrolls a diff (gutter-utility re-parented mid-drag)Possibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 4/5 3-5 days Newbie friendliness 25/100
pierrecomputer/pierre#1184 · 4 comments ·
Maintainers usually reply within 1 day
-
bug
Difficulty 3/5 1-2 days Newbie friendliness 63/100
pierrecomputer/pierre#1172 ·
Maintainers usually reply within 1 day
All issues in pierrecomputer/pierre
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
status:approved type:bug
Difficulty 1/5 Under an hour Newbie friendliness 70/100
egdev6/quorb#109 · 1 comment ·
Maintainers usually reply within 1 day
-
stage:4
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
ilan-pinto/roaring-lions#598 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
Frontmatter next to `src:` is applied to every imported slide, not only the first (undocumented)Open
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Maintainers usually reply within 1 day