-
Notifications
You must be signed in to change notification settings - Fork 84
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
feat: create dedicated ecosystem name enum with all ecosystems #296
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, fyi @andrewpollock & @oliverchang
@@ -296,11 +296,55 @@ | |||
"modified" | |||
], | |||
"$defs": { | |||
"ecosystem": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if changing this ecosystem name will break anyone's workflow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about that, but figured the likelihood anyone is depending on the name specifically right now is pretty low especially given no one seems to have caught how out of date this field actually is 😅
(the name should only matter if you're extending the schema in some way - if you're just using it for validating JSON files then at most it should result in a slightly different error message which shouldn't be depended on anyway)
I've opened #303 adding a script that handles automatically updating the enum and pattern |
Signed-off-by: Gareth Jones <[email protected]>
This introduces a new script to make it easier to ensure all "lists of ecosystems" within this codebase remain up to date, including: - the table in `docs/schema.md` - the Go constants being introduced in #292 - the JSON schema in `validation/schema.json` (both the pattern and the enum being introduced in #296) To make it a bit easier, I've introduced a top-level `ecosystems.json` which is a map of defined ecosystems and a markdown description, sorted alphabetically (which the script also ensures) - I felt this was easier than trying to extract the list from markdown or another source, though it does mean double quotes need to be manually escaped. I went with JSON as it can be read without requiring an external dependency, though if we use Python 3.11 we could switch to `toml` instead as that ships with `tomllib` Example of the workflow output: ![image](https://github.com/user-attachments/assets/aaff0cd4-6387-497f-9869-62ac1b839e58) ![image](https://github.com/user-attachments/assets/057fb2e1-e2ca-4f9b-a704-c116ed69a69f) --------- Signed-off-by: Gareth Jones <[email protected]>
This introduces new dedicated types for the name of an ecosystem (which is an enum) and an ecosystem suffix (which is a string starting with
:
), along with renaming the existingecosystem
type toecosystemWithSuffix
(+ adding it).While these types are not actually used in the schema due to JSONSchema currently does not have a way of specifying that a string is made up of two types, having them defined enables a lot of automation as the current
pattern
based type cannot be used to get a finite list of all possible ecosystems defined by the spec.As an example, here's a TypeScript playground showcasing how you could use the types that would be automatically generated from this new schema structure using
json-schema-to-typescript
(with a manually definedEcosystemSuffix
type, though we can later introduce that for TypeScript specifically by adding atsType
property).Notably, landing this will unblock me adding automation to ensure that all lists of the ecosystem name are in sync (notably, the table in the docs, the enum + pattern here, and soon the constants being added in #292)