Fix peer dep changelogs - #747
Conversation
🦋 Changeset detectedLatest commit: 7687aa6 The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit 7687aa6:
|
e1dcaea to
db6a2a2
Compare
| dependentReleases, | ||
| changelogOpts | ||
| changelogOpts, | ||
| "dependencies" |
There was a problem hiding this comment.
If I read the code correctly this could actually be also caused by an optional dependency.
q: do you plan to utilize this new argument in your code?
There was a problem hiding this comment.
Releases only contain packages specified in the dependencies and peerDependencies fields of package.json so I don't think optional dependencies would be included here unless they were also specified in dependencies which isn't recommended behaviour.
We're planning to use it to distinguish peer dep upgrade lines from non-peer dep ones so that we output a more detailed message for major peer upgrades.
This distinction could also be made using a bumpType or isPeer argument instead.
| updateInternalDependencies: "patch", | ||
| ignore: [], | ||
| ___experimentalUnsafeOptions_WILL_CHANGE_IN_PATCH: { | ||
| onlyUpdatePeerDependentsWhenOutOfRange: false, |
There was a problem hiding this comment.
Out of curiosity - so I assume that you are still using this default setting, doesn't it create major releases for you way too often?
There was a problem hiding this comment.
Yeah we are. It does for packages that have peer dependencies that upgrade frequently yes. The alternative though is that the minimum versions of peer dependency version ranges become stale which can break things, especially with aggressive de-duplication.
It probably is worth re-exploring though.
|
I have another question that is potentially related to this PR. I also noticed that changesets planned MAJOR releases, in which only PATCH updates were listed. After some research and finding this issue, I now understand that peerDependency updates are currently treated as MAJOR updates, but incorrectly listed as PATCH dependencies within the generated CHANGELOG.md file. My first thought is that a What is the current reason for treating each update of a peerDependency as a MAJOR change? |
* chore: patch changesets for treating peer dependencies different (according to changesets/changesets#747 (comment)) * chore: update lockfile * chore: bust cache? * fix: remove restore keys and incoporate patches into cache key * chore: change cache strategy
|
Two packages a) changesets should try to be smart and safely bump the version range (major -> major, minor -> minor, patch -> patch) My 32 cents. |
This is exactly what #827 proposed as well |
* chore: patch changesets for treating peer dependencies different (according to changesets/changesets#747 (comment)) * chore: update lockfile * chore: bust cache? * fix: remove restore keys and incoporate patches into cache key * chore: change cache strategy
|
closing as stale, and because we are updating the bump type of peer dependents in #2090 |
Fixes #746.
This also adds a new
dependencyTypeargument togetDependencyReleaseLineto distinguish peer vs regular dependencies. We want to distinguish them because we currently output a shortenedUpdated dependenciesmessage to prevent changelog noise from the sheer number of dependencies that our atlassian-frontend repo has. Peer dependency upgrades are more important as they trigger a major release and so we want to output the specific dependencies and their versions for peer upgrades and only peer upgrades.