Proposal: Stick to Conventional Commit spec and allow extended types to be configured

[thiagomajesk]

Hi everyone!

Just included this tool as part of my workflow today and have to take my hat off to you guys, it works like a charm.

My team and I have been using Conventional Commits for some time and took the next step to also do semantic releases... However, after setting things up we discovered that the lib is not using the standard spec, but a modified/ mixed version between the Commitlint convention and then old Angular convention + and additional improvement type (which has been discussed here and here and still not agreed upon).

So, the proposal is to use the standard spec types by changing the default_types attribute to default to only feat and fix. In addition to this change, another config called extended_types should be added. This config would allow you to specify extra types to be merged into the default_types attribute, making it easier to extend values as intended by the specification:

- @default_types [
-     build: [
-       hidden?: true
-     ],
-     chore: [
-       hidden?: true
-     ],
-     ci: [
-       hidden?: true
-     ],
-     docs: [
-       hidden?: true
-     ],
-     feat: [
-       header: "Features",
-       hidden?: false
-     ],
-     fix: [
-       header: "Bug Fixes",
-       hidden?: false
-     ],
-     improvement: [
-       header: "Improvements",
-       hidden?: false
-     ],
-     perf: [
-       header: "Performance Improvements",
-       hidden?: false
-     ],
-     refactor: [
-       hidden?: true
-     ],
-     style: [
-       hidden?: true
-     ],
-     test: [
-       hidden?: true
-     ]
-   ]

+ @standard_types [
+  feat: [header: "Features", hidden?: false],
+  fix: [header: "Bug Fixes", hidden?: false]
+ ]

+ @default_types Application.compile_env(:git_opts, :types, @standard_types)

+ @extended_types Application.compile_env(:git_ops, :extended_types, [])

[...]

def types do
-    configured = Application.get_env(:git_ops, :types) || []

    @default_types
    |> Keyword.merge(@extended_types)
    |> Enum.into(%{}, fn {key, value} ->
      sanitized_key =
        key
        |> to_string()
        |> String.downcase()

      {sanitized_key, value}
    end)
  end

Another suggestion that can be part of this proposal is to add a preset option to allow users to automatically opt-in to existing conventions - like the Commitlint or Angular convention that are mentioned in the Conventional Commits website.

PS.: Another thing that I was thinking is that since most of the config types default to hidden?: false, wouldn't it be easier to invert the logic and use visible?: true, while everything else defaults to visible: false when the config is not present? On a side-note, if there are no other options other than header and hidden?, perhaps it would be better to use a tuple to configure that instead of a list.

[zachdaniel]

Ultimately I'd be fine with standardizing the way you've mentioned, but it would involve a major release and/or it would need to be non-default behavior because I wouldn't want to break others' workflow. If that can be accomplished then I'd accept a PR to that effect, including the preset logic.

As for reorienting the config, I'd expect that if it ever grows it would grow as "more metadata per type", which is why it is the way it is now. I'm mostly thinking of users adding their configured types, and I think it's a better experience to see them in the changelog and then decide to hide them vs the other way around. But ultimately I don't care too much as long as the same result is reached 😄.

[thiagomajesk]

Hey @zachdaniel! I did not think about how to release this change, to be honest, but let's figure this out together...

Ideally, this would in fact be a major release... However, we can also include a default preset option that uses your current convention. That way it would be a smooth upgrade to the new version. The only real difference is for people heavily customizing their types (which I don't think is the case). For those users, they'll have to rename to extended_types if they want to merge with the standard options instead of overriding completely, I'd argue that this would be a very reasonable and low-impact change for a major release. What do you say?

As for reorienting the config, I'd expect that if it ever grows it would grow as "more metadata per type", which is why it is the way it is now. I'm mostly thinking of users adding their configured types, and I think it's a better experience to see them in the changelog and then decide to hide them vs the other way around. But ultimately I don't care too much as long as the same result is reached 😄.

Understood! It makes sense to keep how it is then, thanks for the explanation.