10 ms·

You say that as packages never receive updates. Unless you’re doing a lot of installs every day (let’s say on CI), you’re suggesting it’s better to forcibly dow

You say that as packages never receive updates. Unless you’re doing a lot of installs every day (let’s say on CI), you’re suggesting it’s better to forcibly download a hundred megabytes of data daily just to potentially save a couple of megabytes once a week. There’s a smarter mechanism than that: npm already caches packages locally twice, both in node_modules and in a global location. In reality you’re probably never going to install every dependency from scratch every day, so you’re already using either cache on every install. What I’d like to see instead is a pre-resolution of packages done by the registry. I have a list of 30 dependencies, please resolve the tree and send it all over instead of forcing me to do a waterfall of fetches.

bhouston 3y ago
I was saying a dictionary trained on the top packages but not the size of them. I believe you can specify the size of the dictionary right? So you want to figure out when you have diminishing returns for average users. I figure an effective shared dictionary is anywhere from a few 100kb to a few MB. Where between those is optimal I don’t know. I am definitely not saying download 100MB to save a few MB per user. That is just dumb. I find NPM in the last year or so is faster to resolve that yarn. Although I think bun is even faster and may have better global caching.