I worry that this change will adversely affect users who are accustomed to not get dev dependencies. We have many issues asking to remove dev dependencies and other similar types in other language ecosystems. I wonder if it's time to add configurations to specify whether or not to add javascript dev dependencies, at least for this cataloger. What do you think?

@kzantow I think it really depends on user needs, for most people, leaving out dev dependencies by default makes sense since it keeps things cleaner and matches what you'd expect in a production sbom, for advanced users who need full visibility into their dependency tree, like for security checks or compliance, having the option to include dev dependencies is super useful, even have field on sbom with dev=true

@kzantow this makes the behavior more like PNPM and NPM lock files - it's yarn files that are now the unexpected exception I believe. There is already a config to change the behavior via ENV vars

Added a needs discussion for today so we can use some livestream time to maybe get on the same page on what merging this looks like.

1. This goes in as is and people start seeing dev dependencies show up in their SBOM (both positive for some and negative for others)
2. We add a commit that adds a configuration for this that defaults to off where the goal of the feature is to keep it open enough so a future PR can add a toggle for all ecosystem (larger design and out of scope for this PR)

The trick here is to land on something that works for the individual yarn lock dev dep detection that could eventually fit into the larger toggle mentioned in 2

@spiffcs just to clarify, this PR already has an IncludeDevDependencies option that defaults to false so nothing changes for existing users, dev deps stay excluded unless turned on