To fork or not to fork

[SamMousa]

Hey @GrahamCampbell I'm rudely pinging you, I hope you will forgive me.

We've recently switched to the clientside community implementation since the one here is no longer supported.
However we also use this implementation in our backend.

We've found some inconsistencies between the community implementation and the PHP and JS implementations here. In this case the community implementation is correct according to the spec.

My question to you is this: Would you accept PRs that fix spec compliance while breaking consistency with other libraries in this org?

I'd prefer not to fork this to the community org if we can instead maintain it here; on the other hand while you're keeping this alive, it's not being actively developed (no blame, just observation).

What would your preference be? Since we use JMESPath I'm happy to contribute in the form of a fork with the community or by making PRs here; but I'd love your opinion before I make a choice.

The specific issue we're running into is the case of an unquoted string inside a JSON literal:

[?abc == `def`]

Which is supported in this library: https://github.com/jmespath/jmespath.php/blob/master/src/Lexer.php#L432
The fix is easy of course, but we'd break consistency with the JS implementation.

The specification where this is defined lives here: https://github.com/jmespath-community/jmespath.spec/blob/main/jep-012-raw-string-literals.md
Which is obsoleted by 12a: https://github.com/jmespath-community/jmespath.spec/blob/main/jep-012a-raw-string-literals.md

TLDR; would you accept PRs that update this library to newer community specs or do you prefer to keep this implementation consistent with other implementations in this ORG?

[GrahamCampbell]

I think all the implementations should be updated to the current version of the spec.

[SamMousa]

I agree in theory, but we'd need to:

• Approve the 12a spec (which is a community spec) in this ORG, probably by adding it here: https://github.com/jmespath/jmespath.jep
• Update the compliance tests - https://github.com/jmespath/jmespath.test
• Implement 12a for PHP
• Implement 12a for JS -- which is unmaintained
• Implement 12a for Go -- which is unmaintained
• Implement 12a for Rust -- which is unmaintained
• Implement 12a for Python -- which is unmaintained
• Implement 12a for Lua -- which is unmaintained

In practice I don't think that's realistic. There's 5 unmaintained implementations which have no commits for over 3 years; (and most if them do have open issues / PRs).

If this is your position, then I'll go ahead and try to modernize the PHP implementation to see if I can get it into community (and make it compliant to their version of the spec). If you have other ideas on how to achieve your stated goal of making all implementations compliant I'm all ears!