[Feature Request] respect 'defaultScope' when using scope list

[jaklan]

💭 Describe the feature

Currently, when you provide the list of accepted scopes in the config, you select one in prompt by moving with arrows. The first scope highlighted is the first scope provided in the list. defaultScope option has no effect.

💡 Proposed Solution

My proposal would be to actually respect defaultScope, so that you can set its value to one of the accepted scopes and move it to the top of scopes list, so it becomes the first one proposed.

If the defaultScope value is not in the scopes list, we can ignore it / show some error.

[Zhengqbbb]

My proposal would be to actually respect defaultScope, so that you can set its value to one of the accepted scopes and move it to the top of scopes list, so it becomes the first one proposed.

My design at the time was, defaultScope My initial thought was to use it as the default value of custom

move it to the top of scopes list

Awesome suggest !~ I like that. 😀

[jaklan]

@Zhengqbbb ah, I see. In case of "scope-enum": [2, "always", ...] we are in home, because custom is disabled anyway:

It will automatically detect whether the definition of the commitlint rule scope-enum is strict, and it will not be displayed automatically.

[#](https://cz-git.qbenben.com/guide/option-engineer.html#allowemptyscopes)

but then there's a question what about the warning mode ("scope-enum": [1, "always", ...]) and what about enabling custom scopes explicitly.

Maybe we can just split that one into 2 options: defaultScope and defaultCustomScope or defaultScope and defaultScopeEnum?

[Zhengqbbb]

but then there's a question what about the warning mode ("scope-enum": [1, "always", ...]) and what about enabling custom scopes explicitly.

A principle, if you set it to warning, then I will not hide custom, if you set it to error, strict, I will hide it. After all this is whether commitlint affects the commit. We are just an auxiliary generative role.

Maybe we can just split that one into 2 options: defaultScope and defaultCustomScope or defaultScope and defaultScopeEnum?

I think it is enough to use one, and there is no need to come up with another concept. After all, the display of custom default values here is just an example of input.

[jaklan]

@Zhengqbbb btw I found one bug:

    rules: {"scope-enum": [2, "always", ...]},
    allowCustomScopes: true,
    customScopesAlias: "general",
    customScopesAlign: "top",
    allowEmptyScopes: false,
    defaultScope: "general",

At the moment we get:

(optional) here is incorrect, because we allow custom scopes, but not the empty ones. And unfortunately we can set empty scope this way, which shouldn't be allowed:

[jaklan]

Ach wait, I forgot the message is fully static, so the (optional) part as well - I just fixed that with overwriting the message. But the issue with no validation of empty scope despite allowEmptyScopes: false is still actual 😄

[Zhengqbbb]

The latest version 🌟(v1.2.4)🌟 should be resolve this issue request , please have a try. 💪
👀 Let me know if there are still any issues. Thanks for reporting it! 🎉

[jaklan]

@Zhengqbbb tested, seems to work! 🎉