3 ms·
I run my startup on Go and react. The ease of upgrade process can't be further apart. We have our entire package.json locked down to the exact patch version be
by pxue 3y ago
I run my startup on Go and react. The ease of upgrade process can't be further apart.
We have our entire package.json locked down to the exact patch version because we've had issues where random patch upgrade kills the app, we run our own npm server because we can't trust dependency attacks in the js ecosystem. Just absolute pain.
Ten years of Go, I can count on one hand the times a dependency upgrade broke the build.
- 0xParlay 3y ago> we run our own npm server because we can't trust dependency attacks in the js ecosystem What does this mean? Your deps get locked down with sha1(?) checksum automatically after you install your packages (unless you go out of your way to delete the lock file). Must be a valuable startup you have for someone to attack your build with a hash collision..
- pxue 3y agoNo it's to mitigate "leftpad" style attack vector.
- 0xParlay 3y agoThen don't delete your lock-file and the vector doesn't exist? Rolling your own package management solution because understanding the existing tools is too hard.. That is peak "javascript sucks and I'm going to comment about it" energy lol.
- pxue 3y agoI'm not fully clear what you mean by don't delete lock file when the problem is the open source developer decides to unpublish their npm package
- sapiogram 3y agoI think this is more of frontend vs backend thing. I have a similar experience to you with our ~5kloc React frontend, while dependency upgrades for our 50kloc backend have been mostly painless.