Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

cli: export the terminal display-width measure

Aperta Adatta ai principianti
  • Qualcosa non va?
#8,863 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
1/5
Tempo stimato
1-3 ore
Idoneità per principianti
86/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
devtools

Direzione di ricerca

Inizia in CliOutput.ts del modulo CLI e individua la misura interna visualLength (introdotta da #7572 per l'allineamento dell'help); elimina già lo stiling ANSI e applica le regole grapheme/East Asian Width. Esportala come CliOutput.displayWidth con un commento di doc, verifica che la superficie pubblica del modulo (percorso di re-export per effect/cli) la esponga e aggiungi test che verifichino gli esempi dell'issue (larghezza del nome file 8, carattere accentato 1, emoji 2). Fatto quando CliOutput.displayWidth("ファイル") === 8 e il testo con stile misura lo stesso di quello senza stile.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.
Lingua principale
TypeScript
Stelle
16.7k
Fork
808
Merge medio
11h 29m
PR unite (30g)
453

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Effect-TS/effect

Tutte le issue di Effect-TS/effect

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.