Bring in dependency banning and/or restricting rule(s)

[JoshuaKGoldberg]

Splitting out from #42: npm-package-json-lint has a family of rules that can ban variants of package dependencies:

• https://npmpackagejsonlint.org/docs/rules/dependencies/no-restricted-dependencies
• https://npmpackagejsonlint.org/docs/rules/dependencies/no-restricted-devDependencies
• https://npmpackagejsonlint.org/docs/rules/dependencies/no-restricted-pre-release-dependencies
• https://npmpackagejsonlint.org/docs/rules/dependencies/no-restricted-pre-release-devDependencies

Additionally, other rules exist in that package and elsewhere for restricting dependency ranges:

• https://github.com/kellyselden/eslint-plugin-json-files/blob/master/docs/rules/no-branch-in-dependencies.md
• https://github.com/kellyselden/eslint-plugin-json-files/blob/master/docs/rules/restrict-ranges.md

I'd like to add in some kind of rule or rules to this package equivalent to those. Not clear yet how they'd look. Should they be one big configurable rule? Granular rules like how npm-package-json-lint & co have them? More thought required.

Blocked on #40. Not a high priority issue given that this wouldn't be enabled by default in any recommended configs. ✅

[MorrisonCole]

I'd love to see this - definitely something missing from the eslint ecosystem at the moment!

https://eslint.org/docs/latest/rules/no-restricted-imports#rule-details might be a good reference too, since it does something similar.

Some granularity would be nice - one thing I've struggled with in large monorepos is gradually phasing out a dependency, which requires having warnings for some dependencies (i.e., those being removed), and errors for others (i.e., those already removed) in parallel.

[michaelfaith]

https://eslint.org/docs/latest/rules/no-restricted-imports#rule-details might be a good reference too, since it does something similar.

This raises a good point about the value of a new rule for this. If the usage sites of a restricted package are being reported using no-restricted-imports what additional value would a rule applied to the package.json for the same package provide? Wouldn't that be reporting effectively the same thing in two different places? I guess one area that this would cover that that rule doesn't, is dev tool packages that are only being used in package.json scripts and not imported somewhere where the restricted imports rule would cover? My main concern is having two different rules firing errors for the same issue.

one thing I've struggled with in large monorepos is gradually phasing out a dependency

The way I would see this going in practice is adding the package as a restricted import using no-restricted-imports, disabling existing usage and gradually reducing usage until it's zero, at which point knip would report the package as unused and it's removed entirely. I.e. the place where this rule would fit in seems rather narrow, unless I'm missing something.