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

TS7 LSP: documentHighlight returns nothing when the file path contains '@'

Open Beginner friendly
  • Is something wrong?
#64,758 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
78/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
go
Domain
backend-api-design

Research direction

Start with tsc/internal/ls/documenthighlights.go:30, where the issue identifies a raw URI string comparison, and inspect tsc/internal/ls/lsconv/converters.go:315 to understand URI encoding. Reproduce using the provided TypeScript file under a path containing @ and compare the encoded and unencoded URI results. Done means document highlights return all three matches for either URI form; the issue does not name a test file.

Written by the indexing model from the issue text.

Description

🔎 Search Terms

documentHighlight, document highlight, URI encoding, percent-encoding, %40, @ in path, Neovim, LSP

🕗 Version & Regression Information
  • I was unable to test this on prior versions because this code is in the TS7 language server only. The old tsserver (through vtsls) does not have this problem.

I reproduced it with tsc --lsp 7.0.2. The same code is on main at ba1819f.

⏯ Playground Link

Not applicable. The problem is in the language server.

💻 Code

Put this file in a directory whose path contains @, for example /tmp/a@b/proj/x.ts, with an empty tsconfig.json next to it:

const foo = 1;
console.log(foo);
console.log(foo);
🙁 Actual behavior

textDocument/documentHighlight on foo (line 0, character 7) returns an empty array if the client sends the path with @ not encoded:

URI that the client sends Highlights
file:///tmp/a@b/proj/x.ts 0
file:///tmp/a%40b/proj/x.ts 3
file:///tmp/plain/proj/x.ts 3

Neovim sends the first form (vim.uri_from_fname("/tmp/a@b/x.ts") gives file:///tmp/a@b/x.ts). Thus, in Neovim, document highlights and features that use them (for example, jump to next reference) do not work in projects whose path contains @. Other requests, such as textDocument/references, work correctly on the same file.

🙂 Expected behavior

The server returns 3 highlights for all three URIs. The two a@b URIs identify the same file, and the server opens that file correctly from both forms.

Additional information about the issue

Cause. tsc/internal/ls/documenthighlights.go:30 filters the results with a raw string compare:

if mh.Uri == documentUri {
  • mh.Uri comes from lsconv.FileNameToDocumentURI, which encodes @ as %40 (tsc/internal/ls/lsconv/converters.go:315).
  • documentUri is the string that the client sent, without changes.

When the client does not encode @, the strings are different, and the filter removes all highlights. VS Code does not see this problem because vscode-uri also encodes @ as %40 (URI.file('/tmp/a@b/x.ts').toString() gives file:///tmp/a%40b/x.ts). Thus the two sides always agree.

Why this is a server problem. RFC 3986 permits @ in a path segment without encoding, so the client URI is valid. Also, the LSP specification (URI section) says:

Clients and servers should not assume that each other are encoding the same way (for example a client encoding colons in drive letters cannot assume server responses will have encoded colons).

Possible fix. Compare file names, not URI strings:

if mh.Uri.FileName() == documentUri.FileName() {

Another possible fix is to normalize documentUri one time before the loop. Other characters in extraEscapeReplacer (', (, ), *, +, ,, ;, =, !, $, &, and so on) probably cause the same problem with clients that do not encode them.

Related: #43261 had the same type of cause (a path-case mismatch caused document highlights to fail) in tsserver.

Environment

  • Neovim v0.12.0-dev, Linux (WSL2)
  • tsc --lsp 7.0.2
Dominant language
Go
Stars
111k
Forks
16.4k
Avg merge
1d 11h
Merged PRs (30d)
148

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

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 microsoft/TypeScript

All issues in microsoft/TypeScript

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.