(emphasis mine)
I'm not very experienced in node.js development, but wouldn't automated deployment whenever a dependency changes be a really bad idea? Especially considering the issues with dependencies breaking in npm from the not-so-distant past.
(emphasis mine)
I'm not very experienced in node.js development, but wouldn't automated deployment whenever a dependency changes be a really bad idea? Especially considering the issues with dependencies breaking in npm from the not-so-distant past.
Presumably, you'd want to trigger testing and then a deploy, rather than just triggering a deploy, but if you have fully-automated testing, there's no reason not to include a deploy after testing as part of your triggered action.
You could, if you don't have fully automated testing, trigger a deploy to a non-production server automatically, and then after whatever manual validation you do on that server, manually deploy to production.
So, there's probably use cases for triggered deploys, but you don't want to do it willy-nilly.
But, I guess you could set up a whitelist for internal modules that your own org manages to propogate uptades up to deployment.
that being said, it turns out that the semver handshake the community does works Most of The Time, so if it is a trusted dependency it wouldn't be that dangerous. assuming you also had tests-dependent deploy, the tests would catch the break.