I haven't used Deno, but I do use Bun purely as a replacement for npm. It does the hard-linking thing that seems to be increasingly common for package managers these days (i.e. it populates your local node_modules with a bunch of hard links to its systemwide cache), which makes it vastly quicker and more disk-efficient than npm for most usage.

Even with a cold cache, `bun install` with a large-ish dependency graph is significantly faster than `npm install` in my experience.

I don't know if Deno does that, but some googling for "deno install performance vs npm install" doesn't turn up much, so I suspect not?

As a runtime, though, I have no opinion. I did test it against Node, but for my use case (build tooling for web projects) it didn't make a noticeable difference, so I decided to stick with Node.

▲

WorldMaker 3 hours ago | parent | next [-]

Deno does that. It also refrains from keeping a local node_modules at all until/unless you explicitly ask it to for whatever compatibility reason. There are plugins to things like esbuild to use the Deno resolver and not need a node_modules at all (if you aren't also using the Deno-provided bundler for whatever reason such as it disappeared for a couple versions and is still marked "experimental").

▲

satvikpendem 5 hours ago | parent | prev | next [-]

Deno does all that. Hell, yarn does too, or pnpm as the sibling mentioned.

	▲	FINDarkside 2 hours ago \| parent [-]
		Sure, but pnpm is very slow compared to bun.

▲

homebrewer 5 hours ago | parent | prev | next [-]

pnpm does all that on top of node. Also disables postinstall scripts by default, making the recent security incidents we've seen a non-issue.

▲

junon 3 hours ago | parent | next [-]

As the victim of the larger pre-Shai-Hulud attack, unfortunately the install script validation wouldn't have protected you. Also, if you already have an infected package on the whitelist, a new infection in the install script will still affect you.

▲

antihero 5 hours ago | parent | prev | next [-]

I’m not sure why but bun still feels snappier.

	▲	B56b 4 hours ago \| parent \| next [-]
		This is why: https://bun.com/blog/behind-the-scenes-of-bun-install
	▲	babyshake 4 hours ago \| parent \| prev [-]
		Aside from speed, what would the major selling points be on migrating from pnpm to bun?

▲

daheza 4 hours ago | parent | prev [-]

Are there any popular packages that require postinstall scripts that this hurts?

▲

agumonkey 4 hours ago | parent | prev | next [-]

IIRC bun zig code base has a lot of fine optimization too. I think the lead did a conference explaining his work. Or maybe i'm confused.

▲

dolmen 27 minutes ago | parent [-]

https://bun.com/blog/behind-the-scenes-of-bun-install

	▲	agumonkey 14 minutes ago \| parent [-]
		oh thanks yes, i couldn't find it, i was already lost thinking it was a conference by andrew kelley .. thanks a lot

▲

user34283 24 minutes ago | parent | prev [-]

I decided to stick with Node in general. I don't see any compelling reason to change it.

Faster install and less disk space due to hardlink? Not really all that important to me. Npm comes with a cache too, and I have the disk space. I don't need it to be faster.

With the old-school setup I can easily manually edit something in node_modules to quickly test a change.

No more node_modules? It was a cool idea when yarn 2 initially implemented it, but at the end of the day I prefer things to just work rather than debug what is and isn't broken by the new resolver. At the time my DevOps team also wasn't too excited about me proposing to put the dependencies into git for the zero-install.