From a1d823e27d1b605b5658fddc1c9273667f0e9e84 Mon Sep 17 00:00:00 2001 From: David Sherret Date: Fri, 1 Dec 2023 15:12:10 -0500 Subject: feat(compile): support discovering modules for more dynamic arguments (#21381) This PR causes Deno to include more files in the graph based on how a template literal looks that's provided to a dynamic import: ```ts const file = await import(`./dir/${expr}`); ``` In this case, it will search the `dir` directory and descendant directories for any .js/jsx/etc modules and include them in the graph. To opt out of this behaviour, move the template literal to a separate line: ```ts const specifier = `./dir/${expr}` const file = await import(specifier); ``` --- cli/lsp/documents.rs | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) (limited to 'cli/lsp') diff --git a/cli/lsp/documents.rs b/cli/lsp/documents.rs index ede063c5f..95e8df917 100644 --- a/cli/lsp/documents.rs +++ b/cli/lsp/documents.rs @@ -1743,12 +1743,17 @@ fn analyze_module( ) -> ModuleResult { match parsed_source_result { Ok(parsed_source) => Ok(deno_graph::parse_module_from_ast( - deno_graph::GraphKind::All, - specifier, - maybe_headers, - parsed_source, - Some(resolver), - Some(npm_resolver), + deno_graph::ParseModuleFromAstOptions { + graph_kind: deno_graph::GraphKind::All, + specifier, + maybe_headers, + parsed_source, + // use a null file system because there's no need to bother resolving + // dynamic imports like import(`./dir/${something}`) in the LSP + file_system: &deno_graph::source::NullFileSystem, + maybe_resolver: Some(resolver), + maybe_npm_resolver: Some(npm_resolver), + }, )), Err(err) => Err(deno_graph::ModuleGraphError::ModuleError( deno_graph::ModuleError::ParseErr(specifier.clone(), err.clone()), -- cgit v1.2.3