Open Nomeasmo opened 9 years ago
Should we fork s3u/JSONPath?
The thing is it seems the author is not using tags/releases to publish new versions on github (he's probably doing npm only...): autopublish won't be useful in this case, unless we contact the author and take agreement on this.
Think you're right. This repo appears not to be a good source. The original work of Goesser would be, but it is hosted on code.google.com.
Lead me to do further investigations.
Instead of using the original JSONPath implementation I discovered another very promising repo, that uses the JSON Pointer syntax and offers more opportunities and has a versioning in place. flitbit/json-path
Could you check the formal aspects and I create a local package and see if it fits well into Meteor. (Should work, since it is node.js and browser aware and test cases cover my needs)
:+1: seems a good one. If you think it's worth to have, go on!
Let me know when you need the fork...
Here we go, initial version can be found here nomeasmo/json-path.
Still to solve:
If this is not a too complicated task, I'd recommend to lift also the json-ptr into the Meteor Atmosphere.
@splendido I already introduced the meteor package to json-ptr. Could you do a review?
Before I can merge the changes to json-path, we should create a fork from flitbit/json-path and name it json-path
.
Then the MeteorPackaging/JsonPath
can be removed.
I've had a quick look at json-path
and it seems a good work!
...although I'm not a big fan of loading the package's version directly from the package.json
: see here
See how this is done within the makefile for Twix.js.
Improving the build throught the Makefile
could be some added value to make the acceptance probability of a PR higher, but feel free to ignore it.
I've also forked json-path
Committed the initial version. Question, who will create the package then? Is it me using package —create or is it you?
Am 24.03.2015 um 22:09 schrieb Luca Mussi notifications@github.com:
I've had a quick look at json-path and it seems a good work! ...although I'm not a big fan of loading the package's version directly from the package.json: see here https://github.com/MeteorPackaging/json-ptr/blob/master/package.js#L5 See how this is done within the makefile https://github.com/icambron/twix.js/blob/develop/Makefile for Twix.js.
Improving the build throught the Makefile could be some added value to make the acceptance probability of a PR higher, but feel free to ignore it.
I've also forked json-path https://github.com/MeteorPackaging/json-path — Reply to this email directly or view it on GitHub https://github.com/MeteorPackaging/discussions/issues/14#issuecomment-85691353.
Hello @Nomeasmo, I'd say you should create a PR to the author to get official integration. But if you prefer we're also trying out a new way to do it without the need to get the official maintainers involved. See #16.
Before eventually create the new package, lets pick up an organization and make sure meteorpublish
is added among the members
All right,
I’ll try to convince him.
Am 16.04.2015 um 08:41 schrieb Luca Mussi <notifications@github.com mailto:notifications@github.com>:
Hello @Nomeasmo https://github.com/Nomeasmo, I'd say you should create a PR to the author to get official integration. But if you prefer we're also trying out a new way to do it without the need to get the official maintainers involved. See #16 https://github.com/MeteorPackaging/discussions/issues/16.
Before eventually create the new package, lets pick up an organization and make sure meteorpublish is added among the members
— Reply to this email directly or view it on GitHub https://github.com/MeteorPackaging/discussions/issues/14#issuecomment-93657151.
I'd like to have a meteor implementation of the JSONPath library. I build my own local package based on "s3u/JSONPath".
The original code is hosted somewhere in google code. So there are some github implementations around. I've seen repos, that implement node only, some integrate the source directly.
The "s3u/JSONPath" offers tests and works on server and client.