conventional-commits

Is your feature request related to a problem? Please describe.
In a monorepo, I that have a folder with the name "www", however, since I am using git-cliff to generate a public-facing changelog, I would wish for this to be displayed as "Application" when generated.

I am using template replace functions to replace "www" with "Application" but would like the ability to change this in the `co

Description

I have pre-commit hooks to enforce LF line endings, this fails on every commitizen commit as it writes CRLF on windows. An option to configure this would be good.

Possible Solution

Hacky, but I have customized my local commitizen and found all instances of open and added newline='\n' to them if they are w opens. And option in the .cz.yaml to specify this would be the o

Which will behave like that

let settings = await prettyConfig('rollup', { configFiles })

if (!settings) {
  settings = await prettyConfig('rolldown', { configFiles })
}
console.log(settings)

instead of above we can hide it to look like that

const settings = await prettyConfig(['rollup', 'rolldown'], { configFiles })

if (!settings) {
  console.log('no config file

I noticed that it worked fine if I wrote commit messages like chore(versioning): this is a test but if I wrote it like chore: this is a test, it would not take --skipCommitTypes into account

Originally posted by @zeroregard in jscutlery/semver#374 (comment)

We intend to use convco changelog to generate a changelog for a new version / upcoming changes.

The primary intention is to use the generated changelog as the basis for user-facing release notes. We have hidden development-centric sections in the configuration.

However, it could be useful to generate a changelog with these hidden sections too, as insight and a listing for developers.

An a

Maybe it's just a quirk on my machine 🤔

Describe the solution you'd like
Same as #59 with GitHub provider

related to #50

In order to avoid flaky tests would be cool to sort the resulting .Footers map by key.

Ideally, this could be made an opt-in behavior by implementing an option for the parser so as to do not impact at all performances when footers order doesn't matter.