niclasvaneyk / keepac Goto Github PK

Combines a sidebar on the left showing release versions including dates on the left and the rendered contents of that release on the right. This would basically combine something like https://github.com/charmbracelet/bubbles#list and the output of changelog show VERSION

changelog show | grep something is nice to search for changes, however you often want to know the specific version in which something was added/fixed/etc., so the user likely wants that context:

changelog show | grep new feature I want to use yields

- new feature I want to use

changelog grep new feature should add the necessary context:

## [1.2.3] - 2020-01-01

### Added

- **new feature** I want to use

Potential aliases could be

• changelog find already taken by finding the changelog file
• changelog search

TODO

• Multiline items are not handled properly, e.g. searching for async in https://github.com/siimon/prom-client/blob/master/CHANGELOG.md leads to the code fenced items not being rendered properly

After a release, the CHANGELOG section of that release must not be altered. In case the development workflow of a project is to manually edit the CHANGELOG, it might happen that changes come in:

1. PR is made on main.
2. PR not merged.
3. New release on main.
4. merge into main.

I need a check at step 4 to say: "Frozen CHANGELOG.md section changed". I would implement a CLI like that:

git diff HEAD..main | changelog diffcheck

Returns error level != 0 in case a frozen section is touched.

• Every subcommand has an associated GIF demonstrating its usage
• Maybe switch to https://www.terminalizer.com if it renders better / more representative GIFs
• The GIFs are not too fast (right now they are) and none have errors. Ideally, this could be checked during CI (snapshots or exit codes?)
• Final read through, if everything is up-to-date and makes sense / was actually implemented the way it is described

https://github.com/NiclasvanEyk/keepac/releases/tag/0.1.0 does not contain any .exe (as promised in the README.md). Version 0.0.9 did: https://github.com/NiclasvanEyk/keepac/releases/tag/0.0.9

Would be nicer to simply type changelog and see the changelog, especially when #7 gets implemented

I executed

changelog fix "Fixed ..."

The diff was

 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [Unreleased]
+
+### Fixed
+
+- Fixed ...
+
 ## 1.0.0 - 2021-04-18
 
 Initial public release

There should have been following addition at the end:

+[Unreleased]: https://github.com/koppor/cpdfsqueeze-action/compare/1.0.0...main

The tool should use git to find out the GitHub URL for origin and then "magically" create the URL for the link.

Similar for changelog release. The link for the diff could be generated out of previous links.

Similar to the one of glow

Maybe an excerpt like

## [Unreleased]

### Added

- [...]
- My new changes

or a simple message like done! or Inserted a new addition|deletion|fix|... into the [Unreleased] section?

As per the tagline 👀 👀 👀

There are a few parts in the codebase where there is the exact same logic for the [Unreleased] and past releases, which is mostly copy-pasted.

Maybe the types can be somehow be unified

I'd assume in most of the time you add, fix or change something. Typing

changelog insert --add "some new feature"

is not that big of a deal, however

changelog add "some new feature"

seems more natural.

A more complete list:

changelog add "some new feature"
changelog fix "some bug"
changelog cha[nge] "an existing feature"
changelog rm "an unnecessary thing"
changelog rem[ove] "an unnecessary thing"
chagnelog dep[recate] ""
chagnelog sec[ure] "something critical"

Note: characters in [] are optional, however I think it makes sense to add autocompletion for them. When tabbing:

changelog <TAB>
add
change
deprecate
fix
find
insert
remove
secure

looks way nicer than

changelog <TAB>
add
cha
dep
fix
find
insert
rm
sec

Contra

changelog remove is kind of ambiguous. However, since deleting the CHANGELOG.md file is not a common use-case, I think this should be fine.

One could also argue, that this adds an unnecessary amount of commands, which are already supported by changelog insert.