Expose defineConfig on a ./config entrypoint

[theRizwan]

Closes #1941

Adds a defineConfig helper on a separate ./config entrypoint, following @iiroj's suggestion in the issue.

A separate entrypoint keeps the helper and its type resolving through one specifier, so the existing . map stays as it is and nothing new gets pulled in from the index file when a config is loaded. ./session was already the precedent for a second entrypoint, so the shape matches that.

The helper returns its argument unchanged, so it is types only at runtime. KnipConfig is RawConfiguration | ((options: ParsedCLIArgs) => RawConfiguration | Promise<RawConfiguration>), so both the object form and the sync and async function forms already documented on the Dynamic Configuration page go through it without a second overload.

// knip.ts
import { defineConfig } from 'knip/config';

export default defineConfig({
  entry: ['src/index.ts'],
  project: ['src/**/*.ts'],
});

Checked before opening:

• pnpm knip and pnpm knip:production --strict both run clean on this repo, so the new export is picked up as an entry through the exports map rather than reported as unused
• 1069 tests pass
• typechecked a real consumer resolving knip/config under moduleResolution: nodenext. Object form and async function form both pass, entry: 42 fails with the underlying string | string[] | undefined, so the type is coming through the emitted declaration and not being widened
• npm pack includes dist/config.js and dist/config.d.ts
• pnpm run ci clean

Docs section added to Dynamic Configuration. Happy to drop the docs or the whole thing if you would rather keep the config typed with satisfies KnipConfig.

[webpro]

Thanks Rizwan, and everyone involved! Nice teamwork y'all 🫶

[webpro]

🚀 This pull request is included in v6.33.0. See Release 6.33.0 for release notes.

Using Knip in a commercial project? Please consider becoming a sponsor.