Skip to content

🚀 Feature: Require schema to be present #935

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

Open
3 tasks done
DaniFoldi opened this issue Mar 5, 2025 · 4 comments
Open
3 tasks done

🚀 Feature: Require schema to be present #935

DaniFoldi opened this issue Mar 5, 2025 · 4 comments
Labels
status: in discussion Not yet ready for implementation or a pull request type: feature New enhancement or request 🚀

Comments

@DaniFoldi
Copy link

Bug Report Checklist

  • I have tried restarting my IDE and the issue persists.
  • I have pulled the latest main branch of the repository.
  • I have searched for related issues and found none that matched my issue.

Overview

Hi 👋,

While this tool does a pretty good job of keeping package.json free of typos by validating the contents, for manual editing a $schema is sometimes useful. Most of my package.json files contain a "$schema": "https://json.schemastore.org/package.json", line so that they can be validated in CI. What do you think about adding a rule that adds $schema to package.json?

Additional Info

No response

@DaniFoldi DaniFoldi added the type: feature New enhancement or request 🚀 label Mar 5, 2025
@michaelfaith michaelfaith added the status: in discussion Not yet ready for implementation or a pull request label Mar 6, 2025
@michaelfaith
Copy link
Collaborator

michaelfaith commented Mar 6, 2025

Seems reasonable to have that as a new rule available for people to opt into, but not included in the recommended config. If we're going to include a fixer that adds it, then probably should have the schema url be configurable. Though our other require-x rules don't have fixers that add anything...
Thoughts?

@DaniFoldi
Copy link
Author

Thanks for the quick response!

I think it makes sense to have it opt-in, quite possibly some people don’t want the schema to be declared in the file.

Looking at the autofix, it’s definitely a more special case as the autofix in other ones doesn’t make much sense, but here the value could be “fixed”, although I don’t see why a config couldn’t contain a rule for requiring a specific license, perhaps in a monorepo. Following this chain of thought, I would definitely make it configurable.

@michaelfaith
Copy link
Collaborator

michaelfaith commented Mar 6, 2025

@JoshuaKGoldberg curious about your thoughts. In general, but especially on the issue of having a fixer for this, since we have traditionally kept the require- flavor of rules purely focused on "does this thing exist or not", rather than having any say about the value of the property. (though, as I type that out, perhaps the validation doesn't check the value, but if we populate a missing value with a fixer, then we could populate it with a particular schema value...)

@JoshuaKGoldberg
Copy link
Owner

🤔 I'm not convinced this is a common or necessary enough practice to justify including in this package.

"Common": This Sourcegraph search for the schemastore string in package.json files shows 292 results right now. That's a teeny fraction of a teeny fraction of the 1.4+ million package.json files Sourcegraph can find.

"Necessary": As I understand it, there are two benefits:

  • Editor intellisense/suggestions: i.e. showing dropdowns
    • This is provided by default for package.json files in most common editors, including Webstorm and VS Code
  • Validation: what is already provided by this package's require-* and valid-* rules
    • If anything is validated by the JSON schema but not by the other rules, I'd think that a bug in the rules

-1 from me right now, but I'm open to being convinced. What real benefits are there for many users from including a $schema property in a package.json file?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: in discussion Not yet ready for implementation or a pull request type: feature New enhancement or request 🚀
Projects
None yet
Development

No branches or pull requests

3 participants