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

lint info-license-strict exception for UNLICENSED #1754

Open
jayvdb opened this issue Oct 7, 2024 · 3 comments
Open

lint info-license-strict exception for UNLICENSED #1754

jayvdb opened this issue Oct 7, 2024 · 3 comments

Comments

@jayvdb
Copy link

jayvdb commented Oct 7, 2024

Is your feature request related to a problem? Please describe.

For an private API, we are using

license:
  name: UNLICENSED

This is used to match the license value recommended in npm docs: https://docs.npmjs.com/cli/v10/configuring-npm/package-json

redocly lint emits warning

License object should contain url field.

Describe the solution you'd like

IMO UNLICENSED should be recognised as not needing a URL.

IMO the lint could also stipulate that UNLICENSED means the identifier field (SPDX) must not be present, as they are mutually exclusive.

Describe alternatives you've considered

Disabling the lint locally is a workaround, but then if someone adds a URL, and it is malformed, the linter will ignore it. Or someone helpfully but incorrectly adds "identifer: Unlicense" that should be blocked by the linter.

Additional context

@tatomyr
Copy link
Contributor

tatomyr commented Oct 9, 2024

I think this does not comply to the OpenAPI specification. To cover your case, you can either suppress that particular warning with the ignore file or write your rule via a custom plugin.

@jayvdb
Copy link
Author

jayvdb commented Oct 9, 2024

Sorry, could you indicate why this doesnt comply with the spec, and which version of the spec you are referring to?

@tatomyr
Copy link
Contributor

tatomyr commented Oct 10, 2024

Oh, sorry, I didn't mean it's against the spec. I was trying to say that that particular case is not described anywhere in the OpenAPI. So for me it doesn't make sense to modify our existing rule.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants