Feature Request: Enhanced Changelog Format Options

[ArvinJ-H]

Is your feature request related to a problem? Please describe. not really

Describe the solution you'd like Currently, Changie supports a standard changelog format, but I'm interested in having additional formatting options to cater to different project structures (monorepo). Specifically, I propose two new formats:

Plugin/Module-Centric Format:

## Plugin-name
## Plugin-name/Module-name
### Added
- Thing added
- Thing added
### Fixed
- Thing fixed
- Thing fixed

or

Category-Centric Format with Module Reference:

### Added
- Module1: Thing added
- Module2: Thing added
### Fixed
- Module1: Thing fixed
- Module2: Thing fixed

Describe alternatives you've considered Each project have their own changelog, run changie batch as normal, but replace changie merge with a custom script

Additional context Closed the other two ticket since they are no longer applicable.

[miniscruff]

I believe the first one is already possible by using components. I can make an example for you later if needed. And the latter might be possible by adding the component to the change format and skipping the component format. Again, I can try it tomorrow.

[ArvinJ-H]

ah i did try to play with components, it did generated something like

### Added
- Module1: Thing added
- Module2: Thing added
### Fixed
- Module1: Thing fixed
- Module2: Thing fixed

But it was prepended to the project specific CHANGELOG.

It will be awesome if you can provide an example

[miniscruff]

Right, components are configured per project if you are using both. However during the merge process we still generate separate changelogs. If you only want to build one changelog you would not use projects, maybe you would use components instead.

I'm not sure I fully understand what you want the final output to be as what I was going to suggest is what you tried.

It sounds like you are using a monorepo, but want a single changelog where components determine which app or system the change took place in. Which is possible using components, without projects.

If the apps are independently released and thus have separate changelogs, you can use the projects feature to handle that. But you will get one changelog per project.

There is not a way to create one changelog while using projects as the whole point of that config is to generate multiple changelogs.

[ArvinJ-H]

ah I see what you mean, sorry it was a bit confusing.

Is it possible to have projects and components coexist, when only one projects requires components during changie new command?

ie. only project plugin requires additional components input

projects:
  - label: 
    key: u1
    changelog: ui/u1/CL.md
  - label: u2
    key: u2
    changelog: ui/u2/CL.md
  - label: plugin
    key: plugin
    changelog: CHANGELOG.md

components:
    - plugin-1
    - plugin-2
    - plugin-3

[miniscruff]

Currently no, projects keep the same global options as all the others. I was on the fence about adding options to the projects configuration as it would definitely greatly expand the complexity of the config. As it is, practically every option in the global config level would be applicable to at the projects level and I wasn't really prepared for that.

[ArvinJ-H]

oh okay.

what was the reason it was not implemented and could this be a feature request?

[miniscruff]

I was unsure if this kind of functionality was going to be useful or not, and I saw how complicated the kind configs got with custom prompts per kind and wasn't sure how much that was to explode the complexity when I started doing the same idea in the project config.

Its quite possible that between projects and some of the formatting I may just need to readjust the config from the ground up.

For me, it wouldn't make sense to just add the one config you need and skip all the other parts that would also apply to projects. But yea, doing all of that would be a lot of work.

[ArvinJ-H]

maybe a bug or user error, when changie is set up something like this

...default settings
kindFormat: "### {{.Kind}}"
fragmentFileFormat: '{{.Component}}-{{.Custom.Issue}}-{{.Time.Format "2006-01-02"}}'

components:
- ...

batch auto seems to be creating the changelog by looping through the unreleased folder, generates change log similar to this (notice the duplicated Changed and Added), the fragments in the unreleased folder have the exact same change kind order

## v1.0.0 - 2024-03-01

### Changed
- Placeholder

### Removed
- Placeholder
- Placeholder

### Fixed
- Placeholder

### Improved
- Placeholder
- Placeholder

### Added
- Placeholder
- Placeholder
- Placeholder

### Changed
- Placeholder

[miniscruff]

maybe a bug or user error, when changie is set up something like this

...default settings
kindFormat: "### {{.Kind}}"
fragmentFileFormat: '{{.Component}}-{{.Custom.Issue}}-{{.Time.Format "2006-01-02"}}'

components:
- ...

batch auto seems to be creating the changelog by looping through the unreleased folder, generates change log similar to this (notice the duplicated Changed and Added), the fragments in the unreleased folder have the exact same change kind order

## v1.0.0 - 2024-03-01

### Changed
- Placeholder

### Removed
- Placeholder
- Placeholder

### Fixed
- Placeholder

### Improved
- Placeholder
- Placeholder

### Added
- Placeholder
- Placeholder
- Placeholder

### Changed
- Placeholder

Ok I think I reproduced the issue, without a Component header it does look funky. With this config change:

componentFormat: '### {{.Component}}'
kindFormat: '* {{.Kind}}'

My steps look like this:

changie new -c UI -k Added -b "placeholder" -m Issue=5
changie new -c UI -k Changed -b "placeholder" -m Issue=5
changie new -c UI -k Removed -b "placeholder" -m Issue=5
changie new -c Backend -k Added -b "placeholder" -m Issue=5
changie new -c Backend -k Removed -b "placeholder" -m Issue=5
changie batch auto
cat ./.changes/$(changie latest).md

Output:

## v4.0.0 - 2024-03-01
### UI
* Added
* placeholder
* Changed
* placeholder
* Removed
* placeholder
### Backend
* Added
* placeholder
* Removed
* placeholder

With this config:

kindFormat: '### {{.Kind}}'
changeFormat: '* {{.Component}} {{.Body}}'

It gives the, not quite correct output of:

## v6.0.0 - 2024-03-01
### Added
* UI placeholder
### Changed
* UI placeholder
### Removed
* UI placeholder
### Added
* Backend placeholder
### Removed
* Backend placeholder

That is, it still groups components first, and then kind. Ideally it would group both UI and backend components under the added/removed kinds since we don't want the component headers.

[ArvinJ-H]

It gives the, not quite correct output of:

## v6.0.0 - 2024-03-01
### Added
* UI placeholder
### Changed
* UI placeholder
### Removed
* UI placeholder
### Added
* Backend placeholder
### Removed
* Backend placeholder

That is, it still groups components first, and then kind. Ideally it would group both UI and backend components under the added/removed kinds since we don't want the component headers.

Ideally we would like the change log to be formatted in this way, is there any work around to not output duplicated Kinds title?

Also, I did for forgot to mention we will have multiple unique entry for the same components, thanks for acknowledge this

[miniscruff]

Ideally we would like the change log to be formatted in this way, is there any work around to not output duplicated Kinds title?

Also, I did for forgot to mention we will have multiple unique entry for the same components, thanks for acknowledge this

Its not that the kinds is being duplicated, its that its trying to output one component at a time, its just that the component format is empty so there is no output for it. The solution here would be to skip sorting/grouping by component if the component format is empty, or some config flag, that way the default kind sorting would include multiple components worth of changes. That is this block here https://github.com/miniscruff/changie/blob/3e31b282849be5f880c75b9d4d7bef440e4bf816/core/change.go#L49-L58.

If instead of checking if components is enabled by len(comps)>0, we instead check if len(compFormat)>0 I think it will fix itself. Let me see.

Edit: Modified the code locally and re-ran the repro steps.

## v7.0.0 - 2024-03-02
### Added
* UI placeholder
* Backend placeholder
### Changed
* UI placeholder
### Removed
* UI placeholder
* Backend placeholder

That is what you are looking for right?

Edit 2: One more point above is that I actually think we should still consider sorting by component in this scenario, but after kind, such that the component updates are grouped together in the kind update. Right now its sorted by time in my test script.

[miniscruff]

Ok, so to summarize.

1. Plugin/Module-Centric Format is supported already if you provide components with a component format?
2. Category-Centric Format with Module Reference is not supported without a feature/bug fix allowing components without a header to maintain kind sorting?

I can make a separate ticket for 2 with a more specific summary and get to that soon. But want to clarify the first one is good to go or answer any questions on that one.

[ArvinJ-H]

1. yes Plugin centric is working as expected, the final form is a bit different to the example I gave, but it is working fine.
2. yes, Kind sorting/combine would be something I call it in a ticket

Just one more request... when the changie config set to components only, can we have an option to also export changelog individually, maybe an optional config like this?

component
- UI
- ui/changelog.md

[miniscruff]

1. yes Plugin centric is working as expected, the final form is a bit different to the example I gave, but it is working fine.

   2. yes, Kind sorting/combine would be something I call it in a ticket

Just one more request... when the changie config set to components only, can we have an option to also export changelog individually, maybe an optional config like this?

component
- UI
- ui/changelog.md

oops forgot to reply, if you need more then one changelog you have to use the projects feature. You could swap components for projects and get that. Components do not have that options and I don't see why I would add them now that we have the projects system.