It's generally fine to add new libraries if we think they can't be implemented easily on our side. Can you double check that this new import doesn't cause the SCALIBR binary size to get too much bigger?

Regarding the Go version, do you mean that the lib needs Go 1.23 or beyond? We use Go 1.24 internally so requiring 1.23 or beyond should be fine for us.

Regarding the Go version, do you mean that the lib needs Go 1.23 or beyond? We use Go 1.24 internally so requiring 1.23 or beyond should be fine for us.

Yes that's my read of it - I think bumping the Go version could be a breaking change but either way probably best done in a dedicated PR.

I'm happy to open that and we can continue any related discussion over there

Can you double check that this new import doesn't cause the SCALIBR binary size to get too much bigger?

osv-scalibr on  main [?] via 🐹 v1.22.5 via  v20.11.0
❯ du scalibr-old scalibr-new scalibr-alt
48396   scalibr-old
49512   scalibr-new
49304   scalibr-alt

The scalibr-alt version is built with tidwall/jsonc which was another library I found that could work - I went with the current library to start as it's maintained by tailscale and looks to be actively maintained, but I don't think there's a huge risk if we wanted to use this alt library (which would also be a little nicer as it doesn't return an error, so we'd have one less condition branch)

@erikvarga I have gone ahead with switching out the library since tidwall/jsonc only requires Go v1.16, so this means I can get CI green but happy to switch back to the tailscale library if you're prefer (or look at other alternatives, as there's a couple out there)

@erikvarga I have gone ahead with switching out the library since tidwall/jsonc only requires Go v1.16, so this means I can get CI green but happy to switch back to the tailscale library if you're prefer (or look at other alternatives, as there's a couple out there)

Hm, if using tailscale means we have to wait until Go 1.24 is released so we'll stay compatible with the last 2 versions then maybe we're better off using tidwall/jsonc.

@another-rex @erikvarga it doesn't look like this was landed properly - the import has been changed from github.com/tidwall/jsonc to github.com/tidwall/jsonc/pkg/jsonc, which does not exist so everything errors.

Happy to do a PR changing that back, but not sure if that change was intentional as a result of your internals and that maybe something else should be being done?

The more I think about it, the more I think this was a mistake related to internal vs external handling, so I've opened #420

Oops, I think I messed up the open source package name in our internal transformation rules. I'll have to fix that internally tomorrow (unless OSV folks get around to doing it first)