What are the commit conventions for semantic release?

What are the commit conventions for semantic release?

Semantic Release uses specific commit message conventions to automate versioning and package publishing. The main types are: 1. feat: A new feature 2. fix: A bug fix 3. docs: Documentation only changes 4. style: Changes that do not affect the meaning of the code (white-space, formatting, etc.) 5. refactor: A code change that neither fixes a bug nor adds a feature 6. perf: A code change that improves performance 7. test: Adding missing tests or correcting existing tests 8. chore: Changes to the build process or auxiliary tools and libraries.

Can you give me an example of a commit message?

Sure! An example of a commit message following the semantic release conventions could be: feat: add user authentication module.

What happens if I don't follow these conventions?

If you don't follow these conventions, Semantic Release may not be able to determine the type of changes made, which can lead to incorrect versioning and potentially disrupt the automated release process.

Is there a tool to help enforce these conventions?

Yes, tools like Commitlint and Husky can help enforce commit message conventions by validating messages before they are committed.