[FEAT] Add conventionalCommits.types so its possible to change the default types.

[fenilli]

Is your feature request related to a problem? Please describe. Its not necessarily always a node project that uses conventional commits, meaning that its not always possible nor needed to install @commitlint/config-conventional and use commitlint.config.js.

Describe the solution you'd like Just by adding the same pattern used for scopes would fix the issue, meaning that you could add to vscode settings:

conventionalCommits.types = [
    "chore",
    "docs"
]

Describe alternatives you've considered Adding @commitlint/config-conventional as global using npm, and creating a "useless" commitlint.config.js file that is inside .gitignore.

[fenilli]

It also could be an object for local localization and be an improvement for the current conventionalCommits.scopes.

// This makes possible to use the same pattern for both types and scopes.
conventionalCommits.types = [
    {
        "item": "chore",
        // an object that uses i18n pattern
        "localization": {
            "en": {
                "title": "chore item",
                "description": "an chore item that has a cool description"
            }
        },
    },
    // not localized showing only the name.
    "docs"
]

[yi-Xu-0100]

👋 @GustavoFenilli I think this is a good option for the types, but I have some different opinions about the localization. I think the localization may be useless.

1. It is useless for the user setting. It can just set the title and description in the user locale language.
2. Furthermore, it is better to set the title and description in en in an international project. More localization for project developers is not necessary.

@vivaxy I think the setting could be like the following. 🤔

"conventionalCommits.customTypes": {
  "chore": {
    "title": "chore item",
    "description": "an chore item that has a cool description"
  },
  "docs"
}

And add some options for setting the type selection.

1. An option to disable the scope prompt. (#43)
2. An option to add the custom types.
3. An option to disable all the default types.

And the same type occurs in custom types and the default types, it will prefer to use the custom types and find out the default localization when the custom types missing the setting for title and description. Furthermore, it will not show the title and description of an unknown type without a setting.

---

@vivaxy By the way, I can try to take over it and make a PR, but I can not promise the time that I complete it. 😁

[fenilli]

@yi-Xu-0100 Now that you said, yes it kinda does makes no sense the localization I suggested, as its a custom property for a single project.

The only thing I would add to that is maybe the possibility for reading a .json file as configuration, as I stated conventional commits aren't always for javascript projects so config.js is out of the question, and if the use is more focused on a team, or a open source project, people would likely need to share custom types and scopes, so it adheres to the projects commit naming conventions.

About your points of add:

1. That is indeed a nice to have as sometimes you don't have any scope inside your project (#43)
2. I don't think its needed to have custom types clash, meaning if I added types to it, those are it, I only want mine and the base that are needed by the convention ( feat, fix ).
3. That is also a nice to have, if no types are user defined, and I only want the convention ones ( feat, fix ) I should be able to disable.

So with this in mind, the checking about if there is both user and default types clashing, it would always prioritize custom and never look for title and description for defaults, as maybe chore in my project and mind could have a different idea that is used inside the default chore title and description.

[vivaxy]

👋 @GustavoFenilli @yi-Xu-0100 Thank you for your suggestions. It's nice to have those options. @yi-Xu-0100 Feel free to take over and make RPs. 😃

[yi-Xu-0100]

@GustavoFenilli I think it should set the title and description for types even you want to set them as empty.

"conventionalCommits.customTypes": {
  "chore": {
    "title": "chore item",
    "description": "an chore item that has a cool description"
  },
  "ci": {
    "title": "",
    "description": ""
  },
  "docs":{},
  "unkown1":{
    "title": "title for unkown1",
    "description": "description for unkown1"},
  "unkown2":{}
}

For this setting, if disable all the default types, but it also enables some of them without setting a lot, like docs. It will overwrite the title and description for chore, and empty the title and description for ci, and add a full configuration for unknown type unknown1, and add unknown type unknown2 without any configuration.

[yi-Xu-0100]

@vivaxy Thanks, after discussing, I will try to make a pr for this issue. 😁

@GustavoFenilli Setting priority: workspace> user setting> default In my opinion, if you want to set the title and description as empty, I think it should set before the default. 🤔

I don't think its needed to have custom types clash, meaning if I added types to it, those are it, I only want mine and the base that are needed by the convention ( feat, fix ).

I can not clearly understand the description of this opinion, I think the second option is just the setting I described above. It is not a selection for on and off, but a setting for appending or overwriting. Maybe my description misleads you. 😀

[fenilli]

@yi-Xu-0100 what i meant by clashing is that if i set "chore" as a simple string it would not look for title and description inside the default chore, as it was added by the user.

but i get that if used with disable all it would get more verbose as i would have to rewrite a default title and description, but that is the point of a disable all rigth? so maybe if you think about those cases wouldnt be better to also have exclude and include instead?

1. .types would overwrite all defaults, and add to it if there are new entries from the default.
2. .includeTypes would include a default that was removed by both .types or .disableAllTypes. ( unless it has a .types setted )
3. .excludeTypes would exclude a default or an included type from .types .

what do you think?

also @vivaxy what do you think about a config.json file to be included as a possible configuration file?

[fenilli]

Also while creating this, #31 #38 would be an easier improvement, a new entry like title and description, "emoji": ":bug:" if there is one it would get appended and would not prompt the gitmoji, it could also be an array of options and prompt only the options on said array.

this would make easier to control the amout of emojis you see at once or make commits faster, and also make a project stay within boundaries with less options depending on a type or scope.

[yi-Xu-0100]

I think more configuration for types is not necessary. The final design that I suggest is the two configurations and three rules for them.

1. conventionalCommits.defaultTypes: Boolean will config whether the default types show or not (which default is true).
2. "conventionalCommits.customTypes": [] will config the custom types (it will show even when the defaultTypes set to be false).
3. the types in "conventionalCommits.customTypes": [] will have the priority than the types in defaultTypes.

I change the object to the array because I think it can be sorted by position.

So in the condition of adding a new type, the setting can be like:

"conventionalCommits.customTypes": [
  {
    "type": "wip",
    "description": "the work is still in prograss."
  },
  {
    "type": "local",
    "title": "localization",
    "description": "changes about the localization files."
  },
  "wip2"
]

If the title or description missing, the corresponding part will not show in the prompt (I recommend adding the title and description for types). It also can set a string only for types.

In the condition of overwriting default types, the setting can be like:

"conventionalCommits.customTypes": [
  {
      "type": "chore",
      "title": "chore item",
      "description": "a chore item that has a cool description"
  },
  {
      "type": "docs",
      "description": "changes about README.md"
  }
]

If the title or description missing, the corresponding part will show the default in the prompt or set it as "" to make it show nothing (I recommend adding the title and description for types).

In the condition of deleting default types, the setting can be like:

"conventionalCommits.defaultTypes": false
"conventionalCommits.customTypes": [
  "docs",
  "feat",
  "fix"
]

The deleting condition is completed by disabling showing the default types and add default types in custom types. According to the three rules above, it will only show types in the prompt, which be set in the custom configuration, and will reuse the default title and description.

@GustavoFenilli @vivaxy I think that It can make configuration doing well in all conditions. 😁

[fenilli]

It seens fine to me, it looks like it will work for most use cases if not all of them.

I will only point out that feat and fix should never be removed, only possible to overwrite title and description, as those are meant to be the stable for conventional commits right @vivaxy?

@yi-Xu-0100

In the condition of overwriting default types, the setting can be like:

"conventionalCommits.customTypes": [
{
"type": "chore",
"title": "chore item",
"description": "a chore item that has a cool description"
},
{
"type": "docs",
"description": "changes about README.md"
}
]

If the title or description missing, the corresponding part will show the default in the prompt or set it as "" to make it show nothing (I recommend adding the title and description for types).

My only concern and not really necessary but would be a good nice to have would be the case I want to exclude only "chore" from the default types, if a user be like " I like all the default types but 'CI' is not usefull for my project ", how would I remove it using your suggestion? I would need to remove all default and add all back inside the customTypes.

"conventionalCommits.defaultTypes": false
"conventionalCommits.customTypes": [
  "docs",
  "feat",
  "fix"
]

Maybe in this case instead of a new configuration exclude, custom types could have a flag for removing.

"conventionalCommits.customTypes": [
  {
      "type": "chore",
      "title": "chore item",
      "description": "a chore item that has a cool description"
  },
  {
      "type": "ci",
      "exclude": true
  }
]

what do you think?

[vivaxy]

@yi-Xu-0100 @GustavoFenilli I have a suggestion about the configuration. We can move default types into configuration.

The configuration could supports 3 types of input:

1. For single language:

   "conventionalCommits.commitTypes": "conventional-commit-types"

2. For i18n:

   "conventionalCommits.commitTypes": "@yi-xu-0100/conventional-commit-types-i18n"

3. For custom types:

   "conventionalCommits.commitTypes": [
   {
   "type": "normal",
   "title": "with title",
   "description": "and description"
   },
   {
   "type": "only-title",
   "title": "only title"
   },
   {
   "type": "only-description",
   "title": "only description"
   },
   {
   "type": "only-type"
   }
   ]

Other attributes are ignored

It seems straightforward and keep the configuration as simple as possible. What do you think? 😃

[yi-Xu-0100]

@vivaxy I think the "conventionalCommits.commitTypes" should have the default value which is "@yi-xu-0100/conventional-commit-types-i18n", and the value of "conventional-commit-types" will set types in en, right? When the custom configuration was set, it only will use the custom types, right?

Could I use the "type": "<default types>.<locale>" to reuse the default value, such as "fix.en" to reuse the en value, and the "type": "<default types>.i18n" to reuse the i18n value? Then the "type": "<default types>" will add a new type not reuse both the en and i18n value.

[fenilli]

@vivaxy Would it be possible to add something like:

"conventionalCommits.commitTypes": [
  "conventional-commit-types",
  {
    "type": "new",
    "title": "new with title",
    "description": "new with description"
  },
]

So we could "spread" the configuration from the defaults, because the way you suggested it means (one or two or three), meaning that I will lose the defaults by adding one custom type, and if I want to keep the defaults I would need to manually add those.

Also my point on this still stands

My only concern and not really necessary but would be a good nice to have would be the case I want to exclude only "chore" from the default types, if a user be like " I like all the default types but 'CI' is not usefull for my project ", how would I remove it using your suggestion? I would need to remove all default and add all back inside the customTypes.

Sometimes we don't need to add one, but remove one from defaults.

what are your suggestions? @vivaxy @yi-Xu-0100

[vivaxy]

@yi-Xu-0100

Yes. I agree with your ideas:

1. The default value is "@yi-xu-0100/conventional-commit-types-i18n".
2. The default language is en.
3. The custom configuration overrides all of the default values.

About the reuse of default values:

Is it possible to introduce extends property like eslint config or commitlint config? I'll try to dig more information about this idea.

[fenilli]

Is it possible to introduce extends property like eslint config or commitlint config? I'll try to dig more information about this idea.

that would be awesome, but those config like options would be more appropriate to be in a separated file, as those are per project configurations instead of per user configurations.

I would suggest an order of use: conventional-commits.json > vscode workspace configuration > vscode user configuration > default

[vivaxy]

@GustavoFenilli

If we'd like to share those configs between projects, we can add .vscode/settings.json into git version control. But it'll share all of the settings of your editor.😟 Is conventional-commits.json a existing config standard or we have to invent that?

[fenilli]

@vivaxy

i dont think it has a standard, but would be a good addition, sharing vscode settings.json isnt the best option for open source projects.

something like .editorconfig, it can be shared inside the project, and users of another ide could implement their own pluggins to use those standards.

but maybe its too ambicious for this single pr we are discussing.

[fenilli]

@vivaxy @yi-Xu-0100 After some looking around, and using other configurations for this kinda of commit configurations I came up with something like this, I will be sending the same for the conventional commits repo, so they could also take a look for better ideas or configuration needs.

{
  "types": {
    "lengthMin": "2",
    "lengthMax": "8",
    "acceptDynamic": false,
    "extends": ["@yi-xu-0100/conventional-commit-types-i18n"],
    "excludes": ["ci", "docs"],
    "values": [
      {
        "newType": {
          "title": "New Type",
          "description": "This is the description",
          "emoji": ["sparkles", "tada"]
        }
      },
      {
        "newType2": {
          "title": "New Type Again",
          "description": "Where is your imagination?",
          "emoji": "bug"
        }
      }
    ]
  },
  "scopes": {
    "disablePrompt": false,
    "lengthMin": "1",
    "lengthMax": "10",
    "acceptDynamic": true,
    "extends": ["@yi-xu-0100/conventional-commit-scopes-i18n"],
    "excludes": ["common", "core"],
    "values": [
      {
        "changelog": {
          "title": "Change Log",
          "description": "Adding to the Change Log"
        }
      },
      {
        "release": {
          "title": "Release",
          "description": "To release a project version"
        }
      }
    ]
  },
  "emojis": {
    "disablePrompt": false,
    "forceEmojiUse": false,
    "values": {
      "sparkles": {
        "emoji": "✨",
        "code": ":sparkles:",
        "description": "Introduce new features"
      },
      "tada": {
        "emoji": "🎉",
        "code": ":tada:",
        "description": "Begin a project"
      },
      "bug": {
        "emoji": "🐛",
        "code": ":bug:",
        "description": "Fix a bug"
      }
    }
  },
  "content": {
    "description": {
      "lengthMin": "1",
      "lengthMax": "40"
    },
    "body": {
      "disablePrompt": false,
      "lengthMin": "1",
      "lengthMax": "100",
      "wrap": "72"
    },
    "footer": {
      "onlyExclamation": false,
      "disableExclamationPrompt": true,
      "appendBreakingChange": true,
      "lengthMin": "1",
      "lengthMax": "100",
      "wrap": "72"
    }
  }
}

[yi-Xu-0100]

@GustavoFenilli This is a huge configuration for the extension, but if it was adopted for the conventional commit or commitlint, I think the extension can get part of configurations from it.

[fenilli]

@GustavoFenilli This is a huge configuration for the extension, but if it was adopted for the conventional commit or commitlint, I think the extension can get part of configurations from it.

Well thank you for mentioning commitlint, I didn't even think about them, they do accept .commitlintrc.json or .commitlintrc.yml, so those would be great to be able to use.

[irvnriir]

It would be appreciated to have ability to set custom Type output format . For example [<<Type>>] <<Description>>, #<<Type>> <<Description>> and other . Though this may not follow Conventional Commits, this extension could be useful for more .

[seonglae]

Can't I read types and scopes from .github/semantic.yml for compatibility with this github app? even if that app is for PR title

[dylan-k]

Is it possible to change the default types? I'm curious if any of the changes discussed here have been implemented since then.

[fenilli]

Is it possible to change the default types? I'm curious if any of the changes discussed here have been implemented since then.

I don't think they where implemented, it does support the commitlint rules scope-enum and types-enum tho, not sure how they behave if they change the prompts or its just a rule before commiting, didn't try it.

[silopolis]

        "newType": {
          "title": "New Type",
          "description": "This is the description",
          "emoji": ["sparkles", "tada"]
        }

That'd be awesome!