> For the complete documentation index, see [llms.txt](https://docs.interlynk.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.interlynk.io/lynkctl/how-to-guides/package-manifests.md).

# Package Manifest Projects

This guide covers generating an SBOM for a project managed by a package manager — JavaScript, Python, Go, Rust, Ruby, PHP, .NET, or Java.

## Prerequisites

* lynkctl installed — see [Installation](/lynkctl/installation.md)

No package manager and no network access are required. lynkctl reads the manifests and lockfiles in your project directly.

***

## Supported Ecosystems

| Ecosystem        | `--provider`                         | Detected from                                                                                                           |
| ---------------- | ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------- |
| JavaScript / npm | `npm` (alias `yarn`)                 | `package.json`, `package-lock.json`, `npm-shrinkwrap.json`, `pnpm-lock.yaml`, `yarn.lock`, `bun.lock`                   |
| Python           | `python`                             | `requirements.txt`, `Pipfile.lock`, `poetry.lock`, `pdm.lock`, `pylock.toml`, `uv.lock`, `pyproject.toml`, `setup.py`   |
| Go               | `go`                                 | `go.mod`, `go.sum`                                                                                                      |
| Rust             | `cargo`                              | `Cargo.toml`, `Cargo.lock`                                                                                              |
| Ruby             | `gem`                                | `Gemfile.lock`, `*.gemspec`                                                                                             |
| PHP              | `php`                                | `composer.json`, `composer.lock`                                                                                        |
| .NET             | `nuget` (aliases `dotnet`, `csharp`) | `*.csproj`, `packages.lock.json`, `packages.config`, `Directory.Packages.props`, `Directory.Build.props`, `*.deps.json` |
| Java (Maven)     | `maven`                              | `pom.xml`                                                                                                               |
| Java (Gradle)    | `gradle`                             | `build.gradle`(`.kts`), `settings.gradle`(`.kts`), `gradle.lockfile`, `gradle/verification-metadata.xml`                |

***

## Generate an SBOM

From the project root:

```bash
lynkctl generate . -o sbom.cdx.json
```

lynkctl auto-detects the ecosystem from the descriptors in the directory. The examples below are all equivalent to auto-detection, shown with an explicit `--provider` for clarity:

```bash
lynkctl generate ./web-app   --provider npm    -o sbom.cdx.json
lynkctl generate ./service   --provider go     -o sbom.cdx.json
lynkctl generate ./api       --provider python -o sbom.cdx.json
lynkctl generate ./lib       --provider maven  -o sbom.cdx.json
lynkctl generate ./gradle-app --provider gradle -o sbom.cdx.json
```

## Lockfiles vs Manifests

A lockfile pins the exact resolved dependency set; a manifest only declares ranges. lynkctl prefers the lockfile when one is present. When a project has only a manifest (for example a `package.json` with no `package-lock.json`), lynkctl falls back to the manifest and emits a `LOCKFILE_ABSENT` diagnostic — the resulting SBOM may be less precise than one built from a lockfile.

For the most accurate SBOM, commit and point lynkctl at a project that has its lockfile present.

## Multi-Ecosystem Repositories

If a directory contains descriptors for more than one ecosystem — say a `package.json` next to a `go.mod` — auto-detection is ambiguous and lynkctl reports `MULTI_ECOSYSTEM_DETECTED`. Pass `--provider` to choose:

```bash
lynkctl generate . --provider go -o backend.cdx.json
lynkctl generate . --provider npm -o frontend.cdx.json
```

## Flags

Manifest providers honour the shared flags — `--no-enrich`, `--overrides`, `--evidence`, `--exclude-dev`, `--exclude-optional`, `--reproducible`, `--timestamp`, `--strict`, `--quiet`, `--verbose`, and `--output`. See the [Generating SBOMs](/lynkctl/generate.md) flag reference.

The C/C++ build-provider flags — `--include-source-files`, `--exclude-header-files`, `--include-unlinked-vendored`, `--deep-scan`, and the `--make-*` / `--cmake-*` / `--iar-*` families — do **not** apply to manifest providers. Passing one produces a usage error (exit code `2`).

## Troubleshooting

If a run reports warnings or errors, rerun with `-v` to see the individual diagnostics and their suggested actions. See [Diagnostics & Exit Codes](/lynkctl/diagnostics.md) for severity levels, exit codes, and strict mode. For help interpreting a specific diagnostic, contact Interlynk.