CLI to output structured data, JSON, TOML or YAML

[jayvdb]

How are you using generate-license-file?
Library

Is your feature request related to a problem? Please describe.
We only use this tool as a library because we want to emit the data in a structured format. When we present this data, we add a bit of styling to it.

Describe the solution you'd like
A new CLI output format. My preference would be TOML or YAML as we commit this file to our repository, but JSON would also be acceptable.

Additional context
I would like to switch to the CLI, so that we can use pnpm dlx .. , and therefore not have generate-license-file and its deps in our lock file, so we dont get hit by CVEs in these dependencies that are unable to impact our users as the tool is used to generate an audited data file.

[tobysmith568]

Hey @jayvdb ,

Exposing different output formats from our CLI has definitely been on our radar for a little while now but we backburnered it while no one was asking for it. Thank you for putting in the request!

It needs some thinking about which we'll do and we'll report back when we have something. Thanks for specifying you'd be interesting in TOML or YAML.

---

That being said, we suggest there might be an oversight in your rationale for why you don't want Generate-License-File to be listed in your package.json. While it's not a primary dependency of your application, CVEs can still be catastrophic even when they're constrained to CI/CD pipelines or developer machines. If there's a CVE in a tool you're using (no matter if you're pnpm dlx-ing it or not), we'd suggest you'd probably want to be made aware of it so that you can assess the risks. Even if the CLI in our package supports all your needs, we'd still suggest you list it in a way that it can be audited.

If you're finding that there are CVEs in our dependencies, please open issues for them so that we can address them.

[jayvdb]

Glad to hear this request is being considered.

We are well aware of the problems of using pnpm dlx .. , but I also appreciate you taking the time to explaining why it is far from perfect.

To justify this request a bit more in light of what you've explained, we want the ability to use generate-license-file without our custom script so that we can either run pnpm generate-license-file or pnpm dlx [email protected] as necessary to avoid CVEs. When there is a CVE in our lock files, we aggressively try to help upstream resolve the CVE, and try to use pnpm overrides and pnpmfile.js to avoid the CVE, but that isnt always possible. Another arrow in our quiver is to run cli tools using pnpm dlx cli@pin to remove problems from the lockfile. The objective of using that is to prove that we've eradicated the CVE. Simply adding an ignore in our CVE scanners (we also use https://github.com/google/osv-scanner which has fairly good pnpm support, SBOMs and https://github.com/DependencyTrack/dependency-track, and others) is a last resort, because they dont allow declaratively stating that we wish to "ignore CVE-XYZ via generate-license-file but do not allow that CVE from other dependencies". The current situation with CVEs is especially concerning for node, because we've been hit with a few CVEs that are clearly invalid, such as github/advisory-database#4548 (comment) - in that circumstance it can be hard to get the CVE fixed because the maintainers are justifiably reluctant to rush out a fix for a perceived problem that isnt a vulnerability.

Thankfully there are no current problems in the dependencies of generate-license-file, ... touch wood, but it helps to be prepared for the next one. We'll be sure to advise, if we encounter one. It is good to know this team will be receptive of those issues.