| Re: [open-regulatory-compliance] CRA Standardisation request |
@Tobie - if you think the lack of idempotency for libraries is troubling, wait til you hear about the new techniques around module federation. ;)
For awareness: The 'lack of idempotency for libraries' problem is not limited to the javascript/npm example. The problem also exists...and is arguably significantly harder...in the install technology used by Eclipse-based projects and products (called 'equinox p2').
But seriously I think the text is a copout from the JS sec team. I agree with Dick, some knowledge is better than none, e.g. in practice, I don’t care what version of jquery is used, if it is in your package.json / lockfile / reposource I will deep dive.I feel that their analysis is missing the fact that a library’s entire dependency tree can be inferred from the package.JSON - and that information IS valuable.
Admittedly it's valuable...but it's also *static*. Just the fact that in osgi/p2 acceptable version *ranges* constraints are given for dependencies means that the target environment (i.e. what else is present at install time as well as what repos are know/available) will determine the dependency resolution....i.e. what version of a dependency is resolved dynamically at install time.
The guarantee of a library is that it will never have dependencies other than direct, indirect, or transitive. Maybe the lesson here is that a library should “presolve” for a known range of upstream library versions that are expected to be viable.
That would also end up being static (across time/new versions of dependencies)...and so would require regular library-level (or lower) maintenance.