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

cli: export the terminal display-width measure

Closed Beginner friendly
  • Is something wrong?
#8,863 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

A pull request for this has already been merged.

  • #8982 by @Yi-111-a — merged

Assessment

Difficulty
1/5
Estimated time
1-3 hours
Newbie friendliness
86/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
typescript
Domain
devtools

Research direction

Start in the CLI module's CliOutput.ts and locate the internal visualLength measure (introduced by #7572 for help alignment); it already strips ANSI styling and applies grapheme/East Asian Width rules. Export it as CliOutput.displayWidth with a doc comment, verify the module's public surface (re-export path for effect/cli) exposes it, and add tests asserting the examples in the issue (file name width 8, accented char 1, emoji 2). Done when CliOutput.displayWidth("ファイル") === 8 and styled text measures the same as unstyled.

Written by the indexing model from the issue text.

Description

What is the problem this feature would solve?

#7572 fixed help alignment by measuring text in terminal cells instead of UTF-16 code units, which closed #7557. The measure itself stayed internal (visualLength in CliOutput.ts), so the second half of that issue is still open.

Anything a CLI draws next to the built-in output has to measure text by the same rules to line up with it: a custom CliOutput.Formatter, a boxed banner, a table, a prompt built on Prompt.Custom. Today the only options are copying the grapheme and East Asian Width logic into the application, or adding string-width. Either way the application's measure can disagree with the one the built-in help uses, so the two drift as either side changes.

What is the feature you are proposing to solve the problem?

Export the existing measure, for example as CliOutput.displayWidth:

CliOutput.displayWidth("ファイル") // 8
CliOutput.displayWidth("é")   // 1
CliOutput.displayWidth("1️⃣") // 2

It should strip ANSI styling as it does today, so styled and unstyled text measure the same. No new logic is needed, only the export and a doc comment.

What alternatives have you considered?
  • Reimplementing it per application: what we do today. It duplicates Unicode knowledge that already lives in Effect, and the two implementations can disagree.
  • string-width: an extra dependency that measures by its own tables, so it can still disagree with the built-in help.
  • A home in effect/String instead of effect/cli: also fine, since the measure is useful outside the CLI module.
Dominant language
TypeScript
Stars
16.7k
Forks
808
Avg merge
10h 38m
Merged PRs (30d)
495

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 Effect-TS/effect

All issues in Effect-TS/effect

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.