back
169 comments
Not sure if Bun has had an influence on this, these features must have been in development for a long time, but the timing surely is impeccable.

npm compatibility is huge for Deno. It is basically the one major drawback to Deno, which gets hopefully fixed with this feature. It also looks like this compatibility layer is implemented transparently in the existing module management, which is a big bonus. Nobody wants to deal with node_modules anymore when working with Deno for an extended period, just love to see this.

If you deep dive into bun, it only has the gained performance for certain features and cant really even be compared to deno or node at the moment because it lacks so many other features that would better showcase its speed.
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

Core features for npm compatibility though (like implementing most of the npm api, including require(), and its special globals) has been making progress for a long time.

There is even a near complete project to support Node's native api (which bun also supports): https://github.com/denoland/deno/pull/13633

Relative to the the existing node compat efforts, the url import (and accompanying package download code) will be fairly small. The most difficult part is probably the extra stuff that node throws in the global namespace. How to handle that without having to pollute the global namespace for all programs (even those that do not import from node) is unclear.

Ideally these globals would be visible only from code in modules imported from npm. But the spec does not really allow for this unless the npm code is loaded in a different realm, but cross realm code causes a lot of headaches, which could only be avoided by having the realms share most globals and intrinsics (and sharing intrisics is not allowed by the spec).

There may be some other way to hack this into working, or perhaps programs with such imports that actually use NPM specific objects will need to be run with the "--compat" flag. It is really unclear at the moment.

Heh, I commented in that post from yesterday how Bun looked more promising longer term to me than Deno, even though it wasn't production ready yet: https://news.ycombinator.com/item?id=32460658

Like you said, don't know if Bun had an influence on the timing of this announcement, but great to see innovation in the JS server space. Kudos to both the Deno and Bun folks!

My guess is they were planning on announcing these things sometime in the next couple of months, but then Bun showed up on HN, so they moved up the blog post.
"We aren't optimizing for a handful of edge cases, but for overall real world performance" seemed indirectly a call out to Bun.
Deno's progress on NPM compatibility may have accelerated due to how BunJS was received, but yes I believe this idea has been baking for a while in the Deno world. It was always somewhat of a concern when Deno was launched, but the team was just more focused on delivering a solid core product before they started worrying about the ancillary tasks. After all, you can always use the various Deno-friendly CDNs to use a Deno-compatible package distributed over NPM.

BunJS does of course have a slightly different use case, packages or apps that still need to make use of Node APIs. I can see a future where we say "if you have an old Node app, you can run it on BunJS with a codemod and get an X% perf boost for free", as well as "if you are starting a new project, just go with Deno because there's less BS to think about".

I think it has more to do with the money they raised and communicating some path towards wider adoption.

Don't personally know anyone who is treating Bun as anything more than a curiosity.

Npm is the main thing I dislike about Node though. I hope compatibility is a feature meant for easing transitions, not something the general user base should be embracing.
I imagine yes, bun put pressure on to launch node package compatibility.

Any thoughts on speed reliability concerns comparing the two?

Their comments about the performance were definitely a consequence of Bun's release.
It's the drawback but also the problem.

NPM is a giant pain point, and I suggest that Deno and a lot of other people want to move on from it.

But the gravity is just too much.

I'm actually a little disappointed by NPM compatibility. Or at least conflicted. Deno has felt like an opportunity to reboot the server-side JS ecosystem into something far more sensible than it currently is. Not that anyone is to blame for what it is, really, but you learn lessons and move forward. Sometimes making breaking changes.

This seems like an acceptance that moving on simply won't happen. The existing ecosystem is too big and too powerful to be ignored. If I were a particularly cynical person I'd also point to Deno taking on millions in VC funding - once you've done that you can't be content to create a perfect, gleaming sandbox. You have to bring in money.

As a non-user of Deno, I’m curious, how do people tend to manage dependency version centralisation in Deno? I suppose this will apply to existing Deno as well as npm imports. I can just see you ending up having to change “import express from "npm:express@5";” from 5 to 6 in lots of places when the next major version comes out.

When contemplating how I might do it, I came up with centralised reexport, a file deps.ts containing:

  export express from "npm:express@5";
This would basically stand in for the dependencies object in package.json.

So then I looked up the docs and found https://deno.land/manual/linking_to_external_code#it-seems-u... and was amused to find the same solution, even down to the file name “deps.ts”!

Is this how people tend to work with Deno?

I see it also supports import maps, https://deno.land/manual/linking_to_external_code/import_map..., which could readily solve the problem too. Do people use that?

This isn't entirely fair to Deno but it always amazes me how people start out with "we don't need packages! Just do direct imports" and eventually end up with "okay fine fine here's a package manager". Packages are great! Don't dismiss them just because in edgecases they're bad.

In fairness, the two examples, Deno and Go, are successful projects, so maybe it's not a bad initial strategy.

Wow, very interested in an npm compatible Deno! I think that will remove a huge barrier to entry for Deno and could mark a huge shift towards usage in production.

I'm very interested in how packages will manage runtime support in the future. Right now we are seeing an explosion of JavaScript runtimes from Cloudflare Workers to Bun, all with sightly different APIs. I wonder if there will be an easy way to get cross-runtime support without it being much extra work for library authors.

Right now, there has already been conflict with some packages being browser-only and some being node-only. I feel like there needs to be a better solution than the one we have now.

So we've come full circle. From the talk of author on how "NPM was a big mistake", to "Nobody is adopting it, we will die without the NPM ecosystem". I was hoping that Deno will spin off into something that can be compiled due to type system hints into something more optimized than JS, but seems like I was just living in dystopian utopia.
> import express from "npm:express@5";

> There will be no node_modules folder, no npm install; the packages will be automatically downloaded in the Deno cache.

My understanding of deno's package system (see https://deno.land/manual/linking_to_external_code#it-seems-u...), is that basically, at compile time it will go and fetch external URLs and cache those files locally. So this change basically makes it so your import:

> import { assert } from "https://deno.land/std@0.152.0/testing/asserts.ts";

Is magically generated from npm when you do this instead:

> import { assert } from "npm:testing@2.0.1";

Ok cool. Whatever.

...surely this isn't the actual problem?

There seem to be certain pretty fundamental problems:

- not all npm packages are typescript

- a package is not just an 'assert.ts' file, it's often an amalgamation (eg. using rollup)

- a package often has many dependencies

- a package may use the node API, that deno doesn't have (it has a more-or-less compatibility mode, see 'differences that cannot be overcome' -> https://deno.land/manual/node)

So bluntly, how on earth is this going to work?

I mean, I'm a fan, the folk working on Deno are smart and motivated, and if it works, I'm more 'wow' than 'I don't believe it'... but I'm very surprised to see:

> the vast majority of npm packages work in Deno within the next three months

That seems... ambitious.

I can't see how the approach is really sustainable, given that basically, it means 'anything node supports we have to support to'; doesn't that mean you're forever playing catchup and 'doesn't quite work'?

How is vendoring going to work without a package lock file? Doesn't this just mean you've reimplemented npm and you'll forever be playing catchup to the various npm features that are required to make packages work?

The NPM thing is a huuuuge deal. This has been by far the biggest thing holding Deno back, but it was tough because one of Deno's most exciting benefits was standardizing the module system and ditching NPM. It looks like they may have found a best-of-both-worlds solution for shoehorning NPM's massive ecosystem into Deno while it's still building out its own. Big changes indeed.

That, and the emphasis on speed (esp quotes like "We aren't optimizing for a handful of edge cases, but for overall real world performance") makes me wonder if Bun is lighting a fire under them a bit. It's still a long way from catching up, but it's been closing the gap at a blistering pace and getting enormous amounts of hype. The more competition the better.

Exciting times

This might sound odd, but: one thing I've wanted to do is use the Typescript compiler without using NPM. (I'm not smart enough to know why I hate NPM. I just want a tool that compiles TS.)

It almost sounds like I could write a self-contained deno command-line "app" that does this. Does that seem right (for those that know better)?

I've been using Deno in production at work for a while, and NPM compatibility is the one thing dragging me back to Node, some packages like Elasticsearch simply won't work in Deno, if they solve that I'll be throwing a party for all HN where we collectively remove Node from all my development workspaces.
> We've been working on some updates that will allow Deno to easily import npm packages and make the vast majority of npm packages work in Deno within the next three months.

This is really huge and will be a huge boost to the Deno ecosystem. On the other hand, I quite enjoyed that it wasn't jacked into NPM. There were reasonable alternatives like https://jspm.org/. This is a big swing at Node and I'll be watching with maximum curiosity.

As an aside, the only thing preventing me from adopting Deno as my daily driver has been the lack of AWS Lambda support (requiring a lambda layer, slowing down cold starts). Would be great if they could leverage connections and advocate for native AWS support.

Demo is awesome, and the npm compatibility is a game changer. Isn’t this the 3rd http server rewrite in less than a year though? They didn’t mention it being backwards compatible. I guess they needed to change the underlying server to support features in Fresh. This is one downside of the team making the core platform as well as many of the main components of the ecosystem… they can evolve the runtime to suit their vision even if it affects competitor’s implementations.
I have a limited experience using NodeJs. My first interaction with Node was unpleasant. The whole npm world seemed very insecure and very wide wide west like, thinking back I can't remember why I felt that now. I know the article said some would like to get away from the npm. For those who still would like to use npm with Deno, I would love to know why. (I'm genuinely curious, not looking to start a flame war)
Will Deno’s approach to NPM compatibility support peer dependencies? https://nodejs.org/en/blog/npm/peer-dependencies/

Furthermore, will it support unifying transitive dependency versions to minimize bundle sizes?

I hope we figure out a better way to deal with the mountain of dead (and just plain bad) packages on NPM. Not carrying this legacy always sounded like a plus to me, but I haven't used Deno in production yet.

It's also interesting to note how the tone changes after receiving funding. May just be a coincidence, but this looks like a reactionary jab back at Bun, which is barely out of the gate.

> import express from "npm:express@5";

I'm excited to see this, and I'm sure they'll work this out, but I sure hope I don't have to keep dependency versions in sync across all of my import statements. I don't have much love for package.json and node_modules, but it is nice to have one source-of-truth for all the dependencies of a project.

It would be nice if they included a compat flag for importing without this special syntax. As it stands, there is no clear drop-in replacement path for Deno, and as a result, I have no interest in using it.

I'm not rewriting my work so someone can have fun playing with VC money and abandon mature software.

I wish there is more clarity about package dependency will be resolved from Deno?

Supporting npm is one big step forward, but without a package-lock.json that locks all child dependencies, it’d be a nightmare using the new compatibility in production

That Bun pressure though!
This is pleasing to see - no node_modules, no npm install. Just a special import format.

They are not clear if you need to have npm installed or not for this to work. I sincerely hope not - if it requires a locally-installed npm then they've shat the bed I think... that would be a major turn-off for me.

Can't say I've ever been concerned by the performance of Deno, but looking forward to seeing this playout anyway since faster is always nice to have.

>Deno to easily import npm packages and make 80-90% of npm packages work in Deno within the next three months.

I get it, I understand it, but it is depressing to know that we're going to be dealing with horribly ridden legacy NPM code for the next 800 years.

A lot of the code on NPM is just bad. And now we're going to keep this legacy of just, bad JavaScript .

This is why I prefer dart and flutter for making mobile apps. Over react native.

People ITT mention Bun but I'm sure performance was always in the mind of Ryan et al. They were probably too busy with other stuff though.
> We know there's been a lot of chatter recently about runtime speed.

For reference: https://news.ycombinator.com/item?id=32457587

Btw, I like where it's going but I find it quite sad that there is no official linux ARM64 support yet - which means I can't try to use it on AWS lambda for example.

If we really care about performance, then this split between the runtime and user code is not ideal. What we should be trying to do is bake the user code into the runtime and apply total program optimization. This can be done today with C, C++ and Rust. However, in principle JavaScript code could be transpiled to Zig and then baked into Deno.
Deno + Coffeescript? I mean it runs Typescript natively, so why not my favorite flavor of javascript, too? https://github.com/jashkenas/coffeescript/issues/5150
Does something like patch-package: https://www.npmjs.com/package/patch-package exists for Deno? If yes/no how does it work/would work?
> ...make 80-90% of npm packages work in Deno...

Can this really be right? What is the number for Nodejs?

This chips away at one of the showstoppers for Deno for me, which is good.

But while "the vast majority" of npm packages don't require a gyp build step for native addons, some of those modules are pretty important, and I see no indication in the announcement that they're also going to be implementing the Node C API or the gyp build process.

Right now I'm working with a machine learning project, and XGBoost [0] is a direct Node.js extension [1] through the binary interface.

So this does bring things a step closer to being generally usable, but there are still significant roadblocks.

A WebAssembly build of XGBoost could work with Deno, but aside from some guy's unsupported side project/proof-of-concept for use in a browser, I'm not seeing an XGBoost WebAssembly build. And generally when deploying something like a machine learning model I'd rather use well-supported tools than to need to dive into the rabbit hole of maintaining my own.

And yes, XGBoost will likely eventually have that kind of support for Deno, but then the next bleeding-edge project will come along and only support Node.

Even assuming Deno eventually hits a tipping point in popularity where everyone wants to release Node _and_ Deno support in their bleeding-edge projects, there are still things that I miss from package.json that don't seem to exist in the Deno ecosystem.

Things like the "scripts" block: A nice centralized place to find all of the things that need to be done to a project, plus auto-run script entries that can trigger when a project is installed. And inheritable, overridable dependency maps (see the yarn "resolutions" block).

I'd love to jump into Deno, but I think there has been far too much "baby thrown out with the bathwater" to its design. It's the classic development problem of looking at a system and seeing a ton of complexity, but not really understanding that all of that complexity was there for a reason. Maybe when it re-evolves 80% of Node's and npm's features I'll be convinced to make the jump. I'm a huge TypeScript fan after all. But it still strikes me as a violation of "As simple as possible, but no simpler."

[0] XGBoost is a _very_ promising approach to machine learning, training models much faster and with much more accuracy than traditional approaches.

[1] https://github.com/nuanio/xgboost-node

And both Deno and Bun still rely on HTTPS imports which is a nonstarter. It's a security and availability minefield.

I still don't understand why they have this feature and still consider themselves security focused.

> “… will allow Deno to easily import npm packages and make 80-90% of npm packages …”

Do we know what will differentiate the 10-20% of packages that won’t work?

NPM compatibility is probably the most important thing currently holding up people from adopting deno so this is pretty significant
Looks like Deno took notice of Bun https://bun.sh/
> 80-90% of npm packages work in Deno within the next three months.

curious what kind of npm packages won't be supported in Deno

AsyncLocalStorage support (https://github.com/denoland/deno/issues/7010; essentially thread local storage) pretty pretty please?
awwwwhhhh snap! this can really open the runtime up
> the next release of Deno will include a new HTTP server. It is the fastest JavaScript web server ever built.

I feel unease reading untestable claims (with no numbers) about future releases. I'm made more uneasy by the fact that this is the second bullet point of the main tl;dr. It makes me wonder, what are the organizational incentives driving such a publication?