Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
JoshuaKGoldberg opened this issue Sep 20, 2023 · 2 comments
Open

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

JoshuaKGoldberg opened this issue Sep 20, 2023 · 2 comments
Labels
status: accepting prs Please, send a pull request to resolve this! type: feature New enhancement or request

Comments

@JoshuaKGoldberg
Copy link
Owner

JoshuaKGoldberg commented Sep 20, 2023

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.

@JoshuaKGoldberg JoshuaKGoldberg added type: feature New enhancement or request status: blocked Waiting for something else to be resolved labels Sep 20, 2023
@JoshuaKGoldberg JoshuaKGoldberg changed the title Bring in a "require-*" kind of rule Bring in a "require-*"/"no-*" kind of rule Sep 20, 2023
@JoshuaKGoldberg JoshuaKGoldberg added status: accepting prs Please, send a pull request to resolve this! and removed status: blocked Waiting for something else to be resolved labels Nov 6, 2023
@MrHBS
Copy link

MrHBS commented Feb 8, 2024

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
Copy link
Owner Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: accepting prs Please, send a pull request to resolve this! type: feature New enhancement or request
Projects
None yet
Development

No branches or pull requests

2 participants