<@U016VMY2A72> why did you want to move json match...

# kotest-contributors

[sam]

@Jim why did you want to move json matchers to another repo, I can't remember

[Jim]

Cause I'm working on a json-path-assert analog for kotest so we can have kotest first class kotest native matchers

[sam]

the current json matchers are limited because they use a jvm only json path library ?

[Jim]

They're limited to json because they were initially written in Jackson and I think I've upgraded them to kotlinx serialization, and yeah json path is jvm only

[sam]

ok cool thanks

[Jim]

👍👍 so you want me to hold off on that?

[sam]

nope

[sam]

was just considering suggesting to @Emil Kantis he makes his changes in a copy in that repo

[Jim]

K sounds good

[sam]

then we can deprecate the old ones and he can go crazy with new ones

[Jim]

Yeah that sounds like a good plan. I think it should be separate from the main platform for faster iteration

[Emil Kantis]

Does that mean kotest-assertions-json will move from the main kotest repo? 🙂 compareJsonOptions is good to go otherwise, just need to update docs

[sam]

we could leave the old code there and move all the new code to the new repo

[sam]

then you could even just remove the deprecated stuff outright

[sam]

just an idea

[Emil Kantis]

I'm fine either way 🙂 would feel good to get the stuff out with the next release, but if you prefer to have it in the new repo that's alright.

[sam]

If it goes into the new repo, it can be released immediately

[Emil Kantis]

@Jim is the json-path work already in a repo somewhere?

[sam]

as they're on separate cadences

[Jim]

Nope, it’s all local side-work which is why I’m all for this idea of a new project for me to iterate on

[Jim]

would turn it from a big bang project into more manageable changes

[sam]

right

[Emil Kantis]

whatever is most convenient for you guys! you're free to move, revert, etc, to your hearts content 😄 I don't feel comfortable with setting up a new repo on my own, though

[Emil Kantis]

my last JSON-related PR should be about ready now, just waiting for tests.. 🙂

[Emil Kantis]

just 1 thought regarding json-path.. is it necessarily assertion-related? Wouldn't it make sense that extracting subtrees or values from a JSON document be it's own lib? it could still be used for testing, like.. 🙂

val myJson = """{ "x": [0, 1], "name": "john" }

myJson.jsonPath<Int>("$.x[1]") shouldBe 1
myJson.jsonPath<String>("$.name") shouldBe "john"

Bonus benefit is it could be used with other frameworks, or in production code if someone needs it 🙂

[Jim]

yep, that’s the plan

[Emil Kantis]

btw I would call it extrakt, cause squeezing Kt into the name is apparently bonus points in the community 😄

[Jim]

myJson shouldSatisfy { 
  "$.x[1]".extrakt<Int>() shouldBe 1
  "$.name".extraktString>() shouldBe "john"
}

only parse the json once, cache the paths from the parsed json paths, etc.

[Jim]

gotta force the K in there

[Jim]

I’ve got the front end of the json path compiler done (tokenizing the string), just working on turning the tokens into commands on kotlinx.serialization

[Jim]

I think we should get your code in there with the M2, I don’t think ripping out a bunch of Json stuff is in the cards for the 5.0 release

[Jim]

when extrakt is done we can just forward all of the existing kotest json assertions to the new hotness and deprecate them

[Emil Kantis]

👋 I started playing with this a bit more, felt like a fun thing to write some code for.. Here’s my take on it so far: https://github.com/Kantis/extrakt/blob/main/src/test/kotlin/ExtraktTest.kt

Mind, it’s nothing test specific. I just want to be able to extract any (serializable) type from a JsonElement using a json path expression. Can of course be used to test things as well.

If you want to play with it as well I can give you permissions, or if you want to do something completely different with the name I’ll go ahead and rename it

[Emil Kantis]

Wow.. Github highlighting was terrible for that file 😬

[Jim]

seriously 😂