yq VS configs

What I often use to just get the full key paths is yq (https://github.com/mikefarah/yq), piping into grep when necessary

  yq -o=props 

For more information about this command visit https://github.com/mikefarah/yq

I've been trying to install and config a plugin (papis.nvim) for a couple of days and am having issues with a function that uses io.popen to run yq to convert yaml files to json. I know my install of yq is fine- I can run yq -oj info.yaml from the command line with no issue and it produces the correct json output. I know the function can find the yq executable, but it returns nil. I've saved the error from the yq golang code: panic: runtime error: invalid memory address or nil pointer dereference

- yq has no if-then-else https://github.com/mikefarah/yq/issues/95 which is a poor design (or omission) in my opinion

After which, I use openapi-generator to make a yaml output.

https://gist.github.com/freshteapot/3637e8d2b5ecdf01b7d25246...

- yq version 3.4.1 (Worth noting, the example uses an out of date yq, so a few modifictaions might be needed)

https://github.com/mikefarah/yq

For those pining for a similar yaml query tool for working through acres of config: https://github.com/mikefarah/yq

jq is awesome and thanks to the new team for their recent efforts and energy, it massively appreciated.

For anyone looking for such a script, there's some CLIs that make it easy. One is `yq -o props` [1], another way is to use `yq -j` or `yj` [2] to convert to JSON and pipe it to `gron` [3].

[1] https://github.com/mikefarah/yq

[2] https://github.com/sclevine/yj

[3] https://github.com/tomnomnom/gron

I was a long time pre-commit fan, just converted to https://trunk.io/ though

Trunk | https://trunk.io | Sr Full Stack / Sr C++ | Full-Time | Remote / Hybrid, SF

Trunk is an a16z funded dev tools startup, redefining software development at scale. We've built three products so far and have plans for more:

* Trunk Check: a universal linter/formatter, available as a CLI, VSCode extension, and CI check;

Trunk is also a command line tool, so you can run all these checks on CI, with the same versions of tools you use locally

Tests are a good way to assert an invariant that you expect of your codebase, but as with all things, resolving the error can get a bit tricky/frustrating.

The canonical example in my mind is any kind of autofix-able linter, where there's some kind of patch (or more nuanced autofix) that the linter can generate on-the-spot for you. With a sh_test construct (or any other unit test), you generally find yourself printing out some command that the user can run to fix things, which in a sufficiently large codebase can get really frustrating.

(My company - https://trunk.io - is actually building a universal linter as part of our product offering, and we already have a system to write custom linters with varying levels of sophistication that can plug into both your IDE and CI system.)