conventionalcommit / commitlint Goto Github PK

Is it possible to get commitlint to ignore commented lines? For example this commit message:

ops: update CommitLint allowed types
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch DAY-36-enforce-git-hygeine
# Your branch is up to date with 'origin/DAY-36-enforce-git-hygeine'.
#
# Changes to be committed:
#	modified:   .commitlint.yml
#

will fail because there's not an empty line after ops: update CommitLint allowed types but given the rest of the lines are all commented out, I think it should pass? I'm also finding the same thing if e.g. some of the commented lines are longer than the rules (this often happens if the path to a modified file is long)

Cheers!

Hi,
In MacOS, I ran the command commitlint config create in my Go repo. This created the default config file .commitlint.yaml in the current directory. Next I ran the command commitlint config check --config=./.commitlint.yaml. It throws the error
Error: invalid version should be in semver format.

Also, when I ran the command echo "feat: good commit message" | commitlint lint, the same error is thrown.
Running commitlint -v gave the output
commitlint version 0.10.0 - built from 83e21a6afc44e84e108e1f01aea18b2e1d197bcf on 2022-08-09T11:41:55Z

Any help from you will be much appreciated.
Thanks.

commitlint currently fails the messages auto-generated by git for --fixup and --squash commits.

I think commitlint should always permit these commit messages.

Since the point of these commits is to be rebased into other commits, their messages won't be in the commit history for terribly long. And they're already an established part of the git ecosystem.

I'm currently working around this by using -n every time I --fixup, but it's a friction point each time I forget.

commitlint fails auto-generated merge-commit messages; these should be allowed.

daniel@cracked project_dir % git merge develop

→ input: "Merge branch 'develop'..."

Errors:
  ❌ parser: type: invalid character ' '

Total 1 errors, 0 warnings, 0 other severities
Not committing merge; use 'git commit' to complete the merge.

Allow using gitmojis in the commit message description.

Looks like they are detected as part of the scope.

For example, the following commit message generated in VSCode using Conventional Commits extension:

chore: :hammer: Add commitlint as git commit-msg hook

Also add **Conventional Commits** VSCode extension

gives:

commitlint

→ input: "chore: :hammer: Add co..."

Errors:
  ❌ parser: scope must be followed by ': '

Total 1 errors, 0 warnings, 0 other severities

When I write a commit message in my editor, and save and close it, if the message fails commitlint, I have to recreate everything I wrote (re-gather reference URLs, re-copy any supporting evidence for the reasoning in the commit, etc), from scratch.

It would be great if commitlint could keep a record of the last failed commit, so that a fresh git commit opens it up automatically, and you can make the (usually minor) necessary changes to pass commitlint.

It would be nice to have a smaller config file when only making small alterations to the Default Config of commitlint. Adding a behavior allowing users to override the default config would allow for much smaller .commitlint.yaml files.

e.g.

# .commitlint.yaml

extends: default
# or maybe
formatter: overwrite # or `extend`, 'overlay', 'merge', ...etc

# then just what values should be overwritten
settings:
  # Loosen up on the line lengths
  header-max-length:
    argument: 72
  body-max-line-length:
    argument: 100
  footer-max-line-length:
    argument: 100

As of now it seems like this tool is only for linting as part of the commint mesasge hook or manual linting.
In other ecosystems, there is generally a centralized tool which helps with:

• prompting for the correct format
• linting the format
• helping with generating changelog based on the format

Are there some examples where this can be integrated with other tools for cli prompt or for generating changelog

It appears that the README.md is out of date with the latest default config file from v0.10.0

Running commitlint config create will generate the following file, which does not match Default Config section of README.md.

version: v0.10.0
formatter: default
rules:
- header-min-length
- header-max-length
- body-max-line-length
- footer-max-line-length
- type-enum
severity:
  default: error
settings:
  body-max-length:
    argument: -1
  body-max-line-length:
    argument: 72
  body-min-length:
    argument: 0
  description-max-length:
    argument: -1
  description-min-length:
    argument: 0
  footer-enum:
    argument: []
  footer-max-length:
    argument: -1
  footer-max-line-length:
    argument: 72
  footer-min-length:
    argument: 0
  footer-type-enum:
    argument: []
  header-max-length:
    argument: 50
  header-min-length:
    argument: 10
  scope-charset:
    argument: abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ/,
  scope-enum:
    argument: []
    flags:
      allow-empty: true
  scope-max-length:
    argument: -1
  scope-min-length:
    argument: 0
  type-charset:
    argument: abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ
  type-enum:
    argument:
    - feat
    - fix
    - docs
    - style
    - refactor
    - perf
    - test
    - build
    - ci
    - chore
    - revert
  type-max-length:
    argument: -1
  type-min-length:
    argument: 0

Node commitlint version seems to be the "de facto" standard Conventional Commits linter (but it forces you to have node installed).

Are there any plans to make this project compatible with it?

I mean at:

• feature level
• command parameter level
• config file level

So it is easy to transition from the Node version to this Go version.