Is this project alive?

[SamMousa]

Is this project still being actively supported?
I see a lot of open PRs without feedback and a lot of issues that are very stale.

@jeskew, @jamesls I hope you will forgive me for pinging you.

Are you able to do the minimum maintenance (reviewing / merging PRs), are you looking for help in maintaining this, or should we consider forking this library?

[darrenmothersele]

There is further discuss about the status of the JMESPath project here:
jmespath/jmespath.site#65

[glenveegee]

Hi all,

I hope it's not too presumptuous but we've rewritten the entire jmespath.js repo in typescript. It's 100% spec compliant with a few fixes and a bit of tidying up. For all those custom function lovers there's a registerFunction function that lets you add custom functions in a generic way while still having access to the TreeInterpreter and argument validation (see the last few unit tests in jmespath.spec.js)

https://github.com/nanoporetech/jmespath-ts

If you find it a worthy replacement for the current jmespath.js package you're welcome to use it. Even better we'd love any feedback. It's not currently published in NPM. We'll hold off publishing it to npm for now in case there's some feedback about adopting this version. Otherwise we'd be happy to publish it under a different moniker if the community feels it's worth it.

[timharsch]

Hi all,

I hope it's not too presumptuous but we've rewritten the entire jmespath.js repo in typescript. It's 100% spec compliant with a few fixes and a bit of tidying up. For all those custom function lovers there's a registerFunction function that lets you add custom functions in a generic way while still having access to the TreeInterpreter and argument validation (see the last few unit tests in jmespath.spec.js)

https://github.com/nanoporetech/jmespath-ts

If you find it a worthy replacement for the current jmespath.js package you're welcome to use it. Even better we'd love any feedback. It's not currently published in NPM. We'll hold off publishing it to npm for now in case there's some feedback about adopting this version. Otherwise we'd be happy to publish it under a different moniker if the community feels it's worth it.

Since it is typescript,why not just plow forward with it as a separate and distinct library? hopefully you could get it listed on https://jmespath.org/libraries.html as a typescript implementation. Then just let users decide if they want to use jmespath.js or jmespath-ts, I know I would probably choose the one that is both compliant and has the more active community. :-)

[glenveegee]

I was kind of hoping that if it was deemed "up to par" with the other libraries in the jmespath project it would be adopted somehow. I'm happy to hand over the repo to @jamesls. Ideally though, there'd be better access to it so the JS/TS community can push it forward at a faster pace than the jmespath.js implementation. jmespath-ts is spec compliant bit it has already diverged from the spec with the added functionality of registering custom functions. This is in line with many other language implementations and at least allows users an escape hatch to make the library their own. For this, reason I've also created https://github.com/nanoporetech/jmespath-plus which automatically loads in all of lodash functions into jmespath expressions. I'd prefer it they were implemented in the library itself so that the lodash dependency could be dropped. This is effectively a playground for pushing the jmespath expressions etc. to where we need them. It's also open and looking for anyone interested in contributing.

[springcomp]

@glenveegee we at JMESPath Community are currently working on improving the standard and extending the feature set from JMESPath.

We have a set of useful improvements as our next milestone pretty much nailed down.

Our next step is to implement those specifications in the Python library first. As a matter of fact, I'm currently contributing | to | that repository.

Once done, we will either have those PRs accepted there or, most likely, we will implement them in our own fork.

Then we will proceed and submit PRs for inclusion in the AWS CLI and Azure CLI repositories.

I think having a JS implementation like yours - especially as it's written using TypeScript - on par with the specification would be important as well. That's why I would humbly bring to your attention the new features currently being implemented in hope that you might want to include those in your version.