auto-import for `std` modules

[scarf005]

this is a smaller-scoped request for #1069

being able to get import assist for std modules would be helpful.

according to https://docs.deno.com/runtime/manual/advanced/language_server/imports, following endpoints seem to provide module entries:

https://apiland.deno.dev/completions/items/std/0.218.2/

https://apiland.deno.dev/completions/items/std/0.218.2/collections

_Originally posted by @scarf005 in https://github.com/denoland/vscode_deno/issues/1069#issuecomment-1981077417_

[nayeemrmn]

@scarf005 It looked like #1069 was about exported symbols. Were you talking about files? This is already implemented: you need to add the following to your vscode settings:

{
  "deno.suggest.imports.hosts": {
    "https://deno.land": true
  }
}

jsr:@std/... supports this without configuration.

[scarf005]

It looked like https://github.com/denoland/vscode_deno/issues/1069 was about exported symbols. Were you talking about files?

I was referring to symbols.

e.g I have to explicitly 'cache' https://deno.land/std/collections/map_values.ts to be able to import mapValues from there.

This is already implemented: you need to add the following to your vscode settings:

this doesn't work; i've already added the settings, yet in above screenshot it wouldn't suggest importing https://deno.land/std/collections/map_values.ts or https://deno.land/std/collections/mod.ts to be able to use mapValues.

[nayeemrmn]

Okay I understand, the apiland link was a response to the last thing I said in https://github.com/denoland/vscode_deno/issues/1069#issuecomment-1981046332.

We can add a setting to preload select remote libs into the ts server so their auto-imports are always available. However, at this point we would only do that for jsr or npm specifiers. With these in Deno, it's no longer worth developing package sniffing infrastructure for arbitrary or favoured https URLs. e.g.:

{
  "deno.preloadPackages": [
    "jsr:@std/path", // Preload all exports in `jsr:@std/path@0.219.0`.
    "jsr:@std/fs/.", // Preload only the default export in `jsr:@std/fs@0.219.0`.
    "jsr:@std/fs/expand-glob", // Preload only the `expand-glob` export in `jsr:@std/fs@0.219.0`.
    "npm:preact" // Preload whatever paths and exports are included in the type declarations for `npm:preact@10.19.3`.
  ]
}

[scarf005]

However, at this point we would only do that for jsr or npm specifiers. With these in Deno, it's no longer worth developing package sniffing infrastructure for arbitrary or favoured https URLs.

i disagree.

1. jsr: ornpm: specifiers cause vendor lock-in (namely, deno). only URLs are free of vendor lock-in.
2. there's already existing package sniffing infrastructure (apiland), so it makes more sense to provide preloadPackages for http than jsr.