In case it is relevant, here is my .vscode/settings.json file.

{
  "deno.enable": true,
  "deno.lint": true,
  "deno.unstable": false,
  "deno.config": "./deno.jsonc",
  "deno.suggest.imports.hosts": {
    "https://deno.land": true
  },
  "files.associations": {
    "*.css": "tailwindcss"
  },
  "editor.formatOnSave": true,
  "editor.defaultFormatter": "denoland.vscode-deno",
  "editor.quickSuggestions": {
    "strings": true
  }
}

CC @nayeemrmn please take a look

I just checked out the latest commit 67dcd6d for the other issue I linked to. I've verified that it doesn't resolve this issue. I used the following command: deno upgrade --canary --version 67dcd6db518446574d3a1e33f4ce536fcdc4fd25 to check it out then reloaded my window.

I'm going to stick with 1.44.2 until this issue is resolved.

I reproduced this, it's because the react-helmet-async package as used here is depending on the import map entry for react, but the scope tracking I wrote for remote libs doesn't work for globally cached npm packages (it would work if you had "nodeModulesDir": true). Looking into it.

I reproduced this, it's because the react-helmet-async package as used here is depending on the import map entry for react, but the scope tracking I wrote for remote libs doesn't work for globally cached npm packages (it would work if you had "nodeModulesDir": true). Looking into it.

Should I have that enabled if I am using npm packages via npm specifiers? Just asking because I'm not sure the reasons to or not to use the nodeModulesDir setting.

You should use it if you find that a package you're using depends on node_modules being there, and doesn't work otherwise. In this case though it's a mendable regression in the LSP.