Add BNF grammar to explain things with less risk of ambiguity and to support implementing parsers #208

New Issue

GiteaMirror · 2026-02-17T11:53:43-06:00

GiteaMirror commented

2026-02-17 11:53:43 -06:00

Originally created by @christianhujer on GitHub (Jul 6, 2024).

It would be great to have a BNF grammar to explain things with less risk of ambiguity and to support implementing parsers for checkers and alike.

Here's a start, using the ABNF from RFC5234.

I might come up with a PR if the idea of adding an ABNF grammar is accepted.

ABNF Definition of Conventional Commits

commitMessage = conventionalCommitHeader [body] [blankLine footer*]
conventionalCommitHeader = typePrefix headline LF
typePrefix = typeNoun [scope] [breakingChangeIndicator] ":" SP
typeNoun = "feat" / "fix" / "refactor" / noun
scope = "(" scopeNoun ")"
scopeNoune = noun
breakingChangeIndicator = "!"
headline = text LF
body = blankLine bodyLine bodyLine*
bodyLine = text LF
blankLine = LF
footer = footerToken footerTokenSeparator footerBody
footerTokenSeparator = footerTokenColonSeparator / footerTokenHashSeparator
footerTokenColonSeparator = ":" SP
footerTokenHashSeparator = SP "#"
footerToken = "BREAKING CHANGE" / dashSeparatedToken
dashSeparatedToken = token dashPlusToken*
dashPlusToken = "-" token
footerBody = *(text LF)
noun = token
text = *(WSP / VCHAR)
token = ALNUM *ALNUM
ALNUM = ALPHA / DIGIT

Projects may decide to put further restrictions on typeNoun, scopeNoun, and footerToken as they deem useful.

Declaration of Intended Compatibility

The intention of the ABNF grammar is to reflect what is written in the prose ruleset in the specification section. Any difference of the ABNF grammar from the specification ruleset is unintentional, by accident, and a mistake in the ABNF grammar. The ruleset takes precedence over the ABNF grammar.

References:

RFC5234

Originally created by @christianhujer on GitHub (Jul 6, 2024). It would be great to have a BNF grammar to explain things with less risk of ambiguity and to support implementing parsers for checkers and alike. Here's a start, using the ABNF from RFC5234. I might come up with a PR if the idea of adding an ABNF grammar is accepted. # ABNF Definition of Conventional Commits ```abnf commitMessage = conventionalCommitHeader [body] [blankLine footer*] conventionalCommitHeader = typePrefix headline LF typePrefix = typeNoun [scope] [breakingChangeIndicator] ":" SP typeNoun = "feat" / "fix" / "refactor" / noun scope = "(" scopeNoun ")" scopeNoune = noun breakingChangeIndicator = "!" headline = text LF body = blankLine bodyLine bodyLine* bodyLine = text LF blankLine = LF footer = footerToken footerTokenSeparator footerBody footerTokenSeparator = footerTokenColonSeparator / footerTokenHashSeparator footerTokenColonSeparator = ":" SP footerTokenHashSeparator = SP "#" footerToken = "BREAKING CHANGE" / dashSeparatedToken dashSeparatedToken = token dashPlusToken* dashPlusToken = "-" token footerBody = *(text LF) noun = token text = *(WSP / VCHAR) token = ALNUM *ALNUM ALNUM = ALPHA / DIGIT ``` Projects may decide to put further restrictions on `typeNoun`, `scopeNoun`, and `footerToken` as they deem useful. ## Declaration of Intended Compatibility The intention of the ABNF grammar is to reflect what is written in the prose ruleset in the specification section. Any difference of the ABNF grammar from the specification ruleset is unintentional, by accident, and a mistake in the ABNF grammar. The ruleset takes precedence over the ABNF grammar. ## References: * [RFC5234](https://datatracker.ietf.org/doc/html/rfc5234)

GiteaMirror referenced this issue

2026-02-17 12:00:29 -06:00

[PR #208] [MERGED] docs: add new project dcyou/resume #359

GiteaMirror referenced this issue

2026-04-11 07:26:27 -05:00

[PR #208] [MERGED] docs: add new project dcyou/resume #1018

GiteaMirror referenced this issue

2026-04-13 12:55:07 -05:00

[PR #208] [MERGED] docs: add new project dcyou/resume #1681

GiteaMirror referenced this issue

2026-04-16 01:23:38 -05:00

[PR #208] [MERGED] docs: add new project dcyou/resume #2344