LSP Diagnostics return nothing in large project #536

Open
opened 2026-02-16 17:27:13 -05:00 by yindo · 15 comments
Owner

Originally created by @drewbitt on GitHub (Jul 7, 2025).

Originally assigned to: @thdxr on GitHub.

I have a large nx monorepo at work and get on files

opencode debug lsp diagnostics apps/web/src/App/index.tsx

{}

even if I introduce a bug that the VSCode LSP is catching.

If no TSServer is running, due to thousands of files this command takes 70+ seconds due to hundreds of file watchers.

I've tried recreating the bug but small nx monorepos are fine.

If a TSServer is running, this will complete in less than 1 second but will still return {}

I see in TSServer logs that it is setting up an Inferred Project but then also finds the correct tsconfig.app.json, but then exits without finding the error. I wonder if the 3s timeout is related https://github.com/sst/opencode/blob/76b2e4539cb97bae5812ed2d832ce49d02e70c64/packages/opencode/src/lsp/client.ts#L176

Originally created by @drewbitt on GitHub (Jul 7, 2025). Originally assigned to: @thdxr on GitHub. I have a large nx monorepo at work and get on files ``` opencode debug lsp diagnostics apps/web/src/App/index.tsx {} ``` even if I introduce a bug that the VSCode LSP is catching. If no TSServer is running, due to thousands of files this command takes 70+ seconds due to hundreds of file watchers. I've tried recreating the bug but small nx monorepos are fine. If a TSServer is running, this will complete in less than 1 second but will still return `{}` I see in TSServer logs that it is setting up an Inferred Project but then also finds the correct `tsconfig.app.json`, but then exits without finding the error. I wonder if the 3s timeout is related https://github.com/sst/opencode/blob/76b2e4539cb97bae5812ed2d832ce49d02e70c64/packages/opencode/src/lsp/client.ts#L176
Author
Owner

@drewbitt commented on GitHub (Jul 8, 2025):

After the LSP changes, it is interesting I get different results just running the same command one after the other. All showing unrelated files.

❯ opencode debug lsp diagnostics apps/snow-web/src/global.d.ts
{
  "/Users/drewbitt/Documents/Repos/web/apps/switch/src/polyfills.ts": [],
  "/Users/drewbitt/Documents/Repos/web/apps/auth-web/src/utils/auth.utils.ts": [],
}


❯ time opencode debug lsp diagnostics apps/snow-web/src/global.d.ts
{
  "/Users/drewbitt/Documents/Repos/web/apps/switch/src/polyfills.ts": [],
  "/Users/drewbitt/Documents/Repos/web/apps/auth-web/src/utils/auth.utils.ts": [],
  "/Users/drewbitt/Documents/Repos/web/tools/snowdrop/src/generators/api/createApi.ts": [
    {
      range: [Object ...],
      message: "'node' is declared but its value is never read.",
      severity: 4,
      code: 6133,
      source: "typescript",
    }
  ],
  "/Users/drewbitt/Documents/Repos/web/apps/portal-web/src/polyfills.ts": [],
  "/Users/drewbitt/Documents/Repos/web/tools/generators/graphql/src/generators/export/schema.d.ts": [],
  "/Users/drewbitt/Documents/Repos/web/apps/sr/sr-public/src/environments/environment.ts": [],
}

real    16.08s
user    0.90s
sys     2.16s

❯ time opencode debug lsp diagnostics apps/snow-web/src/global.d.ts
{}

real    6.01s
user    0.51s
sys     2.74s
@drewbitt commented on GitHub (Jul 8, 2025): After the LSP changes, it is interesting I get different results just running the same command one after the other. All showing unrelated files. ``` ❯ opencode debug lsp diagnostics apps/snow-web/src/global.d.ts { "/Users/drewbitt/Documents/Repos/web/apps/switch/src/polyfills.ts": [], "/Users/drewbitt/Documents/Repos/web/apps/auth-web/src/utils/auth.utils.ts": [], } ❯ time opencode debug lsp diagnostics apps/snow-web/src/global.d.ts { "/Users/drewbitt/Documents/Repos/web/apps/switch/src/polyfills.ts": [], "/Users/drewbitt/Documents/Repos/web/apps/auth-web/src/utils/auth.utils.ts": [], "/Users/drewbitt/Documents/Repos/web/tools/snowdrop/src/generators/api/createApi.ts": [ { range: [Object ...], message: "'node' is declared but its value is never read.", severity: 4, code: 6133, source: "typescript", } ], "/Users/drewbitt/Documents/Repos/web/apps/portal-web/src/polyfills.ts": [], "/Users/drewbitt/Documents/Repos/web/tools/generators/graphql/src/generators/export/schema.d.ts": [], "/Users/drewbitt/Documents/Repos/web/apps/sr/sr-public/src/environments/environment.ts": [], } real 16.08s user 0.90s sys 2.16s ❯ time opencode debug lsp diagnostics apps/snow-web/src/global.d.ts {} real 6.01s user 0.51s sys 2.74s ```
Author
Owner

@drewbitt commented on GitHub (Jul 9, 2025):

Back to just {} in v0.2.14

ERROR 2025-07-09T15:48:35 +4373ms service=lsp error=Error: Operation timed out after 5000ms
INFO  2025-07-09T15:48:35 +258ms service=lsp initialized
{}
INFO  2025-07-09T15:48:35 +0ms service=app name=lsp shutdown
@drewbitt commented on GitHub (Jul 9, 2025): Back to just `{}` in v0.2.14 ``` ERROR 2025-07-09T15:48:35 +4373ms service=lsp error=Error: Operation timed out after 5000ms INFO 2025-07-09T15:48:35 +258ms service=lsp initialized {} INFO 2025-07-09T15:48:35 +0ms service=app name=lsp shutdown ```
Author
Owner

@drewbitt commented on GitHub (Jul 14, 2025):

Still no luck. The solution for TUI coding is probably to start TSServer at the beginning of launching opencode and then using the existing process to query for files so that there is no expectation for it to launch in under 3 seconds.

@drewbitt commented on GitHub (Jul 14, 2025): Still no luck. The solution for TUI coding is probably to start TSServer at the beginning of launching `opencode` and then using the existing process to query for files so that there is no expectation for it to launch in under 3 seconds.
Author
Owner

@jacob-waldrip commented on GitHub (Jul 15, 2025):

I see the same thing on v0.3.9, suspected it when it never seemed to have any context that it caused an error. Put a couple errors in a file to test, results (tested both absolute and relative paths):

> opencode debug lsp diagnostics path/to/file.tsx
> {}

It doesn't look like opening the TUI triggers the language server to load judging by active processes (which I'm sure is a fair design choice, though possibly a configurable one). When launching a large TS project in neovim, it takes roughly 20 seconds for my LSP to spin up and attach for reference.

@jacob-waldrip commented on GitHub (Jul 15, 2025): I see the same thing on v0.3.9, suspected it when it never seemed to have any context that it caused an error. Put a couple errors in a file to test, results (tested both absolute and relative paths): ``` > opencode debug lsp diagnostics path/to/file.tsx > {} ``` It doesn't look like opening the TUI triggers the language server to load judging by active processes (which I'm sure is a fair design choice, though possibly a configurable one). When launching a large TS project in neovim, it takes roughly 20 seconds for my LSP to spin up and attach for reference.
Author
Owner

@thdxr commented on GitHub (Jul 16, 2025):

can i see --print-logs

@thdxr commented on GitHub (Jul 16, 2025): can i see `--print-logs`
Author
Owner

@jacob-waldrip commented on GitHub (Jul 16, 2025):

Here they are on my end @thdxr (on version 0.3.16) (put 2 errors in appointments.resolver.ts prior to launching opencode)

❯ opencode debug lsp diagnostics commons/server/graphql/domain/appointments/resolvers/appointments.resolver.ts --print-logs

INFO  2025-07-16T19:33:13 +43ms service=app cwd=/Users/jacob.waldrip/Development/commons creating
INFO  2025-07-16T19:33:13 +0ms service=default version=0.3.16 args=debug,lsp,diagnostics,commons/server/graphql/domain/appointments/resolvers/appointments.resolver.ts,--print-logs opencode
INFO  2025-07-16T19:33:13 +0ms service=app cwd=/Users/jacob.waldrip/Development/commons creating
INFO  2025-07-16T19:33:13 +1ms service=app git=/Users/jacob.waldrip/Development/commons git
INFO  2025-07-16T19:33:13 +0ms service=app git=/Users/jacob.waldrip/Development/commons git
INFO  2025-07-16T19:33:13 +3ms service=app name=config registering service
INFO  2025-07-16T19:33:13 +1ms service=bus type=storage.write subscribing
INFO  2025-07-16T19:33:13 +0ms service=app name=bus registering service
INFO  2025-07-16T19:33:13 +0ms service=format init
INFO  2025-07-16T19:33:13 +0ms service=bus type=file.edited subscribing
INFO  2025-07-16T19:33:13 +0ms service=config.hooks init
INFO  2025-07-16T19:33:13 +0ms service=bus type=file.edited subscribing
INFO  2025-07-16T19:33:13 +0ms service=bus type=session.idle subscribing
INFO  2025-07-16T19:33:13 +0ms service=app name=lsp registering service
INFO  2025-07-16T19:33:13 +4ms service=lsp.client serverID=typescript starting client
INFO  2025-07-16T19:33:13 +1ms service=lsp.client serverID=typescript sending initialize
INFO  2025-07-16T19:33:13 +2ms service=config $schema=https://opencode.ai/config.json instructions=.cursor/rules/*.mdc username=jacob.waldrip loaded
INFO  2025-07-16T19:33:13 +344ms service=lsp.client serverID=typescript initialized
INFO  2025-07-16T19:33:13 +0ms service=lsp.client serverID=typescript path=/Users/jacob.waldrip/Development/commons/commons/server/graphql/domain/appointments/resolvers/appointments.resolver.ts waiting for diagnostics
INFO  2025-07-16T19:33:13 +0ms service=bus type=lsp.client.diagnostics subscribing
INFO  2025-07-16T19:33:13 +1ms service=lsp.client serverID=typescript path=/Users/jacob.waldrip/Development/commons/commons/server/graphql/domain/appointments/resolvers/appointments.resolver.ts textDocument/didOpen
INFO  2025-07-16T19:33:14 +428ms service=lsp.client serverID=typescript token=a3d8ba93-284d-4301-b917-66cba69e6ef0 window/workDoneProgress/create
INFO  2025-07-16T19:33:16 +2573ms service=bus type=lsp.client.diagnostics unsubscribing
{}
INFO  2025-07-16T19:33:16 +0ms service=app name=lsp shutdown
INFO  2025-07-16T19:33:16 +0ms service=lsp.client serverID=typescript shutting down
INFO  2025-07-16T19:33:16 +1ms service=lsp.client serverID=typescript shutdown
@jacob-waldrip commented on GitHub (Jul 16, 2025): Here they are on my end @thdxr (on version 0.3.16) (put 2 errors in `appointments.resolver.ts` prior to launching opencode) ```bash ❯ opencode debug lsp diagnostics commons/server/graphql/domain/appointments/resolvers/appointments.resolver.ts --print-logs INFO 2025-07-16T19:33:13 +43ms service=app cwd=/Users/jacob.waldrip/Development/commons creating INFO 2025-07-16T19:33:13 +0ms service=default version=0.3.16 args=debug,lsp,diagnostics,commons/server/graphql/domain/appointments/resolvers/appointments.resolver.ts,--print-logs opencode INFO 2025-07-16T19:33:13 +0ms service=app cwd=/Users/jacob.waldrip/Development/commons creating INFO 2025-07-16T19:33:13 +1ms service=app git=/Users/jacob.waldrip/Development/commons git INFO 2025-07-16T19:33:13 +0ms service=app git=/Users/jacob.waldrip/Development/commons git INFO 2025-07-16T19:33:13 +3ms service=app name=config registering service INFO 2025-07-16T19:33:13 +1ms service=bus type=storage.write subscribing INFO 2025-07-16T19:33:13 +0ms service=app name=bus registering service INFO 2025-07-16T19:33:13 +0ms service=format init INFO 2025-07-16T19:33:13 +0ms service=bus type=file.edited subscribing INFO 2025-07-16T19:33:13 +0ms service=config.hooks init INFO 2025-07-16T19:33:13 +0ms service=bus type=file.edited subscribing INFO 2025-07-16T19:33:13 +0ms service=bus type=session.idle subscribing INFO 2025-07-16T19:33:13 +0ms service=app name=lsp registering service INFO 2025-07-16T19:33:13 +4ms service=lsp.client serverID=typescript starting client INFO 2025-07-16T19:33:13 +1ms service=lsp.client serverID=typescript sending initialize INFO 2025-07-16T19:33:13 +2ms service=config $schema=https://opencode.ai/config.json instructions=.cursor/rules/*.mdc username=jacob.waldrip loaded INFO 2025-07-16T19:33:13 +344ms service=lsp.client serverID=typescript initialized INFO 2025-07-16T19:33:13 +0ms service=lsp.client serverID=typescript path=/Users/jacob.waldrip/Development/commons/commons/server/graphql/domain/appointments/resolvers/appointments.resolver.ts waiting for diagnostics INFO 2025-07-16T19:33:13 +0ms service=bus type=lsp.client.diagnostics subscribing INFO 2025-07-16T19:33:13 +1ms service=lsp.client serverID=typescript path=/Users/jacob.waldrip/Development/commons/commons/server/graphql/domain/appointments/resolvers/appointments.resolver.ts textDocument/didOpen INFO 2025-07-16T19:33:14 +428ms service=lsp.client serverID=typescript token=a3d8ba93-284d-4301-b917-66cba69e6ef0 window/workDoneProgress/create INFO 2025-07-16T19:33:16 +2573ms service=bus type=lsp.client.diagnostics unsubscribing {} INFO 2025-07-16T19:33:16 +0ms service=app name=lsp shutdown INFO 2025-07-16T19:33:16 +0ms service=lsp.client serverID=typescript shutting down INFO 2025-07-16T19:33:16 +1ms service=lsp.client serverID=typescript shutdown ```
Author
Owner

@thdxr commented on GitHub (Jul 16, 2025):

so once the lsp is started, opencode only waits 3s when asking for file diagnostics before it gives up and moves on. can see there it's timing out. the LSP server stays running so it might finish initializing later and start providing values

when using opencode normally the LSP won't spawn until the first time a file it can handle is read - we used to proactively spawn LSPs before but that had some other issues

need to think about this more

@thdxr commented on GitHub (Jul 16, 2025): so once the lsp is started, opencode only waits 3s when asking for file diagnostics before it gives up and moves on. can see there it's timing out. the LSP server stays running so it might finish initializing later and start providing values<br><br>when using opencode normally the LSP won't spawn until the first time a file it can handle is read - we used to proactively spawn LSPs before but that had some other issues<br><br>need to think about this more
Author
Owner

@jacob-waldrip commented on GitHub (Jul 16, 2025):

Let me know if I can be of any help from here, thanks for taking a look.

@jacob-waldrip commented on GitHub (Jul 16, 2025): Let me know if I can be of any help from here, thanks for taking a look.
Author
Owner

@m1yon commented on GitHub (Nov 14, 2025):

This is still an issue I'm running into. It doesn't matter how many times I run opencode debug lsp diagnostics test.ts in a row, it always returns {} even though there are TS errors in the file.

Has anyone found a work around for this?

@m1yon commented on GitHub (Nov 14, 2025): This is still an issue I'm running into. It doesn't matter how many times I run `opencode debug lsp diagnostics test.ts` in a row, it always returns `{}` even though there are TS errors in the file. Has anyone found a work around for this?
Author
Owner

@rekram1-node commented on GitHub (Nov 14, 2025):

@m1yon can you tell me more about your project? Perhaps it is older and the ts server opencode used is too new or something?

@rekram1-node commented on GitHub (Nov 14, 2025): @m1yon can you tell me more about your project? Perhaps it is older and the ts server opencode used is too new or something?
Author
Owner

@m1yon commented on GitHub (Nov 14, 2025):

@m1yon can you tell me more about your project? Perhaps it is older and the ts server opencode used is too new or something?

Thanks for the quick reply! Here are some details about the project:

  • It's a large Next.js project.
  • I'm using bun for package management.
  • The TypeScript version is "typescript": "^5.8.3"
  • I do not have a global TypeScript version or tsserver installed

Here's the tsconfig.json:

{
  "ts-node": {
    "compilerOptions": {
      "module": "commonjs",
      "esModuleInterop": true,
      "allowSyntheticDefaultImports": true
    }
  },
  "compilerOptions": {
    "lib": ["dom", "dom.iterable", "esnext"],
    "allowJs": true,
    "skipLibCheck": true,
    "strict": true,
    "noEmit": true,
    "esModuleInterop": true,
    "module": "esnext",
    "moduleResolution": "bundler",
    "verbatimModuleSyntax": false,
    "resolveJsonModule": true,
    "isolatedModules": true,
    "allowImportingTsExtensions": true,
    "jsx": "react-jsx",
    "incremental": true,
    "plugins": [
      {
        "name": "next"
      }
    ],
    "types": ["bun-types"],
    "paths": {
      "@/*": ["./src/*"],
      "@infrastructure/*": ["./src/infrastructure/*"],
      "@domain/*": ["./src/domain/*"],
      "@clerk/*": ["./src/infrastructure/clerk/*"],
      "@payload-config": ["./src/payload.config.ts"],
      "@emails/*": ["./emails/*"],
      "@test-config/*": ["./test-config/*"],
      "@test-utils/*": ["./test-utils/*"]
    },
    "target": "ES2017"
  },
  "include": [
    "next-env.d.ts",
    "**/*.ts",
    "**/*.tsx",
    ".next/types/**/*.ts",
    ".next/dev/types/**/*.ts"
  ],
  "exclude": [
    "node_modules",
    "scripts",
    "src/infrastructure/healthie/generated"
  ]
}

What I've tried:

  • I've tried adding a .ts file to the root src folder with a basic TS error, but the opencode debug lsp diagnostics {file} command return {} after a few seconds.
  • I created an empty project with a the same TS file, and the opencode debug lsp diagnostics actually returned the correct diagnostics. This makes me believe it's the size of the project.
@m1yon commented on GitHub (Nov 14, 2025): > [@m1yon](https://github.com/m1yon) can you tell me more about your project? Perhaps it is older and the ts server opencode used is too new or something? Thanks for the quick reply! Here are some details about the project: - It's a large Next.js project. - I'm using bun for package management. - The TypeScript version is `"typescript": "^5.8.3"` - I do not have a global TypeScript version or tsserver installed Here's the `tsconfig.json`: ```json { "ts-node": { "compilerOptions": { "module": "commonjs", "esModuleInterop": true, "allowSyntheticDefaultImports": true } }, "compilerOptions": { "lib": ["dom", "dom.iterable", "esnext"], "allowJs": true, "skipLibCheck": true, "strict": true, "noEmit": true, "esModuleInterop": true, "module": "esnext", "moduleResolution": "bundler", "verbatimModuleSyntax": false, "resolveJsonModule": true, "isolatedModules": true, "allowImportingTsExtensions": true, "jsx": "react-jsx", "incremental": true, "plugins": [ { "name": "next" } ], "types": ["bun-types"], "paths": { "@/*": ["./src/*"], "@infrastructure/*": ["./src/infrastructure/*"], "@domain/*": ["./src/domain/*"], "@clerk/*": ["./src/infrastructure/clerk/*"], "@payload-config": ["./src/payload.config.ts"], "@emails/*": ["./emails/*"], "@test-config/*": ["./test-config/*"], "@test-utils/*": ["./test-utils/*"] }, "target": "ES2017" }, "include": [ "next-env.d.ts", "**/*.ts", "**/*.tsx", ".next/types/**/*.ts", ".next/dev/types/**/*.ts" ], "exclude": [ "node_modules", "scripts", "src/infrastructure/healthie/generated" ] } ``` --- What I've tried: - I've tried adding a `.ts` file to the root `src` folder with a basic TS error, but the `opencode debug lsp diagnostics {file}` command return `{}` after a few seconds. - I created an empty project with a the same TS file, and the `opencode debug lsp diagnostics` actually returned the correct diagnostics. This makes me believe it's the size of the project.
Author
Owner

@rekram1-node commented on GitHub (Nov 16, 2025):

I think the command itself may have a bug, I know the lsp works in opencode project but the diagnostics command returns nada, I think for some reason it takes 2 touches to get diagnostics back and that's prolly a bug in our code

@rekram1-node commented on GitHub (Nov 16, 2025): I think the command itself may have a bug, I know the lsp works in `opencode` project but the diagnostics command returns nada, I think for some reason it takes 2 touches to get diagnostics back and that's prolly a bug in our code
Author
Owner

@m1yon commented on GitHub (Nov 18, 2025):

I think the command itself may have a bug, I know the lsp works in opencode project but the diagnostics command returns nada, I think for some reason it takes 2 touches to get diagnostics back and that's prolly a bug in our code

I do see a significant quality drop when using opencode in large TS projects. It will add code to files without adding the required imports, miss closing braces/brackets, many TS diagnostics errors that the edit tool should be returning. It'll finish the task without catching these obvious errors, unless I tell it to run tsc afterward, but that slows the feedback loop.

I mostly use kimi k2 via zen.

Our large TS project uses libraries like convex, which have crazy type inference that slows down the LSP much more than a typical TS project.

@m1yon commented on GitHub (Nov 18, 2025): > I think the command itself may have a bug, I know the lsp works in `opencode` project but the diagnostics command returns nada, I think for some reason it takes 2 touches to get diagnostics back and that's prolly a bug in our code I do see a significant quality drop when using opencode in large TS projects. It will add code to files without adding the required imports, miss closing braces/brackets, many TS diagnostics errors that the edit tool should be returning. It'll finish the task without catching these obvious errors, unless I tell it to run `tsc` afterward, but that slows the feedback loop. I mostly use `kimi k2` via zen. Our large TS project uses libraries like [convex](https://www.convex.dev/), which have crazy type inference that slows down the LSP much more than a typical TS project.
Author
Owner

@rekram1-node commented on GitHub (Nov 18, 2025):

ah that can definitely do it, we do timeouts on lsp feedback so there is a chance it is always taking more than 5 seconds

@rekram1-node commented on GitHub (Nov 18, 2025): ah that can definitely do it, we do timeouts on lsp feedback so there is a chance it is always taking more than 5 seconds
Author
Owner

@rekram1-node commented on GitHub (Nov 18, 2025):

assuming ur project is closed source right otherwise Id try to play with it

I could prolly find something oss that uses convex tho, ig convex itself maybe haha

@rekram1-node commented on GitHub (Nov 18, 2025): assuming ur project is closed source right otherwise Id try to play with it I could prolly find something oss that uses convex tho, ig convex itself maybe haha
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#536