Cannot import npm specifier modules due to firewall

[justinmchase]

Describe the bug I cannot configure NPM_CONFIG_REGISTRY in the vscode extension.

https://deno.com/blog/v1.29#custom-registry-support-via-environment-variable

To Reproduce

1. Connect to a corporate VPN which blocks npm
2. Setup an Artifactory proxy
3. Attempt to import something with an npm specifier

   import * as express from "npm:express";

Expected behavior

I expect to be able to have this succeed by importing through the proxy.

I would imagine it could be as simple as adding an option npmRegistry to the settings which would set that env variable before invoking deno.

{
  "deno.npmRegistry": "<url>"
}

Screenshots

Versions

vscode: 1.67.2 deno: 1.32.4 extension: v3.17.0

[oscar6echo]

I reach a similar wall.

Config: vscode: 1.89.1, deno: 1.43.3, extension: 3.37.1

Behind a corp proxy I can use deno CLI with specific env variables:

• HTTP_PROXY, HTTPS_PROXY, NO_PROXY
• DENO_CERT to use certificates including corp ones

But vscode deno extension does not seem aware of proxy env variables. As a result remote links appear underlined in red wiggle and "Uncached or missing remote URL" on hover e.g.:

NOTE: Here they look ok as I write from outside corp env

An unfortunate consequence for dev exp is that all objects from these outside links are considered any which breaks type checks and forces to use // deno-lint-ignore no-explicit-any in the rest of the code.

On the other hand the certificate config can be set in .vscode/settings.json:

{
    "deno.enable": true,
    "deno.cache": ".cache",
    "deno.tlsCertificate": "/path/to/corp/ca-certificates.crt",
    "editor.formatOnSave": true,
    "editor.formatOnPaste": true,
    "[typescript]": {
        "editor.defaultFormatter": "denoland.vscode-deno"
    }
}

A surprising fact is that even if vscode proxy settings are explicitly set (in field below) this does not help vscode deno extension - as opposed to other extensions of vscode.

This limitation is a serious drag for deno use in a corp env I'm afraid.
Surely you know it already but just wanted to describe this problem precisely.

[nayeemrmn]

@oscar6echo I've checked that HTTP_PROXY and all other env vars are passed from the user's env to the language server (which handles module downloads) by the extension. How do you set the env vars, and have you tried clearing the cache?

[nayeemrmn]

@justinmchase Is it acceptable to set NPM_CONFIG_REGISTRY in your user profile before opening VSCode? That will be passed to the language server.

[justinmchase]

I'm pretty sure I do have it set that way but will check again and yeah it would be ok to pick it up that way in my case, since it's a machine global. But I could see someone still wanting a per repo setting.

[oscar6echo]

@oscar6echo I've checked that HTTP_PROXY and all other env vars are passed from the user's env to the language server (which handles module downloads) by the extension. How do you set the env vars, and have you tried clearing the cache?

What do you call user's env ? Do you mean the terminal from which to start VS Code ? If so, it may not apply in my case as I use VS Code remote SSH to connect to a machine. The doc warns about it, if I understand well. This is why I explicitly tried the HTTP(S)_PROXY env vars via VS Code settings (see last part of my comment , keeping in mind I could not screen shot the exact thing as I write from outside corp env - in particular the visual is a bit different for a remote host) but it did not work while it does for other extensions (tested).

Suggestion: the vscode_deno extension could read env vars from an env file passed in deno settings say (or similar):

{
  "deno.proxyEnvFile": "path/to/env/file.env"
}

This optional setting would override the current behavior - and be pleasantly explicit and easy to understand,
What do you think ?