search

APIDevTools / json-schema-ref-parser

Parse, Resolve, and Dereference JSON Schema $ref pointers in Node and browsers
https://apitools.dev/json-schema-ref-parser
MIT License
952 stars 227 forks source link

Need more maintainers / contributors #285

Closed philsturgeon closed 6 months ago

philsturgeon commented 1 year ago

Hey folks, trying to get a v10 out at the moment but we're blocked on #268 and #283 so if you can get to that I'd really appreciate it.

As a larger thing, I am struggling with doing far too many jobs, including trying to grow an entire reforestation charity which is planting thousands of trees and managing multiple woodlands all over the country. It's a LOT and I cannot be throwing any/much more time on maintaining OSS stuff I don't even use for anything.

See more over here: https://phil.tech/2022/bundling-openapi-with-javascript/

tldr we need to either

  1. get some enthusiastic fresh blood in here as maintainers.
  2. find an alternative library that's got feature party and I'll start the deprecation and redirection process, helping write migration guides.
  3. revive the json-schema-reader rewrite to handle big ticket items like #145.
  4. y'all start throwing a whole load of sponsorship money in here and I'll contract out the work.

Discuss!

philsturgeon commented 1 year ago

There is a new effort from the JSON Schema crew on getting everyone aligned on what $ref is meant to be about, how it should work across OAS and JSON Schema, etc.

https://github.com/json-schema-org/referencing

Probably relevant. No brainspace to try.

philsturgeon commented 1 year ago

Specifically first I would appreciate help getting #288 over the line, more context #290.

jonaslagoni commented 1 year ago

We are still discussing what to do for AsyncAPI (regarding references in general) but wanted to give you our current dilemma, before your deadline, to get your thoughts on the situation @philsturgeon.

The main reason we are looking towards this library is that we need it for our parser (indirectly in Spectral, which we also help maintain).

You can find the full discussion we are having here, regarding requirements for ref resolvers in general, both functional and non-functional requirements, but here is the TLDR (if we were to help out, as the library in its current state dont quite fit into our use-case):

We are of course still discussing requirements and use cases, etc, but did not want to leave you hanging here without providing some feedback before your deadline.

Would love to hear your thoughts on the above "issues" and whether we can get aligned 🙂 Also happy to jump on a call if you'd like a better explanation of our situation.

jcmosc commented 1 year ago

Hey @philsturgeon, curious what the plan here is. I realise I'm asking at the 11th hour...

I recently left my job to focus on building an API design platform this year. So I'm happy to help out as a maintainer. Though my focus for OSS is going to be over at https://github.com/criteria-labs/criteria-api-tools. It's not going to get up to parity for some while yet though as I am prioritising certain features over others.

Though looking at the changes in recent specs, e.g. how $ref is now treated as delegation instead of inclusion, plus differences to OpenAPI Reference and other places $ref appears in OpenAPI. I think a wholesale redesign or new project is inevitable.

philsturgeon commented 6 months ago

Thankfully @jonluca has given this project a new lease of life handling maintenance. I'll leave its future up to them, but I am going to close this issue as the ultimatum is no longer relevant.

relu91 commented 6 months ago

Thankfully @jonluca has given this project a new lease of life handling maintenance. I'll leave its future up to them, but I am going to close this issue as the ultimatum is no longer relevant.

I'm evaluating using this library for a project, does this mean that the warning message in the Readme is now obsolete?

philsturgeon commented 6 months ago

@relu91 yep! removed that message.