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.

Tuned I am, happy to hear this is getting attention. Improvements in this domain would also enable Deno to be a more serious contender in the App space opened up via https://github.com/webui-dev/deno-webui and others.

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.

Great to know!

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.

I don't recall but it felt like a distant goal at best.

Is there a written guide for how to convert a nodejs project to Deno?

I'd really prefer to be using deno instead of node. If it was a seamless experience I would definitely drop nodejs.

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.

I'll wait till there's a written guide then follow it.

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).

Until you try to build a TS project that imports an .mjs from node_modules that doesn't work right. Oh, set the project to type=module, nope, then other crap breaks. I mean, you can get it all working, but simple and easy are two words I would not use for modern node, especially when working with typescript.

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.

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

yeah, I'm aware of this. my point was that you couldn't 100% compatibility without compromising. fwiw it's a good thing. node can be a security nightmare if your team is not disciplined about dependencies.

w.r.t to node apis, technically you are like you say polyfilling them. and with that implementation differences hopefully allow you to continue to polyfill.

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

That's super exciting, can't wait to test it.

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