Fix peer dep changelogs - #747
Conversation
Sorry, something went wrong.
🦋 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 |
Sorry, something went wrong.
|
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:
|
Sorry, something went wrong.
| 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?
Sorry, something went wrong.
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.
Sorry, something went wrong.
| 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?
Sorry, something went wrong.
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.
Sorry, something went wrong.
|
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 peerDependency update should not automatically result in a MAJOR bump. In my perception the package that lists a package as a peerDependency should be bumped according to the version bump of the peerDependency 🤔 . peer dependency major -> major bump of dependent peer dependency minor -> minor bump of dependent peer dependency patch -> patch bump of dependent What is the current reason for treating each update of a peerDependency as a MAJOR change? |
Sorry, something went wrong.
* 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 core and cli. a) changesets should try to be smart and safely bump the version range (major -> major, minor -> minor, patch -> patch) My 32 cents. |
Sorry, something went wrong.
This is exactly what #827 proposed as well |
Sorry, something went wrong.
* 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 |
Sorry, something went wrong.
Fixes #746.
This also adds a new dependencyType argument to getDependencyReleaseLine to distinguish peer vs regular dependencies. We want to distinguish them because we currently output a shortened Updated dependencies message 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.