randomUUID VS npmgraph

Embrace the people who want to help: The number of people who are willing to make meaningful contributions to a project is always shockingly low, even for popular projects, but they are out there. The key is to recognize them and empower them so they're willing to stick around and continue to help. When such people do turn up, get them on your team.

This looks a lot better than I expected.

One thing that bugs me about this (and Tailwind) is the number of dependencies they pull in. Panda has 152 nodes (239, if you count their dev-dependencies)[0].

Tailwind has 98 (594 if you count their dev-dependencies).

I know they're only dev-dependencies, but still... I've got all of that code running on my machine, just to process CSS. I really don't love it.

[0] https://npmgraph.js.org/?q=%40pandacss%2Fdev

This is what I came up with. I get 514. I got 496 here https://npmgraph.js.org/. I'm curious what you get using npm and/or yarn, or other tool.

For a real-world example, check out my npmgraph.js.org tool. It crawls a module's dependency tree on the fly, fetching the NPM registry info for each module. For a large dependency graph like the one for gatsby, on my 60 mbps connection the client completes 1,200+ requests (120MB of data) in about 10 seconds.

Why Array.isArray() when you can require("is-array").isArray()?

deep-equal has 43 packages that are mostly has-*, is-* packages (https://npmgraph.js.org/?q=deep-equal) and you’ll find this package included in a lot of upstream libraries.

The great irony of this post is that the author dreams of a world where they can use a library without it depending on hundreds of other modules, yet their website is built on Gatsby, an NPM package with one of the most insane dependency graphs I've seen. Uploading the author's website's package.json[1] into npmgraph[2] lists a total of 1561 dependencies. All that for what amounts to a simple blog site.

[1] https://github.com/poeti8/pouria.dev/blob/master/package.jso...

[2] https://npmgraph.js.org/

You can actually graph the horrible depencency tree of any package you want here: https://npmgraph.js.org/

> Postgres.js is also a zero dependency module, whereas Slonik has quite the dependency graph meaning - compare https://npmgraph.js.org/?q=slonik with https://npmgraph.js.org/?q=postgres.

This one just made my day. Thanks. I remember trying to build a tool at work with as little as possible dependencies (in python) and how satisfying it was to see quite a few dependencies just being wrappers replaces with 5 lines of my own code that i could easily audit and ensure no supply chain attack was possible for that functionality.

Dependency graph. The more dependencies a framework has, the larger the attack surface area. It can also make debugging issues in your applications much more difficult. You don’t need to find a framework with zero dependencies, but you should have some awareness of a framework’s dependency graph. The tool npmgraph can provide you with an excellent overview.

Recognize when you're the person holding the project back: This has happened to me a couple times now. When your interest in a project wanes, be deliberate about recognizing that. Focus what little energy you do have on recruiting people to help out (or even take over).