-
Notifications
You must be signed in to change notification settings - Fork 149
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Support IntelliSense autocomplete for valid registries when using import map specifiers #752
Comments
@jsejcksn do you still experience this problem with Deno v1.35? I believe this has been fixed. |
@bartlomieju Sure: I'll budget some time today to test and report back here. |
@bartlomieju It now appears that autocompletion doesn't work at all with import map specifiers (except for modules that have been resolved in the same language server session?) I recorded a screen capture of a basic test (attached to the bottom of this message), and here's text output of the files and software versions:
gh_vscode_deno_752.mov |
@dsherret could you take a look here? |
I would like to see IntelliSense autocompletion for imports from valid registries when those registries have been mapped to arbitrary specifiers using an import map.
I'm aware that this issue is being tracked in the CLI repo in regard to LSP support at this issue. I'm creating an issue here in this repo specifically for tracking behavior about the extension in VS Code, and to document the current behavior (below).
I have an example directory structure like this:
If I open the directory as a workspace in VS Code, and then open the file
main.ts
in an editor tab, and begin to type an import statement which uses the full URL for the standard library specifier in the import map, I get IntelliSense autocompletions. Here's a screenshot example to illustrate:However, If I try to use the import map specifier for the same registry, the IntelliSense does not provide autocompletions beyond the specifier itself. It is aware that the mapped specifier exists:
But doesn't provide any further suggestions:
Further observations:
If I type out the complete path for a valid module in the registry using the literal URL, the module is cached as soon as I stop typing, without even needing to save the file:
But when using the import map specifier path to a module, I get a diagnostic signal (red wavy underlines) with conflicting information in the quick info box — it states that the dependency is resolved, but also that it is uncached or missing:
I must manually save the file and invoke the palette command "Deno: Cache Dependencies" in order to resolve the diagnostic issue:
I would, of course, like to see this behavior for
export
statements as well.Related:
export
statements deno#16805The text was updated successfully, but these errors were encountered: