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.

> Seems like the core of these issues was a Claude-coauthored PR: https://github.com/denoland/deno/pull/33208

Disclaimer: I'm the author of the linked PR. Using AI here is not really at fault here - it was just a giant rewrite that replaced how we do `node:http` in Deno. Replacing the engine while driving is never easy and we did the best we could. While we have a lot of test coverage and we use tests directly from Node.js codebase, we just don't catch everything. We're constantly working on improving the situation and I'm sorry you hit a problem. I can assure you that we are fixing all Node compat bugs as quickly as possible.

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.

Thanks for feedback, I opened a PR to implement linking functionality that seems more familiar to npm's strategy: https://github.com/denoland/deno/pull/34359

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

Hi, Bartek from the Deno team here. We are actively looking into improving this situation and from initial investigations we were able to shave off roughly 40% of the baseline size, with more improvements possible in the future. Stay tuned for upcoming releases.

Bartek from the Deno team here. You can also use `package.json` and bare specifiers with Deno. We also recently added `--unstable-byonm` flag (Bring Your Own Node Modules) that allows you to manage `node_modules/` be the package manager of your choice. In other words, you should be able to drop Deno into an existing Node project.

Bartek from the Deno team here. We are working on making this possible with a flag in the upcoming release.

A couple months back we added an ability for Deno to run projects authored for Node.js directly.

Eg. if you have a Vite app (or any other app really) with "package.json" and some "scripts" defined there, just try running "deno task <script_name>". Deno will automatically pick up "package.json" and try its best to run the that script.

It's not fully done, but in our testing we got a lot of non-trivial projects running that way. If something doesn't work in your case, I would greatly appreciate a bug report to help us fix this.

As for the written guide - there's not a single one at the moment - it's something we'll be looking into in the coming months.

Bartek from the Deno team here. Sorry to hear that - we made great progress in making Deno drop-in replacement this year, but we certainly are not yet there 100%.

I'd love to hear what problems did you hit and look into solving them.

Just to clarify - we do have support for node_modules/ resolution (with all of its quirks and gotchas), otherwise we wouldn't be able to load npm packages. However we made a hard stance that CommonJS is only supported in npm dependencies and cannot be used in user code (ie. you must use ESM in your application code).

Bartek from the Deno team here, let me clarify a few things.

> for one the security model is incompatible with node APIs.

All Node.js APIs are polyfilled using Deno APIs and as such these Node.js API are subject to the same permission model as regular Deno programs.

> however if deno were to support all npm packages, it would necessarily basically have to implement the entire node api, including support for pre async/await (aka callbacks)

We're not aiming for 100% compatibility, though we managed to polyfill a hefty amount of built-in Node modules, including ones that are callback based.

> consider just the c++ embedder apis. how exactly would deno deal with that with respect to permissions?

This is the same situation as with Deno's FFI API. You need to pass `--allow-ffi` flag to enable usage of `Deno.dlopen` (or `require("./foo.node")` for N-API extensions). That said when you load dynamic libraries all bets are off - we can't control what the dynamic library can do and you effectively open up your whole system. Still, you can't load such libraries unless `--allow-ffi` flag is passed.

Hope this clears up some things.

These modules can be included but currently there's no way to use them - that's because they need to be present on disk to load them as dynamic libraries.

We're debating how to best tackle that. If you have a specific use case in mind I would appreciate opening a feature request in our issue tracker.

It's another issue, but it's close

Bartek from the Deno team here. We're currently missing polyfills for IPC module to be able to use `next dev` command.

Thanks! This should be fixed now.

You should be good to go after reading through the Rust book [0] and watching this video [1]

[0] https://doc.rust-lang.org/book/ [1] https://www.youtube.com/watch?v=8aGhZQkoFbQ

Hey, I'm the author of this blog post.

Just yesterday we posted a second part of this post [0] where we add "fetch"-like API and TypeScript transpilation.

Happy to answer your questions.

[0] https://deno.com/blog/roll-your-own-javascript-runtime-pt2

> The "npm:" import does not appear to have even started development, although it has been planned for a long time: https://github.com/denoland/deno/issues/13703

The development is well under way, we expect to ship first iteration of this feature in the next release (v1.25) in the coming weeks.

Yes, this effort started years ago and was ramped up significantly in recent months.