That's the hidden cost of npm, cargo, pip, et. Al. The other one is IMO akin to overweight. Try to modernize a mid-sized project after one or two years and cry when you see the dependency graph.
Ceterum censeo go inferior est.
Ceterum censeo go inferior est.
Because that dependency might itself have dependencies and this quickly grows out if hand with different versions etc. It might work now, but will it in the future? How many different versions of the same package do I really need to depend on?
* Import the dependency manually. This is taking a dependency without the formal description a package manager gives you, making it harder to audit, update etc.
* Write the functionality yourself. This guarantees you are not exposed to malicious code, but it takes time and your solution will likely have more bugs than a widely used solution. You also lose the ability to use other dependencies that build on top (e.g. React components) because you are now outside the mainstream.
What is actually needed is better tooling to analyze and prune dependency graphs.
Try upgrading typescript to the latest version. I think that's a fair definition of "modernisation" and something which should be benign.
But now all of a sudden you have to upgrade every dependency to the latest version - or write your own .d.ts files - since they're typically written to the current library version - typescript version combination.
The language and standard library is always backwards compatible (minor security fixes excepted). So updating to a newer language version just works.
Major libraries at the roots of many dependency trees have upgraded in backwards incompatible ways a few times, but the community has pretty consistently come together and helped move every other library that anyone uses to the new version.
Cur?