EasyBuild.CommitParser 1.1.1

EasyBuild.Parser

Common commit parser library used by other EasyBuild tools like EasyBuild.ChangelogGen or EasyBuild.CommitLinter.

Usage

open EasyBuild.CommitParser
open EasyBuild.CommitParser.Types

let commitText = "..."

// If you need the commit message information
Parser.tryParseCommitMessage CommitParserConfig.Default commitText
// > it: Result<CommitMessage,string>

// If you just want to validate the commit message
Parser.tryValidateCommitMessage CommitParserConfig.Default commitText
// > it: Result<unit,string>

For the configuration, you can use the default configuration or provide a custom one.

open EasyBuild.CommitParser.Types

// Default configuration
CommitParserConfig.Default

// My custom configuration
{
    Types =
        [
            // ...
        ]
    Tags =
        [
            // ...
        ] |> Some
}

// You can also use a configuration file by passing the JSON content to the included Decoder
open Thoth.Json.Newtonsoft

let configurationJson = "..."

match Decode.fromString CommitParserConfig.decoder configContent with
| Ok config -> config
| Error error ->
    failwithf "Error while parsing the configuration file: %s" error

Commit Format

[!NOTE] EasyBuild.CommitParser format is based on Conventional Commits and extends it to work in a monorepo environment.

<type>[optional scope][optional !]: <description>

[optional tags]

[optional body]

[optional footer]

• [optional tags] format is as follows:

  [tag1][tag2][tag3]
  

• [optional body] is a free-form text.

  This is a single line body.
  

  This is a
  
  multi-line body.
  

• [optional footer] follows git trailer format

  BREAKING CHANGE: <description>
  Signed-off-by: Alice <alice@example.com>
  Signed-off-by: Bob <bob@example.com>
  

Configuration

EasyBuild.CommitParser comes with a default configuration to validate your commit.

The default configuration allows the following commit types with no tags required:

• feat - A new feature
• fix - A bug fix
• ci - Changes to CI/CD configuration
• chore - Changes to the build process or auxiliary tools and libraries such as documentation generation
• docs - Documentation changes
• test - Adding missing tests or correcting existing tests
• style - Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
• refactor - A code change that neither fixes a bug nor adds a feature

If needed, you can provide a custom configuration either by code directly or by using a configuration file using JSON format.

Configuration File Format

The configuration file is a JSON file with the following properties:

types

• Required: ✅
• Type: { name: string, description?: string, skipTagLine?: bool } []

List of accepted commit types.

tags

• Required: ❌
• Type: string []

List of accepted commit tags.

Examples

{
    "types": [
        { "name": "feat", "description": "A new feature", "skipTagLine": false },
        { "name": "fix", "description": "A bug fix", "skipTagLine": false },
        { "name": "docs", "description": "Documentation changes", "skipTagLine": false },
        { "name": "test", "description": "Adding missing tests or correcting existing tests", "skipTagLine": false },
        { "name": "style", "description": "Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)", "skipTagLine": false },
        { "name": "refactor", "description": "A code change that neither fixes a bug nor adds a feature", "skipTagLine": false },
        { "name": "ci", "description": "Changes to CI/CD configuration" },
        { "name": "chore", "description": "Changes to the build process or auxiliary tools and libraries such as documentation generation" }
    ],
    "tags": [
        "cli",
        "converter"
    ]
}