If I install tailwindcss and setup the main.css file, then what type should I use? chore(package)?

@mrkhairullah What kind of repository is this? Is it a web application? A documentation site? A monorepo? You need context. It might be refactor(docs): switch to tailwindcss (a repo with a docs/ folder), feat: use tailwindcss (a repo that is just for a website), etc.

@mrkhairullah If you are importing tailwindcss inside main.css for the first time and your application is using this css file, this will most likely impact your app, so I’d go with feat since it is not a fix and I would expect a new version tag for this.

@mrkhairullah What kind of repository is this? Is it a web application? A documentation site? A monorepo? You need context. It might be refactor(docs): switch to tailwindcss (a repo with a docs/ folder), feat: use tailwindcss (a repo that is just for a website), etc.

@uncenter yep web app for personal web use react and vite. When adding tailwind in package.json is a chore? and when adding main.css to commit in git use refactor or feat?

@mrkhairullah If you are importing tailwindcss inside main.css for the first time and your application is using this css file, this will most likely impact your app, so I’d go with feat since it is not a fix and I would expect a new version tag for this.

okey thanks @marijoo

Somthing i use when i do CI is

CI: Add eslint10

useful sir

How about change the configuration?

How about change the configuration?

chore prolly

changing project structure, for example creating new src directory, and probably moving some filed into it, is in which type? docs, refactor, chore?

changing project structure, for example creating new src directory, and probably moving some filed into it, is in which type? docs, refactor, chore?

I'd go with refactor.

changing project structure, for example creating new src directory, and probably moving some filed into it, is in which type? docs, refactor, chore?

I'd go with refactor.

Depends. If it‘s a package and the changed project structure eventually impacts users, it could also be a breaking change which should be reflected in a version.

changing project structure, for example creating new src directory, and probably moving some filed into it, is in which type? docs, refactor, chore?

I'd go with refactor.

Depends. If it‘s a package and the changed project structure eventually impacts users, it could also be a breaking change which should be reflected in a version.

No visible change for users is made

Thanks!

What'd you suggest to use if I remove a feature?
If it caused bugs, it would be bugfix I guess. But what if it was just unnecessary?

What'd you suggest to use if I remove a feature? If it caused bugs, it would be bugfix I guess. But what if it was just unnecessary?

bugfix isn't a conventional commit type, it would be fix. That also could be considered something breaking, so you can use an exclamation mark to mark it as such: fix!: xyz and remove abc feature.

I learned something useful today, thanks!

useful

very cool

feat: Include Libraries?

But I'd also just include them in the same commit with
feat: Initial Commit

Hi folks, what is recommended for benchmark-related changes?

Hi folks, what is recommended for benchmark-related changes?

I would go with test.

Hi folks, what is recommended for benchmark-related changes?

How about "benchg" - Combines "bench" and "chg" (shorthand for "change"), or "benchmod" - "bench" and "mod" (modification).

Thanks both for the reply!

Which type will be the best for deleting unused code? IMHO "refactor" is not correct type for this

I use chore for deleting unsed code.

refactor would be to move currently used code to an unused code path.
chore should be used related to code that is being cleaned out and has no active paths to it. We also use chore when bumping dependency versions without any other code changes needed.

Which type can I use to commit a dependency update? I see the build(deps): type often, is it correct?

refactor

I wanted to share my commit-msg Git hook script that enforces the Conventional Commits standard. This script ensures that all commit messages follow a consistent format, improving readability and maintainability of the project's commit history.

What it does:

• Validates commit messages against the Conventional Commits format: <type>(<scope>): <subject>.
• Provides detailed error messages if the commit message doesn't match the expected format.
• Includes descriptions for each valid commit type to help users understand when to use them.

How to use it:

1. Copy the script below into your repository's .git/hooks/commit-msg file.
2. Make the script executable by running:

   chmod +x .git/hooks/commit-msg

3. Start committing! The hook will automatically validate your commit messages.

Script:

#!/usr/bin/env bash

# Path to the commit message file (provided by Git).
COMMIT_MSG_FILE=$1

# Read the commit message from the file.
COMMIT_MSG=$(cat "$COMMIT_MSG_FILE")

CONVENTIONAL_COMMIT_REGEX='^(feat|fix|docs|style|refactor|test|chore|build|ci|perf|revert)(\([a-zA-Z0-9_.-]+\))?(!)?:\s.*$'

# Check if the commit message matches the regex
if ! [[ $COMMIT_MSG =~ $CONVENTIONAL_COMMIT_REGEX ]]; then
    echo "ERROR: Commit message does not follow Conventional Commits format."
    echo
    echo "The commit message should be structured as follows:"
    echo "<type>(<optional scope>): <description>"
    echo "[optional body]"
    echo "[optional footer(s)]"
    echo
    echo "Valid types are:"
    echo "  feat:     A new feature."
    echo "  fix:      A bug fix."
    echo "  docs:     Documentation changes."
    echo "  style:    Code style changes (formatting, missing semicolons, etc.)."
    echo "  refactor: Code refactoring (neither fixes a bug nor adds a feature)."
    echo "  test:     Adding or updating tests."
    echo "  chore:    Routine tasks like updating dependencies or build tools."
    echo "  build:    Changes affecting the build system or external dependencies."
    echo "  ci:       Changes to CI configuration files or scripts."
    echo "  perf:     Performance improvements."
    echo "  revert:   Reverting a previous commit."
    echo
    echo "Examples:"
    echo "  feat(auth): add login functionality"
    echo "  fix(api)!: resolve timeout issue"
    echo "  docs(readme): update installation instructions"
    echo
    exit 1
fi

exit 0

Thanks for the script! @cfgnunes