6 ms·

> Vendoring dependencies is a simple way to ensure consistent build inputs If consistent build inputs is your concern may I ask why using lock files wasn’t eno

> Vendoring dependencies is a simple way to ensure consistent build inputs If consistent build inputs is your concern may I ask why using lock files wasn’t enough? That’s a problem they were designed to solve.

dtgriscom 5y ago
npm has long had a problem respecting lock files. The concept is easy: have a fixed lock file, get a reproducible build. But no: npm will change your lock file (I believe it's framed as "optimizing") without notice. (Perhaps they've solved this in the last couple of years. I've been staying away from that ecosystem... too much growing in it...)
- kevincox 5y ago
  I think the trick is that you should use `npm ci` instead of `npm install` in most cases.
smarx007 5y ago
It says so in the post, in case another left-pad removal happens.
- aniforprez 5y ago
  Not that I'm a fan but didn't npm resolve that problem right after? You can't yank entire packages anymore 24 hours after they're published
  - smarx007 5y ago
    Yes, you are right. But there are people who trust npm (now and esp. in the future) and other free infrastructure and there are those who prefer to be a bit more self reliant after getting burned once.
onei 5y ago
I use vendoring in Go because my team's builds happen within a huge, complicated corporate network that has been known to break arbitrarily in new and interesting ways (or rather when something gets changed unexpectedly and then it takes days/weeks to navigate outsourced IT and change it back). Vendoring deps doesn't save me all the time, but I've generally found it helps. Plus builds are a bit quicker because I can download everything in one go (via git clone) rather than pulling everything in at build time. It also helps when the linter decides it wants all the dependencies downloaded before doing anything and then we find it has a relatively short timeout when the network gains a lot of latency without notice. On reflection, it seems more like I'm papering over network issues. Perks of working in an enterprise company I guess.
cxr 5y ago
Onus confusion strikes again <https://news.ycombinator.com/item?id=29276656 https://news.ycombinator.com/item?id=29276656>. The (mediocre) tooling for lockfiles isn't bedrock. In a discussion about Skub, no one need to explain why the Skub-powered approach isn't good enough. It is the duty of anyone pushing Skub to explain exactly what makes Skub so special to the point that we need to have Skub in our lives.

dtgriscom 5y ago

npm has long had a problem respecting lock files. The concept is easy: have a fixed lock file, get a reproducible build. But no: npm will change your lock file (I believe it's framed as "optimizing") without notice. (Perhaps they've solved this in the last couple of years. I've been staying away from that ecosystem... too much growing in it...)

kevincox 5y ago
I think the trick is that you should use `npm ci` instead of `npm install` in most cases.

smarx007 5y ago

It says so in the post, in case another left-pad removal happens.

aniforprez 5y ago
Not that I'm a fan but didn't npm resolve that problem right after? You can't yank entire packages anymore 24 hours after they're published
- smarx007 5y ago
  Yes, you are right. But there are people who trust npm (now and esp. in the future) and other free infrastructure and there are those who prefer to be a bit more self reliant after getting burned once.

onei 5y ago

I use vendoring in Go because my team's builds happen within a huge, complicated corporate network that has been known to break arbitrarily in new and interesting ways (or rather when something gets changed unexpectedly and then it takes days/weeks to navigate outsourced IT and change it back). Vendoring deps doesn't save me all the time, but I've generally found it helps. Plus builds are a bit quicker because I can download everything in one go (via git clone) rather than pulling everything in at build time. It also helps when the linter decides it wants all the dependencies downloaded before doing anything and then we find it has a relatively short timeout when the network gains a lot of latency without notice. On reflection, it seems more like I'm papering over network issues. Perks of working in an enterprise company I guess.

cxr 5y ago

Onus confusion strikes again <https://news.ycombinator.com/item?id=29276656 https://news.ycombinator.com/item?id=29276656>. The (mediocre) tooling for lockfiles isn't bedrock. In a discussion about Skub, no one need to explain why the Skub-powered approach isn't good enough. It is the duty of anyone pushing Skub to explain exactly what makes Skub so special to the point that we need to have Skub in our lives.