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.<p>npm compatibility is <i>huge</i> 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.
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.<p>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.<p>When contemplating how <i>I</i> might do it, I came up with centralised reexport, a file deps.ts containing:<p><pre><code> export express from "npm:express@5";
</code></pre>
This would basically stand in for the dependencies object in package.json.<p>So then I looked up the docs and found <a href="https://deno.land/manual/linking_to_external_code#it-seems-unwieldy-to-import-urls-everywhere" rel="nofollow">https://deno.land/manual/linking_to_external_code#it-seems-u...</a> and was amused to find the same solution, even down to the file name “deps.ts”!<p>Is this how people tend to work with Deno?<p>I see it also supports import maps, <a href="https://deno.land/manual/linking_to_external_code/import_maps" rel="nofollow">https://deno.land/manual/linking_to_external_code/import_map...</a>, 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.<p>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.<p>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.<p>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";<p>> There will be no node_modules folder, no npm install; the packages will be automatically downloaded in the Deno cache.<p>My understanding of deno's package system (see <a href="https://deno.land/manual/linking_to_external_code#it-seems-unwieldy-to-import-urls-everywhere" rel="nofollow">https://deno.land/manual/linking_to_external_code#it-seems-u...</a>), 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:<p>> import { assert } from "<a href="https://deno.land/std@0.152.0/testing/asserts.ts";" rel="nofollow">https://deno.land/std@0.152.0/testing/asserts.ts";</a><p>Is magically generated from npm when you do this instead:<p>> import { assert } from "npm:testing@2.0.1";<p>Ok cool. Whatever.<p>...surely this isn't the actual problem?<p>There seem to be certain pretty fundamental problems:<p>- not all npm packages are typescript<p>- a package is not just an 'assert.ts' file, it's often an amalgamation (eg. using rollup)<p>- a package often has many dependencies<p>- 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' -> <a href="https://deno.land/manual/node" rel="nofollow">https://deno.land/manual/node</a>)<p>So bluntly, how on earth is this going to work?<p>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:<p>> the vast majority of npm packages work in Deno within the next three months<p>That seems... ambitious.<p>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'?<p>How is vendoring going to work <i>without</i> 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 <i>benefits</i> 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.<p>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.<p>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.)<p>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.<p>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 <a href="https://jspm.org/" rel="nofollow">https://jspm.org/</a>. This is a big swing at Node and I'll be watching with maximum curiosity.<p>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? <a href="https://nodejs.org/en/blog/npm/peer-dependencies/" rel="nofollow">https://nodejs.org/en/blog/npm/peer-dependencies/</a><p>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.<p>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";<p>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.<p>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?<p>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
This is pleasing to see - no node_modules, no npm install. Just a special import format.<p>They are not clear if you need to have npm <i>installed</i> 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.<p>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.<p>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.<p>A lot of the code on NPM is just bad. And now we're going to keep this legacy of just, bad JavaScript .<p>This is why I prefer dart and flutter for making mobile apps. Over react native.
> We know there's been a lot of chatter recently about runtime speed.<p>For reference:
<a href="https://news.ycombinator.com/item?id=32457587" rel="nofollow">https://news.ycombinator.com/item?id=32457587</a><p>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, <i>in principle</i> 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?
<a href="https://github.com/jashkenas/coffeescript/issues/5150" rel="nofollow">https://github.com/jashkenas/coffeescript/issues/5150</a>
Does something like patch-package: <a href="https://www.npmjs.com/package/patch-package" rel="nofollow">https://www.npmjs.com/package/patch-package</a> exists for Deno? If yes/no how does it work/would work?
This chips away at one of the showstoppers for Deno for me, which is good.<p>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.<p>Right now I'm working with a machine learning project, and XGBoost [0] is a direct Node.js extension [1] through the binary interface.<p>So this does bring things a step closer to being generally usable, but there are still significant roadblocks.<p>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.<p>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.<p>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.<p>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).<p>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."<p>[0] XGBoost is a _very_ promising approach to machine learning, training models much faster and with much more accuracy than traditional approaches.<p>[1] <a href="https://github.com/nuanio/xgboost-node" rel="nofollow">https://github.com/nuanio/xgboost-node</a>
And both Deno and Bun still rely on HTTPS imports which is a nonstarter. It's a security and availability minefield.<p>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 …”<p>Do we know what will differentiate the 10-20% of packages that won’t work?
> the next release of Deno will include a new HTTP server. It is the fastest JavaScript web server ever built.<p>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?