• Cachi2 detects when yarn.lock has been updated (dependencies added and/or removed) during request processing and fails the request

So, if Yarn only complains if deps need to be added to the lockfile, why do we care about redundant deps if Yarn is okay with them? And if Yarn is okay with them, the user is likely okay with those as well, so we shouldn't present too many obstacles in front of the user if the native tooling isn't posing them either.

Looking at it from the other side - does NOT using --frozen-lockfile update the lockfile so that dependencies can be removed? If so and if we DO want to handle removed dependencies, then I believe we have to stop using --frozen-lockfile and implement our own detection logic, i.e.:

• running this in a temporary clone is a must (that should be the default for us)
• parse the lockfile before and after yarn install and compare

@taylormadore have I missed anything?

why do we care about redundant deps if Yarn is okay with them?

The risk here is that we report the removed dependencies from yarn.lock in the SBOM and yet yarn does not download them to the cache

does NOT using --frozen-lockfile update the lockfile so that dependencies can be removed?

Not using --frozen-lockfile will update yarn.lock (if needed). We could either re-parse the lockfile after running yarn install without that flag or perhaps just hash the file before and after

The risk here is that we report the removed dependencies from yarn.lock in the SBOM

I wouldn't worry too much about the SBOM, it would match the checked-in lockfile after all (well, based on a buggy CLI behaviour of Yarn that we'd rely on), but yes, we strive for a perfect SBOM, so we could technically do better.

and yet yarn does not download them to the cache

Will this cause hermetic builds to fail? IOW if a frozen lockfile doesn't report a problem and since the online yarn install doesn't download removed dependencies to the filesystem cache, will the offline yarn install from that cache be affected in any way? Will it try to reference those dependencies somehow? Because if hermetic builds aren't affected, then the question of how much analysis vs correcting user misconfigurations do we want to perform on our perfect SBOM endeavour arises. Strictly from code perspective blaming this on Yarn and user project configuration seems like the path of least resistance while retaining much of the SBOM integrity and quality.

@taylormadore thoughts ^^? The discussion in this issue kinda blocks resolution and review off #683

Will this cause hermetic builds to fail?

I gave it a quick test and it doesn't appear to

My feelings on this are that it isn't on the critical path, so this issue definitely doesn't need to be done now, but I'm not sure I'd just close it either. This might be something we want to do later, since it doesn't seem particularly complicated to resolve.

This is of course Just my opinion and I won't stand in the way if others feel differently 🙂

I gave it a quick test and it doesn't appear to.
This might be something we want to do later, since it doesn't seem particularly complicated to resolve.

Understood.

Do we want to keep issues around open? I mean at the very least we should try to resolve the issues, so if it's not pressing, we should close it for now until there's an actual use case that would need the functionality. It's not like we'll lose track of it, it can still be re-opened at any time. The problem with too many issues open makes prioritizing and triaging harder IMO.

Closing it is fine with me