josephburnett

In terms of side projects, I’ve deliberately curated a smaller set that meets multiple criteria. Social connection, simplicity and elegance, and the ability to start and stop at will.

At work I am always looking for ways to do more than one thing at once. Learn a new skill. Teach something. Solve a small problem. Make myself feel good. Take the solution to the next level.

I think it’s okay to want to always be honing and advancing. Humans are always seeking lower energy paths. Maybe you just need to expand the scope of the skills you’re seeking. One of the most valuable skills in my work is the ability to stop and think about what I’m actually trying to do. That is honed through stopping and observing (meditation).

Yeah that works. But I also wanted the ability to produce JSON Patch and JSON Merge Patch formats. And to support set semantics, identifying objects by specified keys. And it works on YAML too.

> Would be nice to be able to use it as a VSCode extension!

I've added support to use jd as a Git diff engine: https://github.com/josephburnett/jd?tab=readme-ov-file#use-g.... Can you configure VS Code use a custom command to show diffs?

> One feature I’ve yet to see is applying jq query syntax to the jsons before the diff

Will you please add this as a feature request? https://github.com/josephburnett/jd/issues. I would like to hear more about how you would use it.

> When that happens, it computes a very long diff where it could have just said "element is missing at index N".

That's exactly the problem addressed by this issue: https://github.com/josephburnett/jd/issues/50. And I've created a new v2 format to address this and other usecases. The v2 API will compute the longest common subsequence of two arrays and structure the diff around that (a standard way of producing a minimum diff).

I've just released jd 1.9.1 with the `-v2` flag. Would you mind trying one of your use cases to see if the diff looks any better? I should say something exactly like that "@ (some path) - (some element)".

> I would note is that some restructurings with jq increased the quality of the diff by a lot.

I would really like to know more about these restructurings. Would you mind dropping me an example here or at https://github.com/josephburnett/jd/issues please? There are somethings I won't do with jd (e.g. generic data transformations) but I do plan to add some more semantic aware metadata with the v2 API.

Also, I'm glad this tool helped you! Made my day to here it :)

> couldn't this also be have been called jdiff? I feel like the two-letter tool name is exercising developer memory more than strictly required.

Yeah, in retrospect I should have given this a longer name. I was going for a natural fit with `jq`. ¯\_(ツ)_/¯

> I wonder if this is much better than difftastic that is more general purpose, but tree-aware?

There are quite a few good tree-aware JSON diff tools out there. But I wanted one that could also be used for patching. I've tried to maintain the invariant that all diffs can be applied as patches without losing anything. And I also wanted better set (and multi-set) semantics, since the ordering of JSON arrays so often isn't important.