Package Phobia - ⚖️ Find the cost of adding a new dependency to your project


(Steven) #1

I created a tool, Package Phobia, because there is no way to know how much disk space npm install some-new-package is going to use. Not all packages are created equal: some might be a single file and others might be massive frameworks.

It’s easy to let your dependencies get out of control and not know it, so Package Phobia is just one more tool you can use to evaluate a package.

There are also links to other tools that let you see:

  • which files are published to npm
  • which packages are dependencies of your dependencies
  • and of course, npm, which shows download history and other metrics

Check out Package Phobia today! https://packagephobia.now.sh


(Kat Marchán) #3

(Kat Marchán) #4

(note: I see no point in having topics here auto close. I’ve reopened this and changed the settings)


(Steven) #5

@zkat I just saw that libnpm exists and I’m wondering if I can use that as an alternative to npm install <somepackage>? Is this possible?


(Kat Marchán) #6

It’s too low level for that


(David A Ball) #7

@styfle Digging into your inquiry about libnpm. The alternative to npm install <package_name> you are looking for is in the package pacote. It does that exact thing, you just have to specify the directory yourself. Generally, it’s @ ~/node_modules in your project home, but you’ll need to specify the path to it.

But I feel you. I am starting to really reconsider every single dependency. Not so much for the disk space. But really mostly due to trust. Hackers making it hard to trust open-source to be reliable lately. I would like a graphical view of my full dependency tree for every project and be able to drill down to the source code. There have just been so many strange things happening lately in open-source. Projects can shut down. Projects can be injected with cryptocurrency wallet stealing code. Like I’m really just wondering why I run node on my dev machine at all, except for VS Code and Atom. Even then there’s the same kind of risks. I wonder if we can somehow put restrictions on what the node application permissions are, if not now then later. Giving hackers keys to the kingdom makes me a little nauseous. But I didn’t own any crypto when the nodemon thing happened so it’s just my empathy I guess.


(Steven) #8

That could work, but pacote doesn’t walk the tree so I would need to re-implement npm de-duping logic and that sounds messy and error prone.

This is what I tried:

const pacote = require('pacote');
const name = 'webpack';
const dest = './pkgsize';

pacote.manifest(name).then(pkg => {
    pacote.extract(pkg._resolved, dest).then(() => {
        console.log(`remote tarball contents extracted to ${dest}`)
    })
})

This reports a significantly smaller size than https://packagephobia.now.sh/result?p=webpack


(Steven) #9

There is a node-like tool called deno that has opt-in flags for write access and network access. Maybe one day it will become stable and everything will be read-only by default.


(David A Ball) #10

Is it the same version? I can’t speak for pacote, only that it’s documentation claims it works like npm install. You might check and see if yarn has a better API. I might later.


(David A Ball) #11

Even reading is a threat, depends on what you’re reading really, but read only mode isn’t good enough either. It’s really an OS issue I guess. Like why should a process be given the same privileges as a user (other than it was designed that way)? It should be like a Venn diagram containing the intersection of two sets, one circle representing user rights and the other process rights, the intersection is further limited. I mean I could create a node user and limit running it to it’s home directory, and that may be my best option to really try to isolate the permissions. The OS gives me permission, the user, and I should be giving my apps permission as a user. Anything else is not good enough. It would be great to see ACLs implemented in this way at the OS level.