knip: Automatic plugin enabling fails while in a monorepo

Hello and thanks for the awesome tool!

Currently, knip appears to work by examining the closest package.json file for an eslint dependency. However, this algorithm will fail in a monorepo that looks like this:

my-monorepo/
├── package.json (contains development deps for every subpackage)
└── packages/
    └── foo
        └── package.json (contains only production deps, for the purposes of publishing to npm)

AFAIK, it is common in monorepos to not repeat the ESLint dep for N subpackages. Instead, the ESLint dep is declared once in the root package.json file.

Currently, it is possible to work around this problem by creating a knip.json file for every subpackage in the repo, containing ignore: [".eslintrc.cjs"]. However, this is of course quite cumbersome. It would be nice to update the algorithm such that it can properly detect that ESLint is a dep while inside of a monorepo.

Finally, I’ll note that the same problem applies to the Jest plugin, the Remark plugin, and so on.

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Comments: 17 (17 by maintainers)

Commits related to this issue

Most upvoted comments

that feels wrong, as project-specific configuration belongs in the project-specific directories.

By the way, in general I agree with this sentiment, this is also why Knip features a --production and a --strict flag. Yet it falls apart when we start looking up configuration files in parent directories or dependencies from parent packages. Eventually Knip is full of assumptions and heuristics in a highly dynamic ecosystem.

Will keep this ticket open to track:

  • Improve documentation re. workspace config
  • Throw when --workspace [dir] doesn’t exist