discussion: multi registry import IntelliSense

We added support for IntelliSense autocomplete a week ago. It only has support for deno.land/x right now. I would like this feature to support more registries (like nest.land or jspm.dev). This is currently not practical to do because each registry requires a separate code path in the extension.

As a solution to this I propose a dynamic import IntelliSense that is not specific to any one registry. You should be able to dynamically add more registries without updates to the VS Code Deno extension.

How does this work for the user?

All registries that want to support this feature must host a /.well-known/deno-import-intellisense.json file on their domain (contents of this file are described below). The extension will request this file when it encounters a domain in an import statement for the first time. If the extension finds this file and recognizes the syntax, a popup is shown to the user:

Do you want to enable import IntelliSense for https://deno.land? Only do this if you trust https://deno.land.

Learn more

[No] [Yes]

If the user enables this, this domain will be added to an array of allowlisted domains in the deno.import_intellisense setting in VS Code user settings (override per project possible). If a domain is part of this allowlist, autocomplete for that domain will be enabled (how this works is described below).

How does this technically work?

When an import is found with a matching registry it is parsed according to the schema defined in /.well-known/deno-import-intellisense.json. Depending on where in the URL the cursor is, the correct auto complete should be triggered. The actual IntelliSense logic should be the same as the one we use now.

Schema of /.well-known/deno-import-intellisense.json

This is approximately what the schema could look like for https://deno.land:

{
  "version": 1,
  "registries": [
    {
      "schema": "/x/:module@:version/:path*",
      "variables": {
        "module": {
          "url": "https://api.deno.land/importintellisense/modules"
        },
        "version": {
          "url": "https://api.deno.land/importintellisense/modules/${module}"
        },
        "path": {
          "url": "https://api.deno.land/importintellisense/modules/${module}/versions/${version}"
        }
      }
    },
    {
      "schema": "/std@:version/:path*",
      "variables": {
        "version": {
          "url": "https://api.deno.land/importintellisense/modules/std"
        },
        "path": {
          "url": "https://api.deno.land/importintellisense/modules/std/versions/${{version}}"
        }
      }
    }
  ]
}

So what does this mean?

The file contains a list of registries under this domain, each with a url schema it containing variables. These variables have a specified URL endpoint that is used to request the information for auto complete. These urls can have replacement variables which will be populated with the extracted values from matched the URL schema. There are two types of replacement variables: ${} which inserts the literal value of the variable and ${{}} which inserts the URL encoded value of the variable. These URLs are expected to return an array of strings in JSON format when sent a HTTP GET request. They will cached (respecting the cache-control headers).

cc @kitsonk @t8 @CGQAQ @callionica @David-Else

[lucacasonato]

Q1. It’s not explicitly called out in the description, but the design calls for a block list as well as an allow list, right? So users could manually add domains to the block list to prevent any web requests including the web request for the well-known file?

SGTM - so a deno.import_intellisense_ignore setting.

Q2. How many requests for the well-known file will a domain that doesn’t provide the file see? Can domains enable tracking by not providing the file?

I would say we try max once every few days? A user can prevent this by adding the domain to the deno.import_intellisense_ignore setting.

Q3. If a user or organisation plans to use a single registry, can they use this system to enable autocomplete for that registry while still preventing all web requests to other locations (including the requests for the well-known file)?

What about a "deno.import_intellisense_discovery": false setting to disable the requests for the well-known file? It would be true by default. Users can still manually add registries via the deno.import_intellisense setting.

[kitsonk]

I like this a lot better. It allows users to add registries without modifying the code of the extension, and as important too, it doesn’t pick a horse in the race.