[JEP-14] String Functions

[springcomp]

This PR implements JEP-14 String Functions from JMESPath Community

[glenveegee]

Something went wrong here. Looks like a build has overwritten all files in src with compiled JS

[springcomp]

yes, I never managed to run unit-tests from your repo.

I had to make some drastic changes in my port to overcome this:

• Updated tests to TypeScript.
• Updated dependencies to NodeJS 14.
• Removed support for CommonJS.
• Updated rollup / terse plugins and configurations.

By the way, @glenveegee Thanks a lot for doing this.

I needed a version for JMESPath Community to quickly iterate, prototype new features, and power the web site examples but I’m happy of course if yours remain the official version. I indeed have linked to your repository from the npm package.

There are quite a lot of changes yet for me to submit as pull requests to this repo.

To name a few (note to self):

• Unicode handling.
• Reporting and detection of compliant error types.
• Unit tests converted to TypeScript.
• Link to compliance test suite by way of Git submodule.

I also have removed support for pre-Node14 and CommonJS modules as this triggers warnings when using npm install. As rollup is deprecating CommonJS, I figured it made sense.

I have been making a dash of changes lately and will not be able to commit much time in the next few weeks, though.

My goal was to setup key language ports, like Golang, Python and TypeScript because I think we need to have popular implementations to demonstrate the value of JMESPath Community. But I would like to have those ports officially maintained by anyone interested enough to participate in discussions and make reasonable efforts to stay current with the spec and the compliance test suite.

• The Python implementation is currently being proposed for inclusion into the az CLI tool.

• I have relinquished the Golang implementation to @eddycharly from Kyverno, as they see value in that port and have a business model around JMESPath. This has prompted @jamesls to chime in and participate in very promising discussions around lexical scoping.

[glenveegee]

@springcomp would you be happy for me to add you as a contributor to the repo? Not sure exactly how it works in GitHub.

Here at Oxford Nanopore the JMESPath TS lib has served our needs and we'll be migrating our JSON search and filter capabilities to an in-house solution based largely on the JSONata spec. Happy for you to come on board here or just promote for your fork to become the canonical TS implementation.

[springcomp]

Here at Oxford Nanopore the JMESPath TS lib has served our needs and we'll be migrating our JSON search and filter capabilities to an in-house solution based largely on the JSONata spec. Happy for you to come on board here or just promote for your fork to become the canonical TS implementation.

Thanks a lot for this proposal.

Whatever the mechanism, I would like to help ensure long-time maintenance of official language implementations. My role is to apply governance and oversee changes to the specification. I see maintaining language implementations as a necessary job but I’d rather have other official contributors do that.

So I think it’s somehow critical for official language ports to be under the JMESPath Community organisation. This ensures that the project does not become stale and if an official maintainer wants to step down, someone can come along. Without having to re-fork and track who did what at any point in time.

What would work for me if your are comfortable:

• Please, join JMESPath Community organization and become official maintainer of the port over there.
• You will be admin of the project.
• We will rename the npm package to @nanoporetech/… as it always was your version all along.

I think this is a win win:

• You have full control on the feature set above and beyond what is mandated by the spec.
• You keep the "brand" and history of your npm package.
• If ever you can not commit long term, I can arrange for the project to still be maintained and receive progress as the spec changes in the future. Other maintainers could come along, etc.

I have alrady worked using this approach with the golang implementation. I have brought it up to standards and improved it somewhat enough for it to be a viable alternative to the original Golang implementation. This is now maintained officially for the foreseeable future by people at Kyverno as they have more skin in the game than me in this implementation.

Would that work for you?