React helmet async breaking in 1.44.3 about deno HOT 6 CLOSED

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
  }
}

from deno.

CC @nayeemrmn please take a look

from deno.

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.

from deno.

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.

from deno.

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.

from deno.

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.

from deno.