hey, any update on this PR?

@kzantow I don't know to whom to request the review, could you please check the PR?

Nice work, hope some will review it soon

cc @wagoodman or @witchcraze perhaps?

Any update??

Hope someone reviews this soon
cc @willmurphyscode perhaps

I would like to add that OpenCode uses Bun, and not having this is leaving a big gap in SBOM generation and SCA as my org adopts AI tooling. Hopefully, we get eyes on soon :)

While waiting for the review, I started using Trivy because it already supports Bun dependency parsing.

I understand that code reviews are time-consuming and maintainers are often busy. However, after waiting for a long time, I needed a solution that I could use immediately, so I decided to move forward with an alternative.

Thanks for taking a look at the contribution.

@hnnynh - Thank you for the PR and time you've put into this feature. I'm very sorry that no on has answered the pings or gotten 👀 on this one.

We've been dealing with a bit of a deluge of automated/agent PR noise and this very real and very well crafted one fell through the cracks in our review process.

I've got some time today so I can give this a look.

Thank you again for all the effort and thought put into this one and I'll try my hardest to see it's in the next release 😄

@kzantow There are some changes this needs that I'm working on right now:

• naming cleanup for the metadata entry java-script --> javascript
• A small bug I'm investigating around JSONC parsing
• A small bug around variable length package arrays in the bun files

I'll post and tag you on here when those are fixed 😄

SchemaChangeDetector Change Detection

⚠️ Breaking Change Detected - Major version bump

New Schemas

• schema/json/schema-16.1.4.json

I made some small patches for JSONC parsing as well as covered a couple cases where the object data being extracted were not always at consistent positions.

I think there is a larger data modeling question I want to think about and maybe ask @wagoodman at lunch his thoughts.

I'll push my metadata model changes here as well.

@kzantow this one is now ready for a second 🟢 from the tools team

Thanks again to @hnnynh for the contribution.

I didn't leave a formal review since it felt unfair to ask you to potentially make these additional changes after waiting so long for the feedback. Here are the changes I made to get this closer (minus any feedback from my colleagues):

89f6b02 - I noticed in the bun specification that they use JSONC and wanted to make sure we had tests and functionality that could parse that format correctly. I think the original commit handled the bytes and passed them off to the standard go JSON decoding process. I added hujson.Standardize(data) to make sure we converted before that happened and added some JSONC cases to the test fixtures

283c91a - While reading some bun.lock examples I noticed that the type of element/position in the tuples that were values on the package entries could vary by package source. The original code would fail in the case of < 4 entries, causing the whole file to not be cataloged. I think this change get's us to where we can parse the different source tuple shapes while also making us more resilient on any individual weirdness per package that we might encounter.

The other things I changed were just some naming consistency as well as flattening the metadata we're outputting as part of the package that shows up in the syft-json

If you have any questions or if you think I've missed something or made an alteration that breaks your original intent please let me know and I can take a 2nd look.

Awesome 🎉 @spiffcs or @wagoodman can you post the version number in this PR when a release goes out with this change? 😄

Thank you for the review and merge! If this feature added to the next release, I think I can consider Syft again as a tool for SBOM creation.