> 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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.interlynk.io/lynkctl/how-to-guides/package-manifests.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.