thomaseizinger/keep-a-changelog-new-release

Bug: Modified spacing for Markdown lists in the Changelog

Closed this issue · 8 comments

vikin91 commented

TL;DR: This action adds two extra spaces to each markdown-list element in the changelog.

Currently, when processing the following example:

## [Unreleased]

This release does one thing

### Added

- List with one space

The action produces the following output:

## [Unreleased]

## [v0.0.9] - 2021-04-03

This release does one thing

### Added

-   List with one space

However, the expected output is:

## [Unreleased]

## [v0.0.9] - 2021-04-03

This release does one thing

### Added

- List with one space

Literally, it adds two extra spaces for each list item.
It changes (_ denotes a space):

-_List with one space

into

-___List with one space

I think the list entries should remain unmodified due to the following reasons:

  1. https://keepachangelog.com/en/1.0.0/ defines them with a single space
  2. Using 3 spaces triggers markdown-lint warning: MD030/list-marker-space: Spaces after list markers [Expected: 1; Actual: 3] markdownlint (MD030)

It would be great if this could be fixed 🙂

thomaseizinger commented

Thanks for the report!

This is unfortunately a known issue without a good solution at the moment. See #7.

vikin91 commented

So I guess, the status here is won't fix, or?
Maybe it is worth to keep the bug report open and invite someone to give it a look?

thomaseizinger commented

Sure!

Happy to keep it open :)
Should probably also document it in the README as a known problem!

rcdailey commented

I had to stop using this action because of this issue. I need my changelog to be updated perfectly since it's hands-free. I do not get a chance to manually edit and fix these issues.

thomaseizinger commented

Are you enforcing the formatting of your markdown files as part of CI?

If yes, then I'd recommend to just run the formatter after this action. That is what we do in some of our repositories.
If no, then I don't see why the reformatting is such a big deal. You could simply adopt the new formatting.

I'd love for this action to not make any formatting changes but I currently don't have the bandwidth to deal with it. Given that it is easily fixable by running a formatter afterwards, it is also fairly low priority.

vikin91 commented

I also use this action as one of the last elements in automated release chain. The code is not touched by a human afterwards (it theoretically could be corrected by human in the release-PR but this is annoying).

@rcdailey did you find other action that is not affected by this problem?

rcdailey commented

I was not able to find and formatters in github actions. If you have one in mind please let me know.

thomaseizinger commented

Personally I am using dprint: https://dprint.dev/

There is also a GitHub action for checking the formatting: https://github.com/dprint/check
To my knowledge, there isn't a GitHub action for formatting but it is reasonably easy to invoke: https://github.com/comit-network/xmr-btc-swap/blob/a8fb344fc8cfb139f1852057a81db9bd7d427e15/.github/workflows/draft-new-release.yml#L45-L46

dprint/check is just a composite action, hence if someone is motivated, it should be easy enough to create dprint/fmt based on that!