Define and implement a strategy for "obscure" things like husky + lint-staged

[webpro]

The husky dependency demands to run husky install which adds hooksPath = .husky to .git/config. Then, for example, lint-staged could be executed from an executable script such as .husky/pre-commit.

This means packages like this require another way of finding out whether they're actually used or not:

• husky: look for git config core.hooksPath and see if result (.husky) is existing directory?
• lint-staged: based on the tool used (not necessarily husky!), find it's usage in such a script or config file

Not sure if this is the way to go and/or if it would be enough. And it's just an example, there are more (popular) tools out there that do things differently (not judging). I'm inclined to think it's feasible for Knip to add another type of plugin, or extend the existing plugin system for such use cases.

Just saying, packages can always be added to the ignoreDependencies list to get rid of such false positives.

[webpro]

Done in 73445e8 (v1.5.0)

[kachkaev]

Hmm still seeing husky as an unused dev dependency in blockprotocol/blockprotocol#895 after upgrading to 1.6.1: https://github.com/blockprotocol/blockprotocol/actions/runs/3940673346/jobs/6742082250#step:8:39. What might be missing?

[webpro]

What might be missing?

According to the husky docs:

{
  "scripts": {
    "prepare": "husky install"
  }
}

Or in postinstall. This way, it would be a regular catch for Knip to see husky is used. However, in the blockprotocol repo, husky is not used or referenced anymore, it was only used to install the Git hooks.

Just saying, the job of plugins is mostly to find dependencies of, in this case, husky, which it finds by scanning the Git hooks themselves (which contains the lint-staged dependency in the blockprotocol repo).