Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Duplicate headers in the changelog #77

Open
jan-molak opened this issue Apr 13, 2017 · 2 comments
Open

Duplicate headers in the changelog #77

jan-molak opened this issue Apr 13, 2017 · 2 comments

Comments

@jan-molak
Copy link

Hey @jpnelson!

I noticed that if a given package has not been changed as part of the commit, its changelog contains a duplicated header of the latest version, but with the current date:

<a name="1.0.1"></a>           <- no change, just another build,
## 1.0.1 (2017-04-13)             yet the header is here



<a name="1.0.1"></a>           <- a change happened here, OK
## 1.0.1 (2017-04-01)

I'm using the independent versioning mode.

@lorenzomigliorero
Copy link

+1

@lorenzomigliorero
Copy link

lorenzomigliorero commented Nov 14, 2018

I @jpnelson , thanks for your work.
I encounter the same bug, headers are duplicated.

These are my last two commits message:

chore(release): releasing component

affects: @malmo/cli@1.0.3

Released from sha 336b1214ac017521c8ea3c235cf89910e2f51811

[skip ci]
Tag for lerna release
fix(yarn): fix module resolution of alias dependencies

affects: @malmo/cli

The first one is auto-generated from lerna-semantic-release pre command.
After launch lerna-semantic-release post this is the content of the generated @malmo/cli CHANGELOG.md:

<a name="1.0.3"></a> // this row is generated by a not relevant commit (releasing component). WRONG
## 1.0.3 (2018-11-14)



<a name="1.0.3"></a> // this row is generated by a relevant commit. RIGHT
## 1.0.3 (2018-11-14)

After investigating, this is the responsible line:

return thisPackage.substring(0, thisPackage.lastIndexOf('@')) === packageName;

What's the purpose of this row, that return a false positive when thisPackage is equal ti @malmo/cli@1.0.3?
I think that this control isn't necessary, but i i'm not aware of all the possible edge case.

Alternatively, replacing this line


with this one return trimmedPackages.split(', ').filter(pkg => pkg.match(/@/g).length < 2);
it's enough, filtering by the @ occurrences exclude the false positive.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants