🚀 Feature: Expose granular API for consumers like eslint-plugin-package-json

[JoshuaKGoldberg]

Context

I maintain eslint-plugin-package-json, which is an ESLint plugin that lints for package.json file correctness. It includes package.json-validator by way of a package-json/valid-package-def rule that directly runs package.json-validator's Node.js API and reports back any complaints.

Problem Statement

That strategy technically works for eslint-plugin-package-json, but:

• Sometimes feature requests come into package.json-validator that happen to overlap other existing eslint-plugin-package-json rules
• It'd be difficult to add granular package-json/valid-package-def configuration: e.g. avoiding only some warnings
• It's confusing how a lot of eslint-plugin-package-json's functionality is encapsulated in one rule

Taking a step back, package.json-validator does more than just check for a "valid" package file. It also gives warnings and recommendations that are more akin to linter warnings.

Proposal

What if package.json-validator were to additionally expose individual API functions for each of its checks? Then consumers could use the individual API piece they want as needed.

In this case, eslint-plugin-package-json could make a single configurable rule for each of those checks. It'd still have a dependency on the package-json-validator package. We could then deduplicate code so that users can get the same recommendations and warnings either via ESLint plugin or this package.