React helmet async breaking in 1.44.3

[KyleJune]

Version: Deno 1.44.3

I have the following import.

import reactHelmetAsync from "react-helmet-async";
const { HelmetProvider } = reactHelmetAsync;

Then when I try using the HelmetProvider as a react component, I get the following error.

In my deno.json, here is the most relevant imports entries.

"react": "npm:[email protected]",
"@types/react": "npm:@types/[email protected]",
"react-helmet-async": "npm:react-helmet-async@2",

I also tried changing the react version to be less specific (react@18) but that didn't resolve the issue.

And here are my compiler options.

"compilerOptions": {
  "lib": ["esnext", "dom", "dom.iterable", "dom.asynciterable", "deno.ns"],
  "jsx": "react-jsx",
  "jsxImportSource": "react",
  "jsxImportSourceTypes": "@types/react"
}

I don't have the issue in 1.44.2 but do in 1.44.3 and 1.44.4. I found #24293 when looking through the commits for the release that broke my code. It sounded like it might be related since the issue is with JSX. But I don't have multiple deno.json files.

I tried checking out each commit using deno upgrade --canary --version, I found the commit that introduces this issue I'm having is the same one for that other issue I linked to. So they seem to be related.

5dec3fd

[KyleJune]

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

[bartlomieju]

CC @nayeemrmn please take a look

[KyleJune]

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.

[nayeemrmn]

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.

[KyleJune]

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.

[nayeemrmn]

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.