bartlomieju's comments

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.

N-API will be supported in future releases of Deno, we have a PR going that is close to completion.

That's not really what's happening behind the scenes.

We are consuming sources as they are provided in npm using "compat layer" that is part of Deno's standard library. We had to provide special module resolution, but besides polyfill for built-in Node APIs, it works very similar to how Node consumes these packages.

New server API is modelled after API available in "std/http/server.ts", so for most folks it should be a drop in replacement.

"compat" mode has been supported for some months now: https://deno.land/manual/node/compatibility_mode