anomalyco / anomalyco/opencode

Bug: TUI syntax highlighting fails on uppercase extensions and extensionless files

Open
#39,601 0 comments 0 reactions 1 assignee View on GitHub

@simonklee is already working on this.

Since Jul 30, 2026.

Dominant language
TypeScript
Stars
209k
Forks
27.5k
PR merge metrics
PR metrics pending

Description

Description

filetype() in packages/tui/src/util/filetype.ts looks up LANGUAGE_EXTENSIONS[path.extname(input)]. That lookup is exact and case-sensitive, so it misses in three ways:

1. Uppercase extensions get no highlighting. path.extname("COMPONENT.TSX") is ".TSX", which is not a key:

filetype("COMPONENT.TSX") -> undefined   (expected "typescript")
filetype("main.PY")       -> undefined   (expected "python")
filetype("Program.CS")    -> undefined   (expected "csharp")

Common in practice for .PY, .SQL, and Windows-authored files.

2. Extensionless files never match. path.extname("Makefile") is "", so the makefile key in the map is unreachable:

filetype("Makefile") -> undefined   (expected "makefile")

3. Five map keys are dead entries. path.extname() only ever returns the final .xxx, so compound keys can never be hit. These are present in the map but unreachable:

makefile, .html.erb, .js.erb, .css.erb, .json.erb

filetype("index.html.erb") does resolve to "erb", but only via the plain .erb key — the more specific entries are never consulted.

The value feeds tree-sitter highlighting (see packages/tui/src/parsers-config.ts), so a miss means the file renders unhighlighted in the diff viewer and permission prompts.

Separately, packages/tui/src/feature-plugins/system/diff-viewer.tsx:73 contains a byte-identical private copy of filetype(), so the diff viewer carries the same bug independently.

Steps to reproduce

import { filetype } from "./packages/tui/src/util/filetype"

console.log(filetype("COMPONENT.TSX"))  // undefined
console.log(filetype("main.PY"))        // undefined
console.log(filetype("Makefile"))       // undefined

OS

Windows (platform-independent — pure lookup logic)

Contributor guide

Open the contributing guide

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.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.