All your replies about external APIs changing are irrelevant. A codeveloper touching functions that call your functions or defining functions called by you will integrate with your work with an innocuous "git pull" and force you to review everything just to rule out what JS could have easily detected.
> If a change in a dependency causes you to have a ripple effect of completely broken code - then yes, your code is tightly coupled.
Again, I'm not talking about "dependencies" or libraries here at all.
> In my job, if somebody commits and pushes something which is going to completely fuck the rest of the development team, then they're told to piss off and fix it.
The push was completely benign. The integration of that push with your current work will be broken in cryptic ways. Not necessarily ones that show up in the testing suites.
> If you absolutely must change a function signature which is part of an API that others may be depending on, then you fucking document it and alert your users. Again, not JS. Sort your process out.
Every single function signature can break things, not just exposed APIs. Two developers might work on the same piece of code. There's not necessarily any obvious point to notify here and still breakage may arise.
> Except it doesn't, because who updates a dependency without checking that they can actually depend on it? The clue's in the name.
You clearly haven't understood the scenario involved, I'll try to describe it again:
1) Developer A adds a new function FOO that calls internal function BAR in his unpushed working tree.
2) Developer B changes the signature of internal function BAR, and pushes this change to "master".
3) Developer A pulls from master, his code is now broken, but JS doesn't even warn him when he executes it. Instead, wrong results (or accidentally correct results for any given test case) arise.
4) The test suites don't catch the error. Developer A unwittingly pushes the broken code to master.