I disagree with this. Dependencies become your code and any magic will always come and bite you, no matter if it's written by you or a downstream dependency.
The guiding principle should be: Reject magic at all cost
1. take an extremely impractical amount of time reinventing the wheel in house, or
2. take a (IMO a relatively much smaller) hit when you fail to take the 10 minutes to read the breaking changes on the dependency. Read this, make fixes, and everything is working again. If you hit a major issue like this with your own tooling, you're at the mercy of your team's ability to quickly build a fix.
A refined version of this point may be something like "only use dependencies which are very well tested, documented, list known issues, and have an active community of development and releases" - don't just install any package or library because "it appears to solve my problem"