Hacker News Reader

Comment by segphault | Hacker News Reader

The install footprint from npm is 302 packages weighing in at 504mb. It includes a lot of superfluous debris, with packages containing single functions like "is-string" and multiple polyfills for functions like object.assign. That's a very large attack surface considering the poor security practices in the npm ecosystem[0] and the growing frequency of attacks on transitive dependencies[1].

[0]: https://www.bleepingcomputer.com/news/security/52-percent-of... [1]: https://news.ycombinator.com/item?id=28962168

View on HN

A huge bet we're placing on our Rust compiler is that we'll control the supply chain much more tightly. The core infrastructure of the project will ship as an architecture-optimized binary (for local dev) or WebAssembly (for browser dev).

In the process, we're being careful and empathetic about the incremental upgrade paths and ecosystem compatibility, so we're shipping a number of packages that'll completely disappear in the future.

You'll see us drop a ton of deps and weight in the short term. Watch this space. Thanks for your feedback, I'm on the same page.

How do you review a WebAssembly binary? Are builds reproducible? I just found this about Rust: https://github.com/rust-lang/rust/labels/A-reproducibility

It would be nice to be able to run them on multiple CIs and compare the SHAs.

> A huge bet we're placing on our Rust compiler is that we'll control the supply chain much more tightly.

This is great to hear, thanks for responding. I'm looking forward to seeing the Next.js dependency story improve in the future as you are able to complete that migration to swc. And hopefully Vercel's leadership in this space also encourages similar improvements in the broader node and react ecosystems.

Keeping in mind that these are generally build-time/server-side dependencies, not client-side dependencies, so size-on-disk isn't a very relevant metric

That seems beside OP's point.

They are speaking of the potential bugs and security vulnerabilities all that code might/probably has, given track records.

They mentioned "weighing in at 504mb", so clarification seemed warranted

Have you ran it in production install mode, because my app dockerfile (using alpine base) isn't even that big total.

I wonder why they don't replace these simple packages like `is-string` with Lodash, which has all these functions and more.

Bundle size isn't a problem: they're ES modules, so you can do something like `lodash/isString` and import only what you need.

Seems like that would cut down on a lot of dependencies. I'm curious why the ecosystem hasn't adopted this or a similar approach.

Also tree shaking out the stuff you don’t need has never worked better. It’s pretty trivial with lodash.

They're probably dependencies of dependencies. You depend on some very useful package and somewhere down the line it depends on something written to be platform agnostic in 2012 when lodash wasn't modular and JavaScript wasn't as mature. The ecoystem hasn't adopted a better approach because it would require every individual package developer to understand the problem, get on board, then update and test everything they've written.

> I wonder why they don't replace these simple packages like `is-string` with Lodash...

As someone who maintains a few dozen packages (public and otherwise), lodash has wasted more of my time than any other - due to its frequent security issues. It was almost always lodash, and I would have to update a dozen packages everytime.

Things may have improved; I no longer use lodash anywhere.

That kind of undisciplined rot is unfortunately widely accepted in the Javascript community.

Reply on news.ycombinator.com