Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
chore: clean up yarn resolutions using versioned specifiers (#1596)
#### Details This PR cleans up the repo's use of yarn resolutions: * Removes a few obsolete resolutions * Updates remaining resolutions to take advantage of yarn v3's versioned specifiers In practice, the actual delta of packages we resolve to is: * `hosted-git-info` is downgraded, but not past the version boundary containing security fixes we want to maintain (3.0.8). This is intentional, to avoid accidentally picking up breaking changes unnecessarily * one `lru-cache` version is collapsed away (as a follow-on effect of the `hosted-git-info` downgrade) * `node-fetch` is upgraded slightly (`2.6.7` to `2.6.9`) in one path that wasn't intended to be impacted by its resolution ##### Motivation * Removing obsolete resolutions removes some existing tech debt * Using versioned specifiers avoids issues where we accidentally force changes upon compliant dependency references that we don't mean to touch. For example, this was happening (benignly) in multiple cases in this PR: * `hosted-git-info` was being forced to `>=3.0.8` with the intent of forcing the transitive reference on `^2.1.4` to pick up a fix from 3.0.8, but this was additionally having the unintentional effect of forcing a perfectly fine dependency on `^4.0.1` to pick up a few versions' worth of breaking changes in `6.1.1`. With this update, we now force a version change only for the too-old `hosted-git-info` dependency, and only up to the major version level we've specifically validated is compatible for our usage * `node-fetch` was being forced to `2.6.7`, with the intent of forcing a transitive reference on `2.6.1` to pick up a fix from `2.6.7`, but this was additionally having the unintentional effect of forcing a valid dependency on `^2.6.7` to `2.6.7` instead of the latest version (`2.6.9`). In this case, the fix was just to remove the resolution since we no longer have a transitive dependency on `2.6.1`, but if that transitive dependency still existed, updating the resolution to `"[email protected]": "^2.6.7"` would similarly avoid impacting the undesired package. ##### Context This pattern (`"dependency-name@^original.version.number": "^new.version.number"`) is what I suggest we start using generally going forward; it avoids most of the problems with blanket resolutions mentioned in the Motivation section. The main downside of this pattern compared to the non-version-based ones is that if a dependency chain updates in a way where we'd still want to keep a resolution, but against a different starting version number, the version-based resolution would stop applying where the version-free resolution wouldn't. I think this is a good tradeoff because: * This case is relatively rare - usually, if we're doing a resolution, it's because of a security update, and the next update of that dependency chain is almost always to just pick up the security update we're doing a resolution for * If it did come up, it would be caught very quickly by component governance, whereas the issues that might arise from the version-free resolution wouldn't #### Pull request checklist <!-- If a checklist item is not applicable to this change, write "n/a" in the checkbox --> - [n/a] Addresses an existing issue: Fixes #0000 - [n/a] Added relevant unit test for your changes. (`yarn test`) - [n/a] Verified code coverage for the changes made. Check coverage report at: `<rootDir>/test-results/unit/coverage` - [x] Ran precheckin (`yarn precheckin`)
- Loading branch information
