Skip to content

TypeScript LSP server is not used if package.json is in a sub-directory #18694

Closed as not planned
Closed as not planned
TypeScript LSP server is not used if package.json is in a sub-directory#18694
Assignees
rekram1-node

Description

@x1unix
x1unix
opened on Mar 23, 2026

Description

Hello.

I've a Go+React TypeScript project. The front-end code in TypeScript is located in a /web subdir of a repo.

If I run opencode in a root dir of the repo, it doesn't use TypeScript language as package.json and node_modules are located in the web sub directory.

At the moment, the only way to workaround this is to start opencode in web subdirectory.

This creates a problem when I have a task where I need to operate on both backend (Go) and frontend (TS) code.

Plugins

n/a

OpenCode version

1.2.27

Steps to reproduce

  1. Clone the repo: https://github.com/x1unix/go-playground
  2. Install yarn dependencies in the web subdirectory.
  3. Run opencode on a prompt which should grep both Go and TypeScript files
  4. Check that opencode can start gopls but doesn't start TypeScript language server
  5. Shut down opencode, run cd web && opencode and do some queries
  6. Check that typescript lsp is started when inside web dir.

Screenshot and/or share link

opencode is ran at the root, only gopls is called:

Image

opencode executed at /web subdirectory near node_modules and package.json, TS LSP is running:

Image

Operating System

Arch

Terminal

kitty

Activity

  1. x1unix
    added
    bugSomething isn't working
    on Mar 23, 2026
  2. github-actions
    assigned
    rekram1-node
    on Mar 23, 2026
  3. github-actions
    added
    coreAnything pertaining to core functionality of the application (opencode server stuff)
    on Mar 23, 2026
  4. x1unix
    changed the title [-]TypeScript LSP server is not used it package.json is in a sub-directory[/-] [+]TypeScript LSP server is not used if package.json is in a sub-directory[/+] on Mar 23, 2026

  5. github-actions commented on Mar 23, 2026

    @github-actions
    github-actionsBot
    on Mar 23, 2026 – with GitHub Actions
    Contributor

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

    • LSP detection in monorepo not working #7690: LSP detection in monorepo not working — same root cause: TypeScript/ESLint LSP not enabled when opencode is started from the git root rather than the frontend subdirectory containing package.json.
  6. thdxr
    removed
    bugSomething isn't working
    coreAnything pertaining to core functionality of the application (opencode server stuff)
    on May 3, 2026

  7. samiralibabic commented on May 8, 2026

    @samiralibabic
    samiralibabic
    on May 8, 2026

    Very much needed.

  8. samiralibabic commented on May 8, 2026

    @samiralibabic
    samiralibabic
    on May 8, 2026

    I can reproduce this same failure mode on OpenCode 1.14.41 with a TypeScript package in a child directory.

    Local repro, with paths sanitized:

    OpenCode cwd: /repo
Target file: /repo/apps/api/src/server.ts
OPENCODE_EXPERIMENTAL_LSP_TOOL=true

    /repo has no package.json / node_modules, while /repo/apps/api is the actual TypeScript package and can resolve:

    /repo/apps/api/node_modules/typescript/lib/tsserver.js

    The live LSP tool reports:

    No LSP server available for this file type.

    But the OpenCode log shows TypeScript LSP startup was attempted:

    service=lsp.server typescript server

    There is no tsserver path in that log entry. From the current TypeScript LSP implementation, this appears to mean typescript/lib/tsserver.js is being resolved from the OpenCode launch directory / instance directory rather than from the detected TypeScript workspace root for the target file.

    This does not look like a file extension support issue: the .ts file was recognized far enough for TypeScript LSP startup to be attempted. It also does not look like an lsp config gate in this case: "lsp": {} is valid per the current docs, and the log shows permission=lsp evaluated as allowed.

    I also found the earlier attempts/discussion around this: #7690, #16335, #7691, and #17359. The PRs appear to be closed/stale, and I do not see an active PR covering the TypeScript-specific root-resolution case.

    Proposed narrow first fix:

    • for TypeScript LSP startup, resolve typescript/lib/tsserver.js from the detected LSP/workspace root first;
    • fall back to the OpenCode launch directory to preserve current behavior;
    • keep the PR TypeScript-only;
    • improve the failure log when tsserver cannot be resolved;
    • add regression coverage or a manual repro for a repo root with apps/api/package.json + apps/api/node_modules/typescript.

    A broader workspace-aware LSP resolver could happen separately, but this TypeScript-only change seems small and should address this issue without a larger LSP-manager redesign.

    Before I work on a PR, would maintainers be open to this narrow direction?

  9. sankalpmukim commented on May 13, 2026

    @sankalpmukim
    sankalpmukim
    on May 13, 2026

    If there was a configuration-driven only fix for this, like we suggest where the LSP roots (package.json) files are, and it picks those up, that will be fine for most monorepo use cases too

  10. nelsonwellswku commented on Jul 5, 2026

    @nelsonwellswku
    nelsonwellswku
    on Jul 5, 2026

    This is a problem for me as well as most of my projects are separated into backend and frontend projects that are not in the root. The Python LSP (backend) is found correctly, but the Typescript LSP (frontend) is never loaded.

  11. punsii commented on Aug 13, 2026

    @punsii
    punsii
    on Aug 13, 2026

    Just wanted to push this. Putting backend and frontend project configuration files in different subdirectories is a really common practice and most tools have no problem with finding the correct configs to apply before running any form of linter or lsp.
    Edit: Just saw that #35396 already contains an analysis of the problem and proposes a fix.

  12. sankalpmukim commented on Aug 13, 2026

    @sankalpmukim
    sankalpmukim
    on Aug 13, 2026

    Some time in the last few weeks, they've added the ability to change the folder of an ongoing opencode session. That feature addition makes it simpler for some usecases

  13. thdxr commented on Oct 11, 2026

    @thdxr
    thdxr
    on Oct 11, 2026
    Member

    Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.

    — from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊

  14. thdxr
    closed this as not plannedon Oct 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions