What node version do you have installed? I cannot reproduce the issue on that repo, I've tried with node versions all the way back to node 12.

here's a dump of the console:

```

catapart@snake:~/Development/magnitce-code-example$ deno install

Warning The following packages are deprecated:

┖─ npm:[email protected] (Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.)

catapart@snake:~/Development/magnitce-code-example$ deno task dev

Task dev vite

You are using Node.js 20.11.1. Vite requires Node.js version 20.19+ or 22.12+. Please upgrade your Node.js version. error: Uncaught (in promise) SyntaxError: The requested module 'node:util' does not provide an export named 'parseEnv' at file:///home/catapart/Development/magnitce-code-example/node_modules/.deno/[email protected]/node_modules/vite/dist/node/chunks/node.js:11:46

    at async CAC.<anonymous> (file:///home/catapart/Development/magnitce-code-example/node_modules/.deno/[email protected]/node_modules/vite/dist/node/cli.js:706:27)

```

also: I'm using Linux Mint, if it matters.

Okay I traced it, the problem is in `node_modules/vite/dist/node/cli.js`:

``` function checkNodeVersion(nodeVersion) { const major = parseInt(nodeVersion.split(".")[0], 10); const minor = parseInt(nodeVersion.split(".")[1], 10); return (major === 20 && minor >= 19) || (major === 22 && minor >= 12) || major > 22; } if (!checkNodeVersion(process.versions.node)) console.warn(`You are using Node.js ${process.versions.node}. Vite requires Node.js version 20.19+ or 22.12+. Please upgrade your Node.js version.`); ```

And that error should be thrown only in Deno < 2.2 which presented `process.version` as `20.11.1`.

Are you 100% sure this is not running some old version of Deno on your system?

you nailed it! I tried it on a different machine, just to be sure, and it worked without a problem. So then I did a full restart on the mint machine and I got a whole new error that was talking about missing files. So I uninstalled deno and reinstalled it, and it worked exactly like it did on the other machine.

I actually started this after another user said they couldn't reproduce the issue, but you figured it out before I finished reporting back.

Thanks for straightening me out on this! As I said a few days ago on the Deno Desktop HN Topic, I'm looking forward to this newest version!

I don't think it's that complicated, in my mind it's as simple as the fact that the npm/node ecosystem is huge and not supporting it at all means having to reinvent each and every library that exists there. That is a huge task and in my experience, the lack of support for npm/node packages (used to) really hamper deno's usefulness.

Now you can tap into the npm ecosystem when needed, but still use deno-first libraries as you please. If you don't like npm, then you can ignore it entirely

But that’s exactly what I’m saying, a big selling point WAS reinventing things. There would be a stdlib “http” package for all HTTP client needs, an “orm” package, and so on. This is how I remember Deno being sold many years ago, and I thought it was a noble cause.

> If you don't like npm, then you can ignore it entirely

But what if Deno had invested all that Node compat effort into something else?

Jsdom should work in deno, can you open a github issue (https://github.com/denoland/deno/issues) with some details and a reproduction?

All of the simple cases I've tried seem to work fine, e.g:

  import { JSDOM } from "npm:jsdom";
  
  const dom = new JSDOM(
    `<!DOCTYPE html><p>Hello world <img src="https://example.com/logo.svg" /></p>`,
  );
  
  console.log(dom.window.document?.querySelector("p")?.textContent); // "Hello world"
  console.log(dom.window.document?.querySelector("img")?.getAttribute("src")); // "https://example.com/logo.svg"

Earlier today, it was producing an error that looked as if it couldn't render some elements. Unfortunately, I switched to a different branch where I tried to switch certain things over to Node, and now when I've switched back, there's a different error, now in the `readability` module, but still connected to its use of jsdom. It looks like it could be due to version mismatches — maybe readability requires a different version of JSDOM to the one installed by default — but now I'm trying to downgrade the currently installed version of JSDOM, and that doesn't seem to work — the version in deno.lock is stubbornly staying at the later version, despite having specified an older version in the `deno.jsonc` (and that older version appearing in the `workspace.dependencies` array at the bottom of the lock file).

I'll try again with a clearer head tomorrow, and maybe if I figure stuff out I can create a proper reproduction, but right now I don't know how to reproduce anything because it doesn't seem like my local environment is consistently reproducible, let alone trying to create something that would work on other machines. I'm surprised at how poor this behaviour is — I thought a big part of Deno@2 was to fix these sorts of dependency issues.