@divybot Update PR desc, how does this fix the issue?

Updated the PR description with a summary, the mechanism of the fix, and the regression tests covering it.

Have you looked at the discussion in the issue? Can you try to reproduce it

Yes. I read through #28681 and cloned the linked repro (aliak00/deno-monorepo). The concrete setup is:

• multi-root workspace: shared, backend, web, and root
• workspace-level deno.enable: false
• backend folder has deno.enable: true
• backend deno.json uses an import map where core/ points to ../../shared/ts/core/src/

I verified the command-line part matches the issue: from apps/backend, /usr/bin/deno check src/run.ts succeeds. The LSP bug this PR addresses is that workspace preload would stop at disabled ancestor dirs like apps/, so it would not reach apps/backend/deno.json in this multi-root disabled-root setup.

I pushed e65233b to make the regression tests mirror that repro shape more closely: shared, backend, web, and root workspace folders, only backend enabled, and backend importing core/ through an import map. Focused verification passed locally:

cargo test -p deno --lib nested_workspace --features rustls/ring
# 2 passed

Have you tried e2e using lsp? I wanna see perf numbers before and after

I ran an e2e LSP measurement against the linked repro (aliak00/deno-monorepo) with two locally built debug binaries:

• before: 19da4cbe8 (parent of the fix)
• after: e65233bcc (current PR head)

Method:

• started deno lsp over stdio
• initialized with the repro workspace folders: shared, backend, web, root
• answered workspace/configuration with workspace-level/root/shared/web deno.enable: false, backend deno.enable: true, and backend import map
• enabled deno.internalDebug and parsed LSP performance measures from stderr
• opened apps/backend/src/run.ts with the issue's bad return-value edit
• requested deno:/status.md and textDocument/diagnostic
• one warm-up per binary, then 5 measured warm runs with the same DENO_DIR

Results, medians from 5 warm runs:

Interpretation: before is faster to ready because it is wrong for this repro: it preloads zero server docs and never reaches the enabled backend workspace through the disabled root. After loads the expected backend workspace files (deno.json, import_map.json, src/run.ts) and still reaches ready in ~373ms median on a debug build. The per-open path is comparable/slightly better in this run (lsp.did_open 3.74ms after vs 4.11ms before).

Caveat: in this isolated e2e run the diagnostic request reports npm-install-related diagnostics for zod, so I used this primarily to verify LSP workspace discovery and preload/cache perf rather than the final semantic diagnostic shape.