knip 2.4.0 → 2.6.1

package/README.md

@@ -1,16 +1,16 @@
 # ✂️ Knip
 
 Knip finds **unused files, dependencies and exports** in your JavaScript and TypeScript projects. Less code and
-dependencies leads to improved performance, less maintenance and easier refactorings.
+dependencies lead to improved performance, less maintenance and easier refactorings.
 
 ```ts
 export const myVar = true;
 ```
 
 This is where ESLint stops: it handles files in isolation, so it does not know whether `myVar` is used somewhere else.
-This is where Knip starts: it lints the project as a whole, and finds unused exports, files and dependencies.
+This is where Knip starts: it lints the project as a whole and finds unused exports, files and dependencies.
 
-It's only human to forget removing things that you no longer use. But how do you find out? Where do you start finding
+It's only human to forget to remove things that you no longer use. But how do you find out? Where do you start finding
 things that can be removed?
 
 The dots don't connect themselves. This is where Knip comes in:
@@ -53,18 +53,18 @@ Well, almost, this is the full list of default extensions: `js`, `mjs`, `cjs`, `
 
 ### Entry Files
 
-Knip looks for entry files at the default locations above, but also in other places:
+Knip looks for entry files at those default locations, but also in other places:
 
 - The `main`, `bin` and `exports` fields of `package.json`.
-- [Plugins][2] such as for Next.js, Remix, Gatsby or Svelte define entry files so you don't have to.
-- The `scripts` in package.json may also provide entry files that Knip can use.
+- [Plugins][2] such as for Next.js, Remix, Gatsby or Svelte add entry files.
+- The `scripts` in package.json or other scripts may provide entry files.
 - Knip does this for each [workspace][1] it finds.
 
 In other words, Knip looks in many places and you may not need much configuration. In a perfectly boring world where
 everything is according to defaults you don't even need a `knip.json` file.
 
 Larger projects tend to have more things customized, and therefore probably get more out of Knip with a configuration
-file. Let's say you are using `.ts` files excusively and have all source files only in the `src` directory:
+file. Let's say you are using `.ts` files exclusively and have all source files only in the `src` directory:
 
 ```json
 {
@@ -171,31 +171,63 @@ This example shows more output related to unused and unlisted dependencies:
 
 The report contains the following types of issues:
 
-- **Unused files**: did not find references to this file
-- **Unused dependencies**: did not find references to this dependency
-- **Unused devDependencies**: did not find references to this dependency
-- **Unlisted dependencies**: used dependencies, but not listed in package.json _(1)_
-- **Unresolved imports**: import specifiers that could not be resolved
-- **Unused exports**: did not find references to this exported variable
-- **Unused exports in namespaces**: did not find direct references to this exported variable _(2)_
-- **Unused exported types**: did not find references to this exported type
-- **Unused exported types in namespaces**: did not find direct references to this exported variable _(2)_
-- **Unused exported enum members**: did not find references to this member of the exported enum
-- **Unused exported class members**: did not find references to this member of the exported class
-- **Duplicate exports**: the same thing is exported more than once
+| Title          | Key                                 | Description                                           |
+| :------------- | :---------------------------------- | :---------------------------------------------------- |
+| `files`        | Unused files                        | unable to find references to this file                |
+| `dependencies` | Unused dependencies                 | unable to find references to this dependency          |
+| `dependencies` | Unused devDependencies              | unable to find references to this dependency          |
+| `unlisted`     | Unlisted dependencies               | used dependencies not listed in package.json _(1)_    |
+| `unresolved`   | Unresolved imports                  | unable to resolve this (import) specifier             |
+| `exports`      | Unused exports                      | unable to find references to this export              |
+| `nsExports`    | Unused exports in namespaces        | unable to find direct references to this export _(2)_ |
+| `types`        | Unused exported types               | unable to find references to this exported type       |
+| `nsTypes`      | Unused exported types in namespaces | unable to find direct references to this export _(2)_ |
+| `enumMembers`  | Unused exported enum members        | unable to find references to this enum member         |
+| `classMembers` | Unused exported class members       | unable to find references to this class member        |
+| `duplicates`   | Duplicate exports                   | the same thing is exported more than once             |
 
 When an issue type has zero issues, it is not shown.
 
-_(1)_ If an unlisted dependency is prefixed with `bin:` it means a binary is missing. This often equals the package
-name, but not always (e.g. `tsc` of `typescript` or `webpack` from `webpack-cli`).
+Getting too many reported issues and false positives? Read more about [handling issues][8].
 
-_(2)_ The variable or type is not referenced directly, and has become a member of a namespace. Knip can't find a
+_(1)_ If an unlisted dependency is prefixed with `bin:` it means the dependency containing that binary is unlisted. This
+often equals the package name, but not always (e.g. `tsc` of `typescript` or `webpack` from `webpack-cli`).
+
+_(2)_ The variable or type is not referenced directly and has become a member of a namespace. Knip can't find a
 reference to it, so you can _probably_ remove it.
 
-### Output filters
+## Output
+
+### Rules
+
+Use `rules` in the configuration to customize the issue types that count towards the total error count, or to exclude
+them altogether.
+
+- `error` (default): printed, adds to total error count (similar to the `--include` filter)
+- `warn`: printed in faded/grey color, does not add to error count (i.e. the exit code)
+- `off`: not printed, does not add to error count (similar to the `--exclude` filter)
+
+Example:
+
+```json
+{
+  "rules": {
+    "files": "warn",
+    "classMembers": "off",
+    "duplicates": "off"
+  }
+}
+```
+
+See [reading the report][9] for the list of issue types.
+
+The rules are modeled after the ESLint `rules` configuration, and could be extended in the future. For instance, to
+apply filters or configurations only to a specific issue type.
 
-You can `--include` or `--exclude` any of the types to slice & dice the report to your needs. Alternatively, they can be
-added to the configuration (e.g. `"exclude": ["dependencies"]`).
+### Filters
+
+You can `--include` or `--exclude` any of the reported issue types to slice & dice the report to your needs.
+Alternatively, they can be added to the configuration (e.g. `"exclude": ["dependencies"]`).
 
 Use `--include` to report only specific issue types (the following example commands do the same):
 
@@ -208,8 +240,16 @@ Use `--exclude` to ignore reports you're not interested in:
 
 Use `--dependencies` or `--exports` as shortcuts to combine groups of related types.
 
-Still not happy with the results? Getting too much output/false positives? The [FAQ][8] may be useful. Feel free to open
-an issue and I'm happy to look into it. Also see the next section on how to [ignore][9] certain false positives:
+See [reading the report][9] for the list of issue types.
+
+### When to use rules or filters
+
+Filters are meant to be used as command-line flags, rules allow for more fine-grained configuration.
+
+- Rules are more fine-grained since they also have "warn".
+- Rules could be extended in the future.
+- Filters can be set in configuration and from CLI, rules only in configuration.
+- Filters have two groups (`--dependencies` and `--types`), rules don't have any grouping.
 
 ## Ignore
 
@@ -226,11 +266,11 @@ There are a few ways to tell Knip to ignore certain packages, binaries, dependen
 
 These can also be configured per workspace (except for `ignoreWorkspaces`).
 
-## Now what?
+## What's next?
 
 This is the fun part! Knip, knip, knip ✂️
 
-As always, make sure to backup files or use Git before deleting files or making changes. Run tests to verify results.
+As always, make sure to back up files or use Git before deleting files or making changes. Run tests to verify results.
 
 - Unused files can be removed.
 - Unused dependencies can be removed from `package.json`.
@@ -242,9 +282,14 @@ As always, make sure to backup files or use Git before deleting files or making
 
 🔁 Repeat the process to reveal new unused files and exports. Sometimes it's so liberating to remove things!
 
-## Workspaces (monorepos)
+Getting too many reported issues and false positives? Read more about [handling issues][8].
+
+## Workspaces
 
-Workspaces and monorepos are handled out-of-the-box by Knip. Every workspace is part of the analysis.
+Workspaces are handled out-of-the-box by Knip. Every workspace is part of the analysis.
+
+Workspaces are sometimes also referred to as package-based monorepos, or as packages in a monorepo. Knip uses the term
+workspace exclusively to indicate a directory that has a `package.json`.
 
 Here's an example `knip.json` configuration with some custom `entry` and `project` patterns:
 
@@ -267,12 +312,9 @@ Here's an example `knip.json` configuration with some custom `entry` and `projec
 ```
 
 It might be useful to run Knip first with no or little configuration to see where it needs custom `entry` and/or
-`project` files. The default configuration of each workspace is the same as for a regular project.
-
-Workspaces are sometimes also referred to as packages in a monorepo. Knip uses the term workspaces exclusively to
-indicate the directories that have a `package.json`.
+`project` files. Each workspace has the same [default configuration][10].
 
-Root workspaces must be named `"."` under `workspaces` (like in the example).
+The root workspace is named `"."` under `workspaces` (like in the example).
 
 Knip supports workspaces as defined in three possible locations:
 
@@ -283,15 +325,14 @@ Knip supports workspaces as defined in three possible locations:
 Extra "workspaces" not configured as a workspace in the root `package.json` can be configured as well, Knip is happy to
 analyze unused dependencies and exports from any directory with a `package.json`.
 
+The `ignore`, `ignoreBinaries` and `ignoreDependencies` options are available inside workspace configurations.
+
 Here's some example output when running Knip in a workspace:
 
 <img src="./assets/screenshot-workspaces.png" alt="example output in workspaces" width="578">
 
 Use `--debug` to get more verbose output.
 
-Use `ignoreBinaries` and `ignoreDependencies` at the root of `knip.json` for global effect, or inside any workspace
-config for local effect.
-
 ## Plugins
 
 Plugins tell Knip where to look for configuration and entry files, and if necessary have a custom dependency finder.
@@ -353,8 +394,8 @@ Knip contains a growing list of plugins:
 - [Webpack][plugin-webpack]
 
 Plugins are automatically activated. Each plugin is automatically enabled based on simple heuristics. Most of them check
-whether one of a few dependencies are listed in `package.json`. Once enabled, they add a set of `config` files for
-itself and/or `entry` files for Knip to analyze.
+whether one of a few dependencies is listed in `package.json`. Once enabled, they add a set of `config` files for
+themselves and/or `entry` files for Knip to analyze.
 
 - `config` files are given to the plugin's dependency finder
 - `entry` files are given to Knip to include with the analysis of the rest of the source code
@@ -374,10 +415,10 @@ and can be analyzed like any other source file. That's why these configuration f
 
 ### Override plugin configuration
 
-Usually no custom configuration is required for plugins, but if your project uses custom file locations then Knip allows
-to override any defaults. Let's take Cypress for example. By default it uses `cypress.config.js`, but your project uses
-`config/cypress.js`. Also, the default pattern for test files is `cypress/e2e/**/*.cy.js`, but your project has them at
-`e2e-tests/*.spec.ts`. Here's how to configure this:
+Usually, no custom configuration is required for plugins, but if your project uses custom file locations then Knip
+allows you to override any defaults. Let's take Cypress for example. By default it uses `cypress.config.js`, but your
+project uses `config/cypress.js`. Also, the default pattern for test files is `cypress/e2e/**/*.cy.js`, but your project
+has them at `e2e-tests/*.spec.ts`. Here's how to configure this:
 
 ```json
 {
@@ -389,9 +430,9 @@ to override any defaults. Let's take Cypress for example. By default it uses `cy
 
 ### Multi-project repositories
 
-Some repositories have a single `package.json`, but consist of multiple projects with potentially lots of configuration
-files (such as the [Nx "intregrated repo" style][10]). Let's assume some of these projects are apps and have their own
-Cypress configuration and test files. In that case, we could configure the Cypress plugin like this:
+Some repositories have a single `package.json`, but consist of multiple projects with configuration files across the
+repository (such as the [Nx "intregrated repo" style][11]). Let's assume some of these projects are apps and have their
+own Cypress configuration and test files. In that case, we could configure the Cypress plugin like this:
 
 ```json
 {
@@ -407,18 +448,18 @@ In case a plugin causes issues, it can be disabled by using `false` as its value
 
 ### Create a new plugin
 
-Getting false positives because a plugin is missing? Want to help out? Please read more at [writing a plugin][11]. This
+Getting false positives because a plugin is missing? Want to help out? Please read more at [writing a plugin][12]. This
 guide also contains more details if you want to learn more about plugins and why they are useful.
 
 ## Compilers
 
-Knip v2 introduces compilers which allows to include files that are not JavaScript or TypeScript in the process of
-finding unused or missing dependencies. For instance, `.mdx`, `.vue` and `.svelte` files come to mind.
+Knip v2 introduces compilers that allow to include files that are not JavaScript or TypeScript in the process of finding
+unused or missing dependencies. For instance, `.mdx`, `.vue` and `.svelte` files come to mind.
 
-Currently this is only supported by using `knip.js` or `knip.ts`. Provide a `compilers` object in the configuration
+Currently, this is only supported by using `knip.js` or `knip.ts`. Provide a `compilers` object in the configuration
 where each key represents the extension and the value is a function that takes the contents of these files as input and
 returns JavaScript or TypeScript as output. Here is an example that compiles `.mdx` files to JavaScript so these files
-and their imports and exports become part of the analyis:
+and their imports and exports become part of the analysis:
 
 ```js
 import { compileSync } from 'mdx-js/mdx';
@@ -430,13 +471,13 @@ export default {
 };
 ```
 
-Read [Compilers][12] for more details and examples.
+Read [Compilers][13] for more details and examples.
 
 ## Production Mode
 
 The default mode for Knip is holistic and targets all project code, including configuration files and tests. Test files
-usually import production files. This prevents the production files or its exports from being reported as unused, while
-sometimes both of them can be removed. This is why Knip has a "production mode".
+usually import production files. This prevents the production files or their exports from being reported as unused,
+while sometimes both of them can be removed. This is why Knip has a "production mode".
 
 To tell Knip what is production code, add an exclamation mark behind each `pattern!` that is meant for production and
 use the `--production` flag. Here's an example:
@@ -451,7 +492,7 @@ use the `--production` flag. Here's an example:
 Here's what's included in production mode analysis:
 
 - Only `entry` and `project` patterns suffixed with `!`.
-- Only production `entry` file patterns exported for plugins (such as Next.js and Gatsby).
+- Only production `entry` file patterns exported by plugins (such as Next.js and Gatsby).
 - Only the `start` and `postinstall` scripts (e.g. not the `test` or other npm scripts in `package.json`).
 - Only unused `exports`, `nsExports` and `classMembers` are reported (not `types`, `nsTypes`, `enumMembers`).
 
@@ -488,7 +529,7 @@ aliases. They can be configured manually:
 
 Each workspace can also have its own `paths` configured. Note that Knip `paths` follow the TypeScript semantics:
 
-- Path values is an array of relative paths.
+- Path values are an array of relative paths.
 - Paths without an `*` are exact matches.
 
 ## Reporters
@@ -504,14 +545,14 @@ Knip provides the following built-in reporters:
 
 When the provided built-in reporters are not sufficient, a custom reporter can be implemented.
 
-Pass `--reporter ./my-reporter` from the command-line. The data can then be used to write issues to `stdout`, a JSON or
+Pass `--reporter ./my-reporter` from the command line. The data can then be used to write issues to `stdout`, a JSON or
 CSV file, or sent to a service.
 
-Find more details and ideas in [custom reporters][13].
+Find more details and ideas in [custom reporters][14].
 
 ## Public exports
 
-Sometimes a file that's not an entry file has one or more exports that are public, and should not be reported as unused.
+Sometimes a file that's not an entry file has one or more exports that are public and should not be reported as unused.
 Such variables and types can be marked with the JSDoc `@public` tag:
 
 ```js
@@ -529,54 +570,10 @@ export const split = function () {};
 
 Knip does not report public exports and types as unused.
 
-## FAQ
-
-### Really, another unused file/dependency/export finder?
-
-There are already some great packages available if you want to find unused dependencies OR unused exports.
-
-I love the Unix philosophy ("do one thing well"). But in this case I believe it's efficient to handle multiple concerns
-in a single tool. 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?
-
-### How do I handle too many output/false positives?
-
-#### Too many unused files
-
-When the list of unused files is too long, this means the gap between the set of `entry` and the set of `project` files
-needs tweaking. The gap can be narrowed down by increasing the `entry` files or reducing the `project` files, for
-instance by ignoring specific directories that are not related to the source code imported by the `entry` files.
-
-#### Too many unused dependencies
-
-Dependencies that are only imported in unused files are also marked as unused. So a long list of unused files would be
-good to remedy first.
+## Handling Issues
 
-When unused dependencies are related to dependencies having a Knip [plugin][1], maybe the `config` and/or `entry` files
-for that dependency are at custom locations. The default values are at the plugin's documentation, and can be overridden
-to match the custom location(s).
-
-When the dependencies don't have a Knip plugin yet, please file an issue or [create a new plugin][14].
-
-#### Too many unused exports
-
-Unused exports of `entry` files are not reported. When exports of other files are marked as unused, because they are
-meant to be used by consumers of the library, there are a few options:
-
-1.  Add the containing file to the `entry` array in the configuration.
-2.  Re-export from an existing entry file.
-3.  Mark the exported value or type [using the JSDoc `@public` tag][15].
-
-### How to start using Knip in CI while having too many issues to sort out?
-
-Eventually this type of QA only really works when it's tied to an automated workflow. But with too many issues to
-resolve this might not be feasible right away, especially in existing larger codebase. Here are a few options that may
-help in the meantime:
-
-- Use `--no-exit-code` for exit code 0 in CI.
-- Use `--include` (or `--exclude`) to report only the issue types that have little or no errors.
-- Use separate Knip commands to analyze e.g. only `--dependencies` or `--exports`.
-- Use [ignore patterns][9] to filter out the most problematic areas.
+How to handle a long list of reported issues? Seeing too many false positives? Read more about [handling issues][15]
+describing potential causes for false positives, and how to handle them.
 
 ## Comparison
 
@@ -641,53 +638,62 @@ The following commands are similar:
 Many thanks to some of the early adopters of Knip:
 
 - [Block Protocol][21]
-- [DeepmergeTS][22]
-- [eslint-plugin-functional][23]
-- [freeCodeCamp.org][24]
-- [is-immutable-type][25]
-- [release-it][26]
-- [Template TypeScript Node Package][27]
+- [Cursor][22]
+- [DeepmergeTS][23]
+- [eslint-plugin-functional][24]
+- [freeCodeCamp.org][25]
+- [is-immutable-type][26]
+- [release-it][27]
+- [Template TypeScript Node Package][28]
 
 ## Knip?!
 
 Knip is Dutch for a "cut". A Dutch expression is "to be ge**knip**t for something", which means to be perfectly suited
-for the job. I'm motivated to make knip perfectly suited for the job of cutting projects to perfection! ✂️
+for the job. I'm motivated to make Knip perfectly suited for the job of cutting projects to perfection! ✂️
+
+## Really, another unused file/dependency/export finder?
+
+As listed above, there are already some great packages available if you want to find unused dependencies OR unused
+exports. I love the Unix philosophy ("do one thing well"). But looking at what Knip does, I believe it's efficient to
+handle multiple concerns in a single tool. 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?
 
 ## Contributors
 
 Special thanks to the wonderful people who have contributed to this project:
 
-[![Contributors][29]][28]
+[![Contributors][30]][29]
 
-[1]: #workspaces-monorepos
+[1]: #workspaces
 [2]: #plugins
 [3]: #compilers
 [4]: #reporters
 [5]: #custom-reporters
 [6]: https://labs.openai.com/s/xZQACaLepaKya0PRUPtIN5dC
 [7]: ./assets/cow-with-orange-scissors-van-gogh-style.webp
-[8]: #faq
-[9]: #ignore
-[10]: https://nx.dev/concepts/integrated-vs-package-based
-[11]: ./docs/writing-a-plugin.md
-[12]: ./docs/compilers.md
-[13]: ./docs/custom-reporters.md
-[14]: #create-a-new-plugin
-[15]: #public-exports
+[8]: #handling-issues
+[9]: #reading-the-report
+[10]: #configuration
+[11]: https://nx.dev/concepts/integrated-vs-package-based
+[12]: ./docs/writing-a-plugin.md
+[13]: ./docs/compilers.md
+[14]: ./docs/custom-reporters.md
+[15]: ./docs/handling-issues.md
 [16]: https://github.com/depcheck/depcheck
 [17]: https://github.com/smeijer/unimported
 [18]: https://github.com/pzavolinsky/ts-unused-exports
 [19]: https://github.com/nadeesha/ts-prune
 [20]: #production-mode
 [21]: https://github.com/blockprotocol/blockprotocol
-[22]: https://github.com/RebeccaStevens/deepmerge-ts
-[23]: https://github.com/eslint-functional/eslint-plugin-functional
-[24]: https://github.com/freeCodeCamp/freeCodeCamp
-[25]: https://github.com/RebeccaStevens/is-immutable-type
-[26]: https://github.com/release-it/release-it
-[27]: https://github.com/JoshuaKGoldberg/template-typescript-node-package
-[28]: https://github.com/webpro/knip/graphs/contributors
-[29]: https://contrib.rocks/image?repo=webpro/knip
+[22]: https://github.com/getcursor/cursor
+[23]: https://github.com/RebeccaStevens/deepmerge-ts
+[24]: https://github.com/eslint-functional/eslint-plugin-functional
+[25]: https://github.com/freeCodeCamp/freeCodeCamp
+[26]: https://github.com/RebeccaStevens/is-immutable-type
+[27]: https://github.com/release-it/release-it
+[28]: https://github.com/JoshuaKGoldberg/template-typescript-node-package
+[29]: https://github.com/webpro/knip/graphs/contributors
+[30]: https://contrib.rocks/image?repo=webpro/knip
 [plugin-ava]: ./src/plugins/ava
 [plugin-babel]: ./src/plugins/babel
 [plugin-capacitor]: ./src/plugins/capacitor

package/dist/ConfigurationChief.d.ts

@@ -29,7 +29,22 @@ export declare class ConfigurationChief {
     constructor({ cwd, isProduction }: ConfigurationManagerOptions);
     init(): Promise<void>;
     getCompilers(): [SyncCompilers, AsyncCompilers];
+    getRules(): import("./types/issues.js").Rules;
     normalize(rawLocalConfig: RawConfiguration): {
+        rules: {
+            files: import("./types/issues.js").IssueSeverity;
+            dependencies: import("./types/issues.js").IssueSeverity;
+            devDependencies: import("./types/issues.js").IssueSeverity;
+            unlisted: import("./types/issues.js").IssueSeverity;
+            unresolved: import("./types/issues.js").IssueSeverity;
+            exports: import("./types/issues.js").IssueSeverity;
+            types: import("./types/issues.js").IssueSeverity;
+            nsExports: import("./types/issues.js").IssueSeverity;
+            nsTypes: import("./types/issues.js").IssueSeverity;
+            duplicates: import("./types/issues.js").IssueSeverity;
+            enumMembers: import("./types/issues.js").IssueSeverity;
+            classMembers: import("./types/issues.js").IssueSeverity;
+        };
         include: string[];
         exclude: string[];
         ignore: string[];

package/dist/ConfigurationChief.js

@@ -2,6 +2,7 @@ import mapWorkspaces from '@npmcli/map-workspaces';
 import micromatch from 'micromatch';
 import { ConfigurationValidator } from './ConfigurationValidator.js';
 import { ROOT_WORKSPACE_NAME, DEFAULT_EXTENSIONS, KNIP_CONFIG_LOCATIONS } from './constants.js';
+import { defaultRules } from './issues/initializers.js';
 import * as plugins from './plugins/index.js';
 import { arrayify, compact } from './util/array.js';
 import parsedArgs from './util/cli-arguments.js';
@@ -11,6 +12,7 @@ import { findFile, loadJSON } from './util/fs.js';
 import { getIncludedIssueTypes } from './util/get-included-issue-types.js';
 import { _dirGlob } from './util/glob.js';
 import { _load } from './util/loader.js';
+import { getKeysByValue } from './util/object.js';
 import { join, relative, toPosix } from './util/path.js';
 import { toCamelCase } from './util/plugin.js';
 import { byPathDepth } from './util/workspace.js';
@@ -28,6 +30,7 @@ const getDefaultWorkspaceConfig = (extensions) => {
     };
 };
 const defaultConfig = {
+    rules: defaultRules,
     include: [],
     exclude: [],
     ignore: [],
@@ -88,12 +91,16 @@ export class ConfigurationChief {
     getCompilers() {
         return [this.config.syncCompilers, this.config.asyncCompilers];
     }
+    getRules() {
+        return this.config.rules;
+    }
     normalize(rawLocalConfig) {
         const initialWorkspaces = rawLocalConfig.workspaces ?? {
             [ROOT_WORKSPACE_NAME]: {
                 ...rawLocalConfig,
             },
         };
+        const rules = { ...defaultRules, ...rawLocalConfig.rules };
         const include = rawLocalConfig.include ?? defaultConfig.include;
         const exclude = rawLocalConfig.exclude ?? defaultConfig.exclude;
         const ignore = arrayify(rawLocalConfig.ignore ?? defaultConfig.ignore);
@@ -140,6 +147,7 @@ export class ConfigurationChief {
             return workspaces;
         }, {});
         return {
+            rules,
             include,
             exclude,
             ignore,
@@ -241,9 +249,10 @@ export class ConfigurationChief {
     }
     getIssueTypesToReport() {
         const cliArgs = { include, exclude, dependencies, exports };
+        const excludesFromRules = getKeysByValue(this.config.rules, 'off');
         const config = {
             include: this.config.include ?? [],
-            exclude: this.config.exclude ?? [],
+            exclude: [...excludesFromRules, ...this.config.exclude],
             isProduction: this.isProduction,
         };
         return getIncludedIssueTypes(cliArgs, config);

package/dist/ConfigurationValidator.d.ts

@@ -1,5 +1,7 @@
 import { z } from 'zod';
 export declare const ConfigurationValidator: z.ZodObject<{
+    exclude: z.ZodOptional<z.ZodArray<z.ZodString, "many">>;
+    rules: z.ZodOptional<z.ZodRecord<z.ZodUnion<[z.ZodLiteral<"files">, z.ZodLiteral<"dependencies">, z.ZodLiteral<"devDependencies">, z.ZodLiteral<"unlisted">, z.ZodLiteral<"unresolved">, z.ZodLiteral<"exports">, z.ZodLiteral<"types">, z.ZodLiteral<"nsExports">, z.ZodLiteral<"nsTypes">, z.ZodLiteral<"duplicates">, z.ZodLiteral<"enumMembers">, z.ZodLiteral<"classMembers">]>, z.ZodEnum<["error", "warn", "off"]>>>;
     entry: z.ZodOptional<z.ZodUnion<[z.ZodString, z.ZodArray<z.ZodString, "many">]>>;
     project: z.ZodOptional<z.ZodUnion<[z.ZodString, z.ZodArray<z.ZodString, "many">]>>;
     paths: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodArray<z.ZodString, "many">>>;
@@ -11,7 +13,6 @@ export declare const ConfigurationValidator: z.ZodObject<{
     syncCompilers: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodFunction<z.ZodTuple<[z.ZodString], z.ZodUnknown>, z.ZodString>>>;
     asyncCompilers: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodFunction<z.ZodTuple<[z.ZodString], z.ZodUnknown>, z.ZodPromise<z.ZodString>>>>;
     include: z.ZodOptional<z.ZodArray<z.ZodString, "many">>;
-    exclude: z.ZodOptional<z.ZodArray<z.ZodString, "many">>;
     workspaces: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodObject<{
         entry: z.ZodOptional<z.ZodUnion<[z.ZodString, z.ZodArray<z.ZodString, "many">]>>;
         project: z.ZodOptional<z.ZodUnion<[z.ZodString, z.ZodArray<z.ZodString, "many">]>>;
@@ -1403,6 +1404,8 @@ export declare const ConfigurationValidator: z.ZodObject<{
         project?: string | string[] | undefined;
     }>]>>;
 }, "strip", z.ZodTypeAny, {
+    exclude?: string[] | undefined;
+    rules?: Partial<Record<"files" | "dependencies" | "devDependencies" | "unlisted" | "unresolved" | "exports" | "types" | "nsExports" | "nsTypes" | "duplicates" | "enumMembers" | "classMembers", "error" | "warn" | "off">> | undefined;
     entry?: string | string[] | undefined;
     project?: string | string[] | undefined;
     paths?: Record<string, string[]> | undefined;
@@ -1414,7 +1417,6 @@ export declare const ConfigurationValidator: z.ZodObject<{
     syncCompilers?: Record<string, (args_0: string, ...args_1: unknown[]) => string> | undefined;
     asyncCompilers?: Record<string, (args_0: string, ...args_1: unknown[]) => Promise<string>> | undefined;
     include?: string[] | undefined;
-    exclude?: string[] | undefined;
     workspaces?: Record<string, {
         entry?: string | string[] | undefined;
         project?: string | string[] | undefined;
@@ -1804,6 +1806,8 @@ export declare const ConfigurationValidator: z.ZodObject<{
         project?: string | string[] | undefined;
     } | undefined;
 }, {
+    exclude?: string[] | undefined;
+    rules?: Partial<Record<"files" | "dependencies" | "devDependencies" | "unlisted" | "unresolved" | "exports" | "types" | "nsExports" | "nsTypes" | "duplicates" | "enumMembers" | "classMembers", "error" | "warn" | "off">> | undefined;
     entry?: string | string[] | undefined;
     project?: string | string[] | undefined;
     paths?: Record<string, string[]> | undefined;
@@ -1815,7 +1819,6 @@ export declare const ConfigurationValidator: z.ZodObject<{
     syncCompilers?: Record<string, (args_0: string, ...args_1: unknown[]) => string> | undefined;
     asyncCompilers?: Record<string, (args_0: string, ...args_1: unknown[]) => Promise<string>> | undefined;
     include?: string[] | undefined;
-    exclude?: string[] | undefined;
     workspaces?: Record<string, {
         entry?: string | string[] | undefined;
         project?: string | string[] | undefined;

package/dist/ConfigurationValidator.js

@@ -5,7 +5,23 @@ const syncCompilerSchema = z.function().args(z.string()).returns(z.string());
 const asyncCompilerSchema = z.function().args(z.string()).returns(z.promise(z.string()));
 const compilerSchema = z.union([syncCompilerSchema, asyncCompilerSchema]);
 const compilersSchema = z.record(z.string(), compilerSchema);
+const issueTypeSchema = z.union([
+    z.literal('files'),
+    z.literal('dependencies'),
+    z.literal('devDependencies'),
+    z.literal('unlisted'),
+    z.literal('unresolved'),
+    z.literal('exports'),
+    z.literal('types'),
+    z.literal('nsExports'),
+    z.literal('nsTypes'),
+    z.literal('duplicates'),
+    z.literal('enumMembers'),
+    z.literal('classMembers'),
+]);
+const rulesSchema = z.record(issueTypeSchema, z.enum(['error', 'warn', 'off']));
 const rootConfigurationSchema = z.object({
+    rules: rulesSchema.optional(),
     entry: globSchema.optional(),
     project: globSchema.optional(),
     paths: pathsSchema.optional(),