3 ms·

But, like... Why did you update to a new version of Coffeescript and not know about this bug before it made it to your production environment? I agree that Co

But, like... Why did you update to a new version of Coffeescript and not know about this bug before it made it to your production environment? I agree that Coffeescript should probably just use semver. But they don't, and you have no control over that. What you do have control over is when you update your dependencies and whether or not you validate releases before deploying to production. It seems a little disingenuous to act like this is entirely Coffeescript's fault.

yclept 12y ago
always pin your dependencies
lmm 12y ago
npm has a substantial amount of valuable automated tooling that assumes semver. It is the standard of that community.
- kevincennis 12y ago
  Yeah, I completely understand that. I work on big Node apps every day. But anyone who's had an app in production for very long learns pretty quickly that you you use "1.8.0", not "^1.8.0" if you don't want things to break.
Touche 12y ago
There's a lot of value in being able to receive bug fixes without explicitly knowing about them and manually upgrading. Most people do not have enough time to do this, we get paid to ship features not fiddle with developer productivity tools. This is why npm shrinkwrap exists.
davidbanham 12y ago
I didn't update the deps. This situation arose when a new server was spun up. Chef dutifully checked out all the various repositories, installed the deps, etc etc. npm saw that there was a new version of a dep that was advertised as being backwards compatible, so it installed it. Then things broke. The prevention to this is npm shrinkwrap. Had that been used on this particular service, it would have continued installing coffeescript 1.4.0. It also would have missed out on any security patches, bugfixes or performance improvements that may have happened in the meantime.

3 ms·

But, like... Why did you update to a new version of Coffeescript and not know about this bug before it made it to your production environment? I agree that Co

by kevincennis 12y ago

yclept 12y ago
always pin your dependencies
lmm 12y ago
npm has a substantial amount of valuable automated tooling that assumes semver. It is the standard of that community.
- kevincennis 12y ago
  Yeah, I completely understand that. I work on big Node apps every day. But anyone who's had an app in production for very long learns pretty quickly that you you use "1.8.0", not "^1.8.0" if you don't want things to break.
Touche 12y ago
There's a lot of value in being able to receive bug fixes without explicitly knowing about them and manually upgrading. Most people do not have enough time to do this, we get paid to ship features not fiddle with developer productivity tools. This is why npm shrinkwrap exists.
davidbanham 12y ago
I didn't update the deps. This situation arose when a new server was spun up. Chef dutifully checked out all the various repositories, installed the deps, etc etc. npm saw that there was a new version of a dep that was advertised as being backwards compatible, so it installed it. Then things broke. The prevention to this is npm shrinkwrap. Had that been used on this particular service, it would have continued installing coffeescript 1.4.0. It also would have missed out on any security patches, bugfixes or performance improvements that may have happened in the meantime.