Giters

conventional-changelog / conventional-changelog

Generate changelogs and release notes from a project's commit messages and metadata.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

handling of revert commits after recent major releases

travi opened this issue · comments

commented

while working to update semantic-release to work with the new versions, i've noticed that existing tests we had in place around how revert commits were being ignored start failing when upgrading either conventional-changelog-writer or conventional-commits-filter. i don't find details in the release notes that suggest that the handling of revert commits was expected to have changed.

is this an expected behavior difference? if so, could you help me understand the expected updates around this behavior. we have wip beta versions of our impacted plugins and core that solve the majority of the breaking changes, but i'd like to resolve these outstanding updates before promoting those betas to stable.

for reference, here are related isolated updates of the packages i mentioned above to show how they fail:

commented

@travi I will take a look soon.

commented

@travi

  1. transform functions are not equal because they created by preset in load-time, so you can compare them by casting them to string
  2. conventional-commits-filter expects commits in newest-to-oldest order
const commits = [
  { hash: "111", message: "fix(scope1): First fix" },
  { hash: "222", message: "feat(scope2): First feature" },
  { hash: "333", message: "revert: feat(scope2): First feature\n\nThis reverts commit 222.\n" },
- ];
+ ].reverse();
commented

thanks for the fast response!

  1. transform functions are not equal because they created by preset in load-time, so you can compare them by casting them to string

cool, yeah i understood the cause of this one but hadn't worked through handling it yet since it was focused on getting a functional beta out. will be simple enough to deal with getting this resolved

  1. conventional-commits-filter expects commits in newest-to-oldest order

has this always been the case, or was this a change with the latest releases? since this list of commits is hard coded in this test, i can totally understand that it would need to be updated to align with other changes. just trying to understand why this worked before and if it means that i need to dig into other changes. i imagine this just needs to be aligned with the other piece of the puzzle that produces the list of commits, which likely changed together?

commented

@travi This was a change with some of the latest releases

https://github.com/conventional-changelog/conventional-changelog/blob/master/packages/conventional-commits-filter/index.js#L49

I prepared loop to handle streams or async generators, so it can handle commits only in newest-to-oldest order. it will be used in next major upgrade.
I didn't think this could be a problem, because all tools from this monorepo works with commits in that order.

commented

thanks again. that helps me understand what i'm looking for. we can totally handle the change, but this gives me a few more paths to check out on our side to make sure we are handling things as expected from the conventional-commits side