Supported ecosystems
Deptools reads five ecosystems. If your project declares its dependencies another way, it cannot be analyzed yet.
Supported ecosystems
| Ecosystem | Build files read |
|---|---|
| Maven | pom.xml |
| Gradle | build.gradle, or build.gradle.kts for the Kotlin DSL |
| npm | package.json, with package-lock.json, yarn.lock or pnpm-lock.yaml |
| sbt | build.sbt, and the Scala files under project/ |
| Composer | composer.json and composer.lock |
yarn and pnpm are read through their lockfiles. There is no separate yarn or pnpm ecosystem to pick, both are npm projects.
A project analyzes the module chosen at creation, and the creation form asks you which one. A repository that holds several modules can take one project per module, or a single project on Entire repository, which reads them all.
How the ecosystem is detected
A repository can declare more than one. When it does, Deptools proposes the JVM ecosystem first, then Composer, then npm, and the Ecosystem field of the creation form lets you pick another.
That order exists because a PHP application almost always ships a
package.json for its front end assets. Testing npm first would route a
Composer project to the wrong parser.
The ecosystem is fixed once the project is created. To change it, delete the project and create it again.
What is read to resolve versions
A build file names a dependency, and not always the version that ends up installed. How Deptools reaches the resolved version differs per ecosystem.
- Maven and Gradle resolve from the build files themselves. Deptools follows property variables, BOM and platform imports, version catalogs, Gradle constraints, and the versions carried by plugins such as Kotlin, Spring Boot, Quarkus, Micronaut and Android.
- npm and Composer resolve from the lockfile. On npm an analysis without one still runs, but Deptools then resolves the tree from the registry, so the versions it reports are the ones a fresh install would pick rather than the ones you ship. Commit your lockfile to remove that gap.
- sbt is read statically, from
build.sbtand the Scala files underproject/.
Scores are calibrated per ecosystem
Reference values are set per ecosystem, because the populations are not comparable. Maven, Gradle and sbt share one calibration, npm and Composer each have their own. A 7.4 on npm and a 7.4 on Maven are not the same statement. See the health score.