I would love to see jq libraries become as common as regex libraries so I could use jq directly in whatever stack or environment I'm working on.

Here is a straightforward jq translation

    def stores:
      [
        { "store number" : 1, "state" : "MA" },
        { "store number" : 2, "state" : "MA" },
        { "store number" : 3, "state" : "CA" },
        { "store number" : 4, "state" : "CA" }
      ];
    def sales:
      [
        { "product" : "broiler", "store number" : 1, "quantity" : 20  },
        { "product" : "toaster", "store number" : 2, "quantity" : 100 },
        { "product" : "toaster", "store number" : 2, "quantity" : 50 },
        { "product" : "toaster", "store number" : 3, "quantity" : 50 },
        { "product" : "blender", "store number" : 3, "quantity" : 100 },
        { "product" : "blender", "store number" : 3, "quantity" : 150 },
        { "product" : "socks", "store number" : 1, "quantity" : 500 },
        { "product" : "socks", "store number" : 2, "quantity" : 10 },
        { "product" : "shirt", "store number" : 3, "quantity" : 10 }
      ];
    
    [
        {store: stores[], sale: sales[]}
      | select(.store."store number" == .sale."store number")
      | { nb:    .store."store number",
          state: .store.state,
          sold: .sale.product
        }
    ]

Try it online - https://tio.run/##rZPPUsMgEMbP5Sl2ctIZmklbe6HTg@PZJ8jkkD84Rh...

The difference might be that Brackit uses sophisticated join algorithms for these kinds of implicit joins as known from relational query processing.

I completely agree when your goal is GSD just use the tools you have.

When you have time to sharpen the saw come back and dig into the details of how jq and tools like it work and where their limits are. Looking at the jq builtins[1] can be very enlightening

If you get to the point where your goal is to increase your jq skills I'd recommend looking at the jq questions on Stack Overflow and posting your own solution. Contributing a solution to https://rosettacode.org/wiki/Category:Jq is also good.

1- https://github.com/stedolan/jq/blob/master/src/builtin.jq

"cobbled-together" jq as it often appears in the wild will often compare badly with crafted solutions because the writer's goal is usually GSD and not write pretty code.

People with the time and inclination to slow down and think a little more about how the tools work will produce cleaner solutions.

In your example to convert

    {"name":"foo","vals":[1,2,3]}

to

    {"name":"foo","val":1}
    {"name":"foo","val":2}
    {"name":"foo","val":3}

All you need is this jq filter

    {name:.name, val:.vals[]}

To me this is much better than the proposed zq or jq solution you're using as a basis for comparison. You could almost use the shorter

    .vals = .vals[]

if the name in the output didn't change.

These filters takes advantage of how jq's [] operator converts a single result into separate results. For people new to jq this behavior is often confusing unless they've seen things like Cartesian products.

.[] - https://stedolan.github.io/jq/manual/#Array/ObjectValueItera...

counter point: I reach for jq probably twice a year. It's a slog every time, but way way less work than diving into the terse syntax and understanding the inner workings of jq. A good abstraction is the border of my understanding, a leaky abstraction means I have to have mastery of the internals to be successful. jq is a leaky abstraction.

can also use name instead of name:.name

I think jq is very elegant - genius even - but whenever I use it, I have to look up the docs for syntax. But I guess that's true for any infrequently used tool.

This exactly. I think JQ's problem in this regard is further compounded because its query language just doesn't feel like anything else most people have used, I've certainly never come across anything quite like it, anyway.