LSP extension matching broken for extensionless files (e.g. wscript, Makefile, Dockerfile)

[Erik-Vimotek]

Bug

LSP servers configured with extensionless filenames in the extensions array never activate. This affects any extensionless file that should be treated as Python, such as wscript files used by the waf build system.

Root cause

The extension matching logic falls back to the full absolute path when a file has no extension:

let m = z1.parse(K).ext || K

For /home/user/project/subdir/wscript, path.parse(K).ext is "", so m becomes the full path. extensions.includes(m) then never matches "wscript".

Suggested fix

let m = z1.parse(K).ext || z1.basename(K)

Reproduction

"lsp": {
  "pyright": {
    "command": ["pyright-langserver", "--stdio"],
    "extensions": [".py", ".pyi", "wscript"]
  }
}

Open any file named wscript. The LSP server never starts.

Version

OpenCode 1.17.9

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• [FEATURE]: ** At now LSP doesn't work for files that have no extension, like Dockerfile, Makefile, Containerfile, or CHANGELOG. #27604: LSP doesn't work for extensionless files like Dockerfile, Makefile, Containerfile — same root problem
• [Bug] Dockerfile LSP does not work when filename is Dockerfile #18558: Dockerfile LSP does not work when filename is Dockerfile — same symptom
• Custom LSP cannot target CMakeLists.txt because matching is extension-only #18384: Custom LSP cannot target CMakeLists.txt because matching is extension-only — same root cause
• [FEATURE]: Support LSP detection via shebang line for extensionless scripts #15518: Feature request for LSP detection via shebang line for extensionless scripts — related

If your issue is not covered by any of these, please clarify what distinguishes it.