Dependencies matter. Every dependency you add to your project is an invitation to break your project.
You send that invitation to the direct dependency author, and every downstream author. Add dependencies with care. Evaluate the trade-offs between depending on another package/library and using existing functionality.
When you choose to depend on other projects, consider whether you will use the dependency in standard and common ways. You may want to look for an alternative if you would test the boundaries of its' functionality.
Though the title is dramatic, Code dependencies are the devil provides a great overview of why dependencies should be added with care. It contains a set of questions to help you evaluate whether to add a project as a dependency.
Dirk Eddelbuettel wrote about dependency woes he experienced. He also includes examples of others' experiences.
Scott Chamberlain published a very nice blog post on limiting dependencies in R package development. Be sure to read the references as well.
Dirk Eddelbuettel took a great short introduction into getting started in R by Saghir Bashir and modified it to create a tinyverse edition that has a careful focus on dependency use.
Russ Cox offers a thoughtful essay entitled Our Software Dependency Problem detailing the (current) lack of best practices and tools to take full advantage of the (enormous) benefits available from responsible code reuse via carefully chosen dependencies.
Frank Chimero wrote an insightful post Everything Easy is Hard Again (based on two earlier talks) about toolchains and workflows (in the web development context) that is very relevant and insightful for the R development case too.
Chris Lewis argues convincingly that dependencies are not free and extract an ongoing maintenance cost.. He proposes to recognise the sub-field of 'software dependency engineering'.Dirk Eddelbuettel created a project for Continuous Integration for R at Travis, GitHub, Azure, etc. that is the successor of the r-travis project. Dirk forked the r-travis project when the original project added many non-base R dependencies. Like r-travis, r-ci has few dependencies and aims to be very stable. A user (erikca) praised r-ci for its stability:
We've been running this for 6 months on Azure - and it has performed without any hiccup whatsoever (except the rare timeout here and there from the CI provider).
Jeff Kaufman wrote a very good essay on Designing Low Upkeep Software. It stresses that [t]he biggest piece is minimizing your dependencies, and limiting them to ones that value backwards compatibility as well as a few other points which resonate with other points made here.
Milosz Danczak has a good post entitled Life is too shoort to depend on unstable software that opens with When committing to a piece of software, favor those created by people who value backward compatibility. and is worth reading in full.