knip icon indicating copy to clipboard operation
knip copied to clipboard

💡 Add option to ignore export names using a pattern

Open eugene-mohc opened this issue 1 year ago • 4 comments

Suggest an idea for this project

It would be useful to be able to ignore certain exports by pattern or regex matching. For example I like to always export the props type of a React component in its file. It may not be used anywhere else yet, but is conveniently there for the future and reduces git diffs.

This can somewhat be achieved using these settings:

{
  "ignoreExportsUsedInFile": {
    "type": true
  }
}

However this prevents all other type exports from being reported as well, which is not ideal. The config could accept an array of patterns to ignore instead:

{
  "ignoreExportsUsedInFile": {
    "type": [".*Props"]
  }
}

This would ignore only type exports which end with "Props", for example:

              // Matches, OK      // Not used, reported
export type { ComponentNameProps, SomeOtherType }

export { ComponentName }

eugene-mohc avatar Aug 21 '24 08:08 eugene-mohc

Valid RFC. Would likely becomes regexes for ignoreExports or ignoreExportTypes (like ignoreBinaries etc already do).

For now, you could add a simple preprocessor function to strip out anything unwanted.

webpro avatar Aug 21 '24 08:08 webpro

@webpro I've build an custom preprocessor that deletes issues that are not correct or accepted. This works great for reporting. However, when combined with the --fix option, it ignore my custom preprocessor and "fixes" the issues anyways. Is this by design or a bug?

Pseudo-code of my preprocessor:

import type { ReporterOptions } from "knip";

export default function (options: ReporterOptions): ReporterOptions {
  delete options.issues.exports["some/file.name"];
  return options;
}

jerone avatar Dec 30 '24 10:12 jerone

Is this by design or a bug?

To answer my own question; this is by design. Reading the source, all preprocessors are run just before reporters. This is after fixers are ran.

Something like preprocessors, but before fixers, would help a lot.

jerone avatar Jan 04 '25 21:01 jerone

I think it's a bug and we should apply the fixes only on the issues returned from the preprocessor(s). Different issue than OP, though.

webpro avatar Jan 05 '25 20:01 webpro

Closing this issue as part of a general cleanup to keep this project sustainable and optimize my time working on it. If you think this is inappropriate or if there is no workaround and you feel stuck, feel free to open a new issue. Thanks for your understanding.

webpro avatar Aug 10 '25 07:08 webpro