ngryman / cz-emoji

Commitizen adapter formatting commit messages using emojis.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

How do I use this with `validate-commit-msg`?

jameslnewell opened this issue · comments

Hey nice lib. How do I use this with validate-commit-msg?

{
    "validate-commit-msg": {
      "types": "cz-emoji"
    }
}

results in

./node_modules/validate-commit-msg/lib/validateMessage.js:29
    types = Object.keys(require(types).types);
                   ^

TypeError: Cannot convert undefined or null to object
    at validateMessage (./node_modules/validate-commit-msg/lib/validateMessage.js:29:20)
    at validate (./node_modules/validate-commit-msg/lib/cli.js:32:10)
    at readFile (./node_modules/validate-commit-msg/lib/cli.js:59:5)
    at FSReqWrap.readFileAfterClose [as oncomplete] (fs.js:446:3)

> husky - commit-msg hook failed (add --no-verify to bypass)
> husky - to debug, use 'npm run commitmsg'
/Users/james/code/tradie/tradie-v4/node_modules/commitizen/dist/cli/strategies/git-cz.js:102
        throw error;

Hey, sorry for the late answer. I'm not really familiar with validate-commit-msg. Did you try with another cz adapter?

nah. I think you just need to export the types as json e.g. https://github.com/AndersDJohnson/conventional-commit-types

cz types do not follow the same format (https://github.com/ngryman/cz-emoji#types). Also types can be defined by the user, the default ones are just an example. Each user may have his own favorite list of emojis and commit convention. As opposed to conventional-commit, I'm not enforcing anything here. So, exporting a set of predefined types for a third party library would not be relevant.

If you do want to check your message format using validate-commit-msg you'll have to define your types in the format they expect using their .vcmrc file for example.

But I don't really see the point to do so, cz-emoji enforces the message to have a predefined format, meaning that you'll be 100% sure it has the format you defined. Checking it using another tool is redundant. validate-commit-msg would make sense if you typed your commit messages manually. My advice would be to simply drop validate-commit-msg for your use case.

@ngryman you don't think it's worthwhile to validate in CI environment, in case someone on the team inadvertently isn't using the cz command?

Hiya I'd like to request support for either validate-commit-msg or commit lint for validating the commit message in CI service.

Having commit validation is especially helpful for open source projects which may have inexperienced contributors.

Hey folks, I understand the need the validate contributors commits. I think the first time I read this issue, the fact that you had to duplicate your emojis definition seemed ok to me. But as there are now several people requesting it, I guess it's not good enough.

So we're talking about being able to reuse the emojis definition in third party tools like validate-commit-msg or commitlint. What is preventing you to import the config section of your package.json that contains the emojis definition? I'm asking because I'm unaware of the requirements/format that those tool expect.

It seems like validate-commit-msg has been deprecated in favor of commitlint https://www.npmjs.com/package/validate-commit-msg

Having just tried the 'commitizen adapter' (prompt) I was disappointed (but not surprised) that this plugin didn't automatically get integrated. Instead, I assume the standard prompt is revealead:

$ npm run commit
> git-cz
cz-cli@2.10.1, @commitlint/prompt@7.0.0

Please enter a type: [required] [tab-completion] [header]
<type> holds information about the goal of a change.


<type>(<scope>): <subject>
<body>
<footer>


72 characters left
❯ type: 
build  chore  ci  docs  exit  feat  fix  help  perf  quit  refactor  revert  style  test

hitting tab a couple times reveals the avail options...

Creating a cz-emoji replacement might be as simple as using this as a template: https://github.com/marionebl/commitlint/blob/master/%40commitlint/config-conventional/index.js

and then update commitlint.config.js from
module.exports = {extends: ['@commitlint/config-conventional']};
to the new cz one

Hey @Falieson, thanks for the info. I'm not very familiar with commitlint and I'm not sure I understand everything.

Does commitlint support involves code changes or documentation changes on my side?
In both cases, do you think you could open a PR for that since you seem to have a good solution?

Thanks!

commitlint does a precommit hook to validate that all messages follow the format, and has an extension which provides a prompt which is the part that's equivalent to cz.

@ngryman I think the resulting 'support' for commitlint would be a PR for the commitlint repo rather than this one. The code that goes into the new config-conventional-emoji would be mostly copy paste from this repo.

I want to go ahead and do it, but its not high enough on my priorities yet, maybe by the end of July I'll get to it.

P.S. I did a little write up on nps//cz/sv => https://medium.com/@falieson/js-utilities-for-a-grrreat-developer-experience-part-2-4-ts-module-from-scratch-d939c5bfebf2

For anyone who wants to get validation working, use the package here: https://github.com/arvinxx/commitlint-config-gitmoji

commit.config.js

module.exports = {
  extends: [
    'gitmoji'
  ],
  parserPreset: {
    parserOpts: {
      headerPattern: /^(:\w*:)(?:\s)(?:\((.*?)\))?\s((?:.*(?=\())|.*)(?:\(#(\d*)\))?/,
      headerCorrespondence: [
        'type',
        'scope',
        'subject',
        'ticket'
      ],
    }
  }
};

PR here: #22

Closing the issue as it seems that @loonpwn provides a good solution for it.