Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A small feature can bring a surprisingly large tree of code with it. That does not prove software dependencies are universally growing out of control, but it does explain why teams need to know what their applications include, why it is there, and how it is maintained.
Why does my app have so many dependencies?
Modern applications reuse components rather than implementing every capability from scratch. When a project adds a package, that package may require other packages to work. The resolved set can therefore be much larger than the list a developer added by hand.
Sonatype estimated more than 6.6 trillion open-source downloads in 2024 and said open-source components could make up as much as 90% of a modern application. Those are claims from Sonatype’s vendor-produced report, not a neutral measurement of every application. The report also put 2024 npm requests at 4.5 trillion and estimated 530 billion PyPI requests; those figures describe requests to package registries, not unique packages or applications.
Recommended Free Tools
What are direct, transitive, and bloated dependencies?
Direct dependencies
A direct dependency is a component your application references or declares. For example, a web project might directly include a library for parsing dates.
#1 Best Overall
Transitive dependencies
A transitive dependency is included because another dependency needs it. If the date library depends on a formatting package, that package is part of the application’s dependency tree even if your own code never imports it. Dependencies can themselves have dependencies, creating a recursive graph. Google Cloud notes that teams need visibility into indirect dependencies because issues can originate in components the application does not reference directly. Google Cloud’s dependency-management guidance explains the distinction and related practices.
Bloated dependencies
More dependencies and bloated dependencies are not the same thing. A larger resolved component set may be appropriate for an application’s needs. In a 2021 peer-reviewed study of Maven artifacts, researchers classified a dependency relationship as bloated when the dependency was not needed to build or run the artifact under their analysis method.
In that study, 75.1% of analyzed Maven dependency relationships were classified as bloated. The sample covered 9,639 artifacts and 723,444 dependency relationships; the result is specific to that study’s Maven sample and definition, not an estimate for all languages, package managers, or software. In a small cleanup intervention, 21 of 26 answered pull requests were merged, removing 140 bloated dependencies. That suggests many proposed removals were accepted in that sample, not that every project can remove dependencies easily.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Are dependencies a security risk?
Dependencies can introduce maintenance and security concerns, but dependency count alone does not tell you how vulnerable an application is or how likely it is to be exploited. Risk depends on factors such as the component and version, whether vulnerable code is reachable, the application’s exposure, exploitability, and available controls.
The Maven study notes that unnecessary dependencies can enlarge binaries, increase maintenance effort, and include potentially vulnerable code the artifact does not need. Separately, an indirect dependency can have a vulnerability or other issue even when application code never references it directly. A useful security process therefore tracks the full resolved graph and prioritizes components by actual use, reachability, severity, and remediation options rather than treating every dependency equally.
How can I find unused dependencies and reduce bloat?
Use a repeatable review rather than removing packages based only on their names or apparent lack of use. A dependency may be used by generated code, build steps, plugins, tests, or runtime behavior that is not obvious from a quick source search.
- Inventory the resolved graph. Use your package manager or build system to inspect both direct and transitive components. Confirm which versions are actually resolved, not just which names appear in a manifest. Visibility into indirect components is necessary to investigate issues beyond the packages your code imports.
- Preserve resolved versions. Commit the lockfile or equivalent reproducibility mechanism supported by your ecosystem. Google’s Node.js guidance describes npm and Yarn lockfiles as records of exact package versions that help subsequent installations use the same versions. Other languages and build systems differ, so follow the mechanism for your own tooling rather than assuming every ecosystem behaves like Node.js.
- Check whether declared packages are needed. Review imports, build and test configuration, generated code, plugins, and runtime paths. Remove a candidate only after checking those uses, then run the project’s tests and build. DepClean is a Maven-specific research tool; its analysis should not be assumed to transfer unchanged to other ecosystems.
- Monitor and verify. Track vulnerability information for direct and indirect components, keep relevant packages updated, and verify artifacts where your workflow supports it. Google’s guidance includes vulnerability monitoring and artifact verification as dependency-management practices.
- Use an SBOM as working data. A software bill of materials (SBOM) records components in a software product. The NSA and Enduring Security Framework recommendations announced on November 9, 2023, cover SBOM consumption, lifecycle, risk scoring, and operational implementation. An inventory by itself does not manage risk: teams need to consume it and connect findings to ownership, severity, and remediation decisions. The NSA announcement describes the guidance’s scope.
- Remediate proportionately. Remove unnecessary components when safe; otherwise, update, replace, constrain, or mitigate them according to actual use and risk. Recheck the resolved graph after changes so a removal does not simply expose a different indirect dependency or break another part of the build.
What does responsible dependency growth look like?
Healthy reuse lets teams deliver functionality without maintaining every underlying component themselves. The tradeoff is that each added dependency can create another relationship to understand, update, and monitor. The useful question is not whether an application has a large number of dependencies in isolation, but whether the team can explain and manage the components it ships.
- Can the team identify direct and transitive components and their resolved versions?
- Can it tell which dependencies are used by the build, tests, and running application?
- Does it receive and act on relevant vulnerability and update information?
- Can it verify artifacts and use an SBOM to support lifecycle and risk decisions?
Those controls make a growing dependency tree inspectable. Without them, even a modest list of direct packages can conceal components the team did not deliberately select.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
