When reading yarn docs (the part: Selective dependency resolutions) I found usage case:
Your dependency defines a broad version range and your sub-dependency just got a problematic update so you want to pin it to an earlier version.
So there it is: let's say I installed dependency, and this dependency has its sub-dependencies which are defined by dependency lockfile. When the dependency has defined broad version of its sub-dependency the issue can occur, ie. sub-dependency can be bumped and it can be destructive to its mother dependency (then the whole app goes down) on the fresh install. This means that I have no control over sub-dependency version. On every fresh yarn install it can be very different even though I have my own lock file.
Please help me understand, first of all, even though I have my own lockfile I cannot control sub-dependencies versioning? second, is there a way to control it somehow in order to prevent uncontrolled sub-dependency bumping? Selective dependency resolutions is a way to control it but only after finding that error occurs and setting resolutions for ALL sub-dependencies makes no sense.
Expected behavior: lock sub-dependency to flat versions as it is with first-level dependencies so when fresh install occurs it will install not only exact dependency but also the same sub-dependency on other machine (version control).
Thank you!
