oscarotero / keep-a-changelog Goto Github PK

Hi,
if I use the CLI I cannot customize the compare links / tags links. Is is possible to add an CLI option to change to GitLab urls?

GitLab compare links: https://gitlab.com/gitlab-org/gitlab-runner/-/compare/0.4.0...0.4.1
GitLab tag link: https://gitlab.com/gitlab-org/gitlab-runner/-/tags/v16.0.0
Note the dash between repository URL and compare and tags.

AFAIK GitLab does not support HEAD to compare unreleased commits. We could use main as default.
Thanks.

Hi @oscarotero ,

I'm wondering what's the reason for enforcing v prefix prior to the version number when generating compare link at https://github.com/oscarotero/keep-a-changelog/blob/master/src/Release.js#L149 .

        if (!this.version) {
            return `[Unreleased]: ${changelog.url}/compare/v${next.version}...HEAD`;
        }

        if (!this.date) {
            return `[${this.version}]: ${changelog.url}/compare/v${next.version}...HEAD`;
        }

        return `[${this.version}]: ${changelog.url}/compare/v${next.version}...v${this.version}`;

Could this be a keep-a-changelog or semver requirement by any chance?

My use case scenarios are a) the tag is exactly the version value, and b) the tag has a custom prefix then the version value. I'm totally fine if, for scenario b), the custom prefix has to be considered as the version.

Any thoughts on how to best tackle this?

Hello, I recently found this project today, and it was really helpful in my O.S.S projects with Deno, thanks.

However, when installing it I did find some bugs.

The first one is the Deno URL. It should be https://deno.land/x/[email protected]/mod.ts but it has a typo in the readme. it's missing the v in the version number.

The second thing is not a bug but more of a request. Could you please change the access modifiers on some of the classes to private? Its hard to tell which ones are usage functions vs variables.

Example:

export default class Release {
  changelog?: Changelog;
  version?: Semver;
  date?: Date;
  description: string;
  changes: Map<string, Change[]>;
 }
 All these methods can be assessed for no reason and other util functions on the class. It would make it more simple to script the change logs if some were set to private or protected, thanks.

Hi @oscarotero. Aren't the following versions in the changelog bad?
https://github.com/oscarotero/keep-a-changelog/blob/master/CHANGELOG.md?plain=1#L9-L15
They should be 2.4.0 and 2.4.1, not 3.4.0 and 3.4.1 ;) To npm you pushed version 2.4.1.

Thanks for this great library, we were trying to use it with Deno 1.11 and saw the following error:

Check https://raw.githubusercontent.com/oscarotero/keep-a-changelog/deno/bin.js
error: TS2339 [ERROR]: Property 'operator' does not exist on type 'never'.
    if (high!.operator === comp || high!.operator === ecomp) {
              ~~~~~~~~
    at https://deno.land/x/[email protected]/mod.ts:1744:15

TS2339 [ERROR]: Property 'operator' does not exist on type 'never'.
    if (high!.operator === comp || high!.operator === ecomp) {
                                         ~~~~~~~~
    at https://deno.land/x/[email protected]/mod.ts:1744:42

TS2339 [ERROR]: Property 'operator' does not exist on type 'never'.
      (!low!.operator || low!.operator === comp) &&
             ~~~~~~~~
    at https://deno.land/x/[email protected]/mod.ts:1751:14

TS2339 [ERROR]: Property 'operator' does not exist on type 'never'.
      (!low!.operator || low!.operator === comp) &&
                              ~~~~~~~~
    at https://deno.land/x/[email protected]/mod.ts:1751:31

TS2339 [ERROR]: Property 'semver' does not exist on type 'never'.
      ltefn(version, low!.semver)
                          ~~~~~~
    at https://deno.land/x/[email protected]/mod.ts:1752:27

TS2339 [ERROR]: Property 'operator' does not exist on type 'never'.
    } else if (low!.operator === ecomp && ltfn(version, low!.semver)) {
                    ~~~~~~~~
    at https://deno.land/x/[email protected]/mod.ts:1755:21

TS2339 [ERROR]: Property 'semver' does not exist on type 'never'.
    } else if (low!.operator === ecomp && ltfn(version, low!.semver)) {
                                                             ~~~~~~
    at https://deno.land/x/[email protected]/mod.ts:1755:62

Found 7 errors.

Great tool!

I understand it supports the Types of changes based on https://keepachangelog.com/en/1.0.0/
However, I think that a change of those "Types of changes" could be beneficial to many users. For example some could add a "Upgrade" type or anything else...
Well, it was discussed a while back here brightcove/kacl#6 But with no additional initiative it seems...

Is this something that would be considered?

Solution proposals:

1. probably the easiest: don't change implementation. the Release class can be extended. Just cover it by a test and mention in documentation, so people can rely on it.
2. based on point 1. - Have an Additional class ReleaseBase that could e.g. accept another parameter in constructor to define the types. Additionaly, ReleaseBase does not include methods like added, changed etc. Release class would extend ReleaseBase . It still doesn't introduce any breaking changes.
3. Change the current Release class to accept optional parameter for types (in constructor). No way to add new methods for specific change types.
4. Have an additional method in Release class setTypes. That just doesn't seem right

The parsing fails to parse "yanked" releases:
https://github.com/FayneAldan/SVRichPresence/blob/80996477c83571a163b74d37fe778579f3f40f3b/CHANGELOG.md?plain=1#L110

Parse error in the line 111: Syntax error in the release title

There's also no way to add a yanked release in the API.

Yanked releases are mentioned in the Keep a Changelog FAQ.

Hi! Thanks for this tool.

We're using the changelog command to ensure our CHANGELOG.md is formatted properly. At the moment, if the file cannot be parsed, it just prints out the error in red. It'd be nice to have an option so it exits with non-zero code. That way we can run the command as part of our CI builds.

I'm good to contribute if you're happy with the idea.

Cheers!

Scenario

I'm using both keep-a-changelog and Prettier, with a CHANGELOG.md file, and I've hit an issue between them:

1. keep-a-changelog parses CHANGELOG.md and generates links at the bottom of the file, as expected. Those links are longer than the printWidth we've set for Prettier.

[2.0.0]: https://my-very-long-url/v1.2.3..v2.0.0
[1.2.3]: https://my-very-long-url/v1.2.2..v1.2.3

2. Prettier runs and wraps long lines -- including the links at the bottom

[2.0.0]:
  https://my-very-long-url/v1.2.3..v2.0.0
[1.2.3]:
  https://my-very-long-url/v1.2.2..v1.2.3

3. The next time keep-a-changelog parses the changelog, it doesn't recognize those links because they aren't on a single line: they're tokenized as paragraphs and indented appropriately. At that point it looks like the document has no links at all, so all h2's in the changelog get de-linked.

Possible solution

Adding our changelog to .prettierignore did avoid this, as did disabling it with proseWrap (suggested in their issue #4709), but the line-wrap is handy for the rest of the document so I'd prefer to keep it.

Locally, I was able to resolve this by having keep-a-changelog's parser recognize multi-line links:

// src/parser.js:137
if (line.match(/^\[.*\]\:$/)) {
  const nextLine = allLines[index + 1]
  if (nextLine && nextLine.match(/\s*http.*$/)) {
    // We found a multi-line link: treat it like a single line
    allLines[index + 1] = ''
    return ['link', [line.trim() + nextLine.trim()]];
  }
}

(I just split the 'link' regex into two parts, and updated the loop to .map((line, index, allLines))

That worked very well for my use case. My questions are:

1. Is there a better way to do this, while keeping Prettier? I played around with prettier-ignore and a few other options, but the above solution worked best for me.
2. Would this change work for other projects, generally? I'm happy to submit a PR if you think it'd be beneficial.

Currently, the following entry fails to parse:

## [Unreleased]
This is a brand new releases with:
- Configuration is now done within the Web client, for authorized users.
### Added
- New configuration screen

It seems that the description can only be a <p> tag as parsed. Could it be anything before the first matching change type?

I'd like to run a command which releases the Unreleased section.

e.g. before:

## [Unreleased]
### Added
- feature1
- feature2

after:

## [Unreleased]

## [1.2.3] - 2021-03-01
### Added
- feature1
- feature2

yarn changelog --release doesn't seem to do this. My changelog gets normalized, but nothing else seems to happen.

As recommended in https://keepachangelog.com/en/1.0.0/#effort the [Unreleased] section should be kept at the top even if empty.

Currently, when calling changelog --release 2.0.0, the [Unreleased] is removed.

Hi,

Thanks for this useful tool to generate changelog.

Could you modify the generated markdown to follow the rules defined by markdownlint to enforce consistency in Markdown files.

Currently the two rules that are not respected are:

• Lists should be surrounded by blank lines
• Headings should be surrounded by blank lines

There should be a method in the Release class to set the release as "Yanked"

The changelog command seems to add a non-standard newline near the top of the CHANGELOG file below # Changelog.

The example changelog here links to the first version, too. The link is to:

[0.0.1]: https://github.com/olivierlacan/keep-a-changelog/releases/tag/v0.0.1

This package removes such link.

Thanks for the great framework. It would be great if you could include typings with your releases.

I prefer to have newline after headings, but this package removes one. Could that be an option to keep or even enforce?