Bring in a "require-*"/"no-*" kind of rule

[JoshuaKGoldberg]

https://npmpackagejsonlint.org/docs/rules#require-node-rules has a bunch of require-* rules for requiring properties to exist, such as require-author, require-bin.

This seems like it'd do well as a general-purpose ESLint rule. It could:

• By default: enforce the required properties that will prompt a warning if missing
• By configuration: be extended to any arbitrary property

Maybe, package-json/require-properties or package-json/require-package-properties as a name? The latter seems a little overly specific, so I'm leaning towards require-properties maybe?

But, what about https://npmpackagejsonlint.org/docs/rules/#disallowed-node-rules? Should we unify into one big rule for requiring which properties do or don't exist?

I also think that https://npmpackagejsonlint.org/docs/rules/required-node/require-scripts can be treated as a subset of https://npmpackagejsonlint.org/docs/rules/scripts/prefer-scripts for this rule. As in, this same rule can require both that scripts exists and what values it contains. Someone please yell at me if that's not ideal.

Blocked on #40, but once that PR is merged this will be good to go. ✅

[TKDev7]

If I am understanding correctly, this way I can lint against adding useless properties for private apps, like author, name, version etc. Is this correct? I am basically trying to come up with the smallest possible package.json scheme for an app.

[JoshuaKGoldberg]

Yup! You'd have to configure the list yourself, as what constitutes as "useless" changes depending on the context.

[michaelfaith]

Maybe one rule called restrict-properties? And it has an array for require and one for disallow? Something like that?

[JoshuaKGoldberg]

Coming back to the require-* kinds of rules, I don't think making a single catch-all require-properties rule is a good idea. Users tend to like to granularly configure things, and disable specific ones as needed.

Also relevant, michaelfaith/package-json-validator#80: splitting up package-json-validator into granular APIs that can each be called by a single rule in this plugin.

I think that leans this package to a nice direction for this issue:

• Granular require-* rules for fields like name, version, etc.
• Granular valid-* rules for those fields too
  • I think these should be separate from require-* - you might have a collection of package.json files that need valid entries for some properties iff they exist
• A single disallow-properties rule for properties that must not exist
• A single require-properties rule for properties that must exist

For the *-properties rules I'm not very deadset that they shouldn't be unified into one restrict-properties.

cc @michaelfaith - thoughts?

[michaelfaith]

What criteria do we use for whether a property should have its own rule vs be configurable in the single umbrella rule? It feels a little odd to have some properties be broken out as dedicated rules while others are configured as part of one big rule. The importance of a property is such a relative thing, where to draw that line becomes challenging. I do agree that granular rules feels a bit more natural, but having some be granular and some not be could be confusing.

[JoshuaKGoldberg]

Agreed, having some be granular and some not would be confusing. Proposal: how about we put all properties in their own rules? That's my preference more and more.

[michaelfaith]

Proposal: how about we put all properties in their own rules? That's my preference more and more.

That sounds good to me. Then there's the other part of the question: should there be separate require- and validate- sets of rules. Personally, I think it makes sense to have those be different things. Taking #786 as an example, having format validation as part of a rule called require-license doesn't seem to line up. So maybe require- rules would just be "does this thing exist or not". In that case, would valid- check that the property exists and check that it's valid, or just checking that if it does exist, it's valid?

[JoshuaKGoldberg]

would valid- check...

I think the latter, just checking that if it does exist, it's valid. 👍 otherwise they duplicate the require- rules.