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.
Context
I maintain
eslint-plugin-package-json, which is an ESLint plugin that lints forpackage.jsonfile correctness. It includespackage.json-validatorby way of apackage-json/valid-package-defrule that directly runspackage.json-validator's Node.js API and reports back any complaints.Problem Statement
That strategy technically works for
eslint-plugin-package-json, but:package.json-validatorthat happen to overlap other existingeslint-plugin-package-jsonrulespackage-json/valid-package-defconfiguration: e.g. avoiding only some warningseslint-plugin-package-json's functionality is encapsulated in one ruleTaking a step back,
package.json-validatordoes 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-validatorwere 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-jsoncould make a single configurable rule for each of those checks. It'd still have a dependency on thepackage-json-validatorpackage. We could then deduplicate code so that users can get the same recommendations and warnings either via ESLint plugin or this package.