Offer programmatic API

[webpro]

The main function in src/index.ts or something similar/new could be exposed for programmatic usage. Yet needs attention in terms of API: what should it look like for external usage?

[Jym77]

Adding my 2 cents here:
knip seems to be doing a very good job at building the dependency graph of the project.
One other of my tooling problem is to generate human readable (dot, convertible to images) dependency graphs for my workspaces. So far I haven't found a tool which is doing it exactly the way I'd like…

Quoting knip's README:

When building a dependency graph of the project, an abstract syntax tree for each file, and traversing all of this, why not collect the various issues in one go?

Would it also be possible to have a programmatic hook into that graph to use it for other purposes? I'd rather have a single tool build a single dependency graph and use it as source of truth for all my dependency graph needs (whether pruning unused exports or documenting code structure)…

[webpro]

Here's some additional info:

• Knip tries to find entry files and utilizes TypeScript's ts.createProgram() (with a call to program.getTypeChecker(), and recursively after more entry files are found), eventually resulting in a set of resolved files. Note: a monorepo may have more than one such program.
• The other thing Knip could potentially expose is the list of exports and imports. You can look for exportedSymbols and importedSymbols in src/index.ts and see if that contains what you're after.

Not promising anything here, but these are starting points.

[webpro]

Not in scope, closing this for now.

[mathieucaroff]

To users who think they need a programmatic API, please note that Knip already supports:

• A. JSON reporter (knip --reporter json)
• B. custom reporters (knip --reporter ./my-reporter.ts)
• C. custom pre-processors (knip --preprocessor ./my-preprocess.ts): They really should have been called post-processors. They are functions that receive the results and return data in the same shape/structure as the results.

(B) and (C) allow to achieve features like:

• Custom filtering
• Custom output formatting
• Richer data output

As of 2023-12-08, they are documented here: https://knip.dev/features/reporters/

[webpro]

Thanks @mathieucaroff!

A great example is this GitHub Action: https://github.com/marketplace/actions/knip-reporter

They really should have been called post-processors.

A bit off-topic, but I guess it depends on how you look at it:

knip produces results/data → processor(s) → reporter(s)

The initial idea was that it's processing the data before reporting it. But yeah, one can definitely argue it's processing data after it's assembled.