bartlomieju

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?

Sure, we also managed to close ~30 outstanding issues with this rewrite and set us up to reach ~90% node:http compatibility, so overall I consider it a success.

We tried to build `node:http` on top of Rust libraries (like Hyper) but we failed for a couple years. So earlier this year we decided to make it compatible (by using llhttp to have very high coverage - at the moment 88% compatibility for node:http module) and then focus on improving performance and slowly chipping away llhttp parts while keeping compatibility.

Gee, sorry to hear that. It's Bartek from the Deno team here. This is really a whack-a-mole. We currently present the latest stable Node.js version (26.3.0) so the error is not correct - I bet it's probing for something stupid like no of arguments a certain function supports. Is your project open source so I can take a look myself?

Bartek from Deno team hear. I'll love to hear what you feel is missing so we could improve `deno desktop` for more users.

Yes, you can do all that. You get a fully-fledged Deno program that can do all of this, _plus_ you get a frontend GUI app.

Bartek from the Deno team here. No promises yet, but we're looking into feasibility of it.

Sorry to hear that, could I ask you to file an issue in our bug tracker?

Thanks, I'll update the docs. When we wrote them a couple weeks back, Electrobun was announcing Linux only support.

Bartek from the Deno here. Nope, we do support enums OOTB.

Bartek from the Deno team here. Thanks for the feedback, I understand your frustration.

> The worst of the changes is "lib.node included by default", if I'm writing Deno or web code I absolutely don't want node types included by default.

Since a few versions ago, Deno now has some of Node.js APIs included by default (eg. process or Buffer). It's really more of a bug fix to make type-checking work properly.

While it's not ideal, you can still decide which types you want included by default with `compilerOptions.types`. `["deno.ns", "web"]` should give you what you're looking for.

Bartek from the Deno team here. Thanks for the feedback. I assure you this is not a short-sighted change. This has been a problem since before Deno 1.0. We resorted to hacks like different set of globals for user code and different for code inside node_modules/ directory. It was a maintenance headache, made global lookups super slow and was really hard to explain to users. While Web "setTimeout" might have been nice in the beginning the fact that it required additional APIs like "Deno.unrefTimer" made it worse than Node's setTimeout.

Bartek from the Deno team here - we are actively working on improving experience running NextJS projects in Deno.