How DependencyDesk Analyzes Dependencies Across Four Ecosystems
DependencyDesk supports dependency analysis for JavaScript/Node.js, PHP, Ruby, and Python projects. Each ecosystem has its own package manager, manifest file format, and conventions for declaring dependencies and licenses. This post explains what DependencyDesk analyzes in each ecosystem and highlights common gaps that sellers and buyers should be aware of.
JavaScript and Node.js (npm)
DependencyDesk reads package.json and package-lock.json files in JavaScript projects. The package.json file declares direct dependencies and devDependencies with version ranges, while package-lock.json records the exact resolved versions of every dependency in the tree, including transitive dependencies.
The license field in package.json is a string (e.g., "license": "MIT") or an object for older formats. DependencyDesk extracts this field for each dependency. One common gap in the npm ecosystem is that some packages declare their license only in a LICENSE file in the package directory rather than in the license field of package.json. DependencyDesk flags these as "Unknown" so they can be verified manually.
JavaScript projects often have the largest dependency trees of any ecosystem. A typical Node.js application can have hundreds of direct dependencies and thousands of transitive dependencies. DependencyDesk reports all of these, organized by repository.
PHP (Composer)
DependencyDesk reads composer.json and composer.lock files in PHP projects. The composer.json file declares dependencies with version constraints, and composer.lock records the exact resolved versions. Composer has strong conventions around license declaration — the license field in composer.json is well-supported and most published packages include it.
PHP projects tend to have smaller dependency trees than JavaScript projects, but the dependencies are often more critical — frameworks like Laravel or Symfony form the backbone of the application. DependencyDesk reports both require and require-dev dependencies with their versions and licenses.
Ruby (Bundler)
DependencyDesk reads Gemfile and Gemfile.lock files in Ruby projects. The Gemfile declares dependencies with version constraints, and Gemfile.lock records the resolved dependency graph. Ruby gems declare their license in the gemspec file, and this information is typically available through the gem metadata.
Ruby projects generally have moderate dependency trees. The Ruby ecosystem has strong conventions around semantic versioning and license declaration. DependencyDesk extracts license information from the gem metadata for each dependency.
Python (pip and friends)
Python has multiple dependency declaration formats, and DependencyDesk supports the most common ones: requirements.txt, Pipfile (used with Pipenv), and pyproject.toml (used with Poetry and modern pip). The requirements.txt format is the simplest — a flat list of packages with optional version pins — but it does not include license information directly.
For Python projects, license information is typically declared in the package metadata on PyPI rather than in the dependency declaration file itself. DependencyDesk extracts what information is available from the manifest files and flags packages where the license cannot be determined from the available data.
Python's dependency management landscape is more fragmented than other ecosystems, with multiple competing tools (pip, Pipenv, Poetry, conda). DependencyDesk focuses on the pip-compatible formats that cover the vast majority of Python web applications.
Manifest Files vs. Lock Files
An important distinction in dependency analysis is between manifest files and lock files. Manifest files (package.json, composer.json, Gemfile) declare what dependencies the project needs with version ranges. Lock files (package-lock.json, composer.lock, Gemfile.lock) record the exact versions that were resolved and installed.
DependencyDesk analyzes both when available. Lock files provide more precise version information, which is important for vulnerability assessment and compliance. When only a manifest file is available (no lock file committed to the repository), DependencyDesk reports the version constraint rather than an exact version.
Common Gaps to Watch For
Several common gaps appear across all ecosystems during dependency analysis. Packages without declared licenses are the most common issue — DependencyDesk flags these as "Unknown" so they can be verified. Vendored dependencies (libraries copied directly into the repository rather than installed via a package manager) are not detected by manifest-level analysis. Private or internal packages that are not published to public registries may not have license metadata available.
These gaps are important to document in a due diligence context. A DependencyDesk report provides comprehensive coverage of declared dependencies, and the "Unknown" flags identify exactly where manual follow-up is needed.
Getting Started
DependencyDesk analyzes dependencies across all four ecosystems in a single pass across your entire GitHub organization. The analysis completes in minutes and produces an exportable CSV report. Visit dependencydesk.com to get started.