deno

c1936645 - fix(lsp): honor `moduleResolution: "bundler"` for npm dir imports (#34643)

fix(lsp): honor `moduleResolution: "bundler"` for npm dir imports (#34643) ## Summary Fixes denoland/deno#33955. The LSP's `NodeResolver` was always constructed with `bundle_mode: false`, so importing a subpath of an npm package whose `package.json` doesn't list it under `exports` (e.g. `devextreme-react/text-box`) raised `[ERR_UNSUPPORTED_DIR_IMPORT]` even when the user had explicitly set `"moduleResolution": "bundler"` in `tsconfig.json` or `deno.json`. The TypeScript language service itself already routes such projects through `ts.ModuleResolutionKind.Bundler` (see `cli/tsc/98_lsp.js`), so the Rust-side resolver and tsserver disagreed about whether the import was valid. This wires the user's `compilerOptions.moduleResolution` through to the LSP's per-scope `NodeResolver`: - `NodeResolver::bundle_mode` becomes a runtime-settable `AtomicBool` exposed via `set_bundle_mode`. This sidesteps the existing circular dependency between `LspCompilerOptionsResolver` (which needs a node resolver to resolve tsconfig `extends`) and the node resolver (which now needs the compiler options). - After `LspCompilerOptionsResolver` is built, `LspResolver::set_compiler_options_resolver` iterates each scope's resolver and flips `bundle_mode` on whenever any compiler-options entry under that scope reports `CompilerOptionsModuleResolution::Bundler`. - Runtime / CLI behavior is unchanged — `cli/factory.rs` still only enables `bundle_mode` for `deno bundle`. ## Test plan - [ ] New `lsp_tsconfig_module_resolution_bundler_dir_import` integration test reproducing the issue: imports `some-pkg/text-box` (a directory without `exports`) and asserts the LSP emits no diagnostics when `moduleResolution: "bundler"` is set. - [ ] Existing LSP / node_resolver tests continue to pass. Closes denoland/divybot#369 --------- Co-authored-by: divybot <divybot@users.noreply.github.com> Co-authored-by: Divy Srivastava <me@littledivy.com>