Features

• Hyperfast rendering of the template into a new project using Copier
• Project management with Make
• Support for Conventional Commits and Semantic Versioning
• Automated changelog with semantic release
• Automated semantic versioning with semantic release
• Automated labeling for pull requests based on Conventional Commits using Conventional Release Labels
• Continuous integration with GitHub Actions
• Automated dependency updates with Dependabot
• Documentation using MkDocs and Read the Docs
• Consistent coding styles across different text editors with EditorConfig and its configuration file .editorconfig
• Enforced coding standards and best practices for JavaScript using ESLint
• Consistent code style using Prettier and its configuration file .prettierrc
• Ensured code quality with pre-commit and its configuration file .pre-commit-config.yaml
• Simplified Git hooks management with Husky
• Assisted commit message creation with Commitizen for standardized commit messages

Semantic Release

Commit Message Format

Semantic-release relies on commit messages to determine the impact of changes in the codebase on users. By adhering to standardized commit message conventions, semantic-release can automatically calculate the next semantic version number, generate a changelog, and publish the release.

Tools such as commitizen or commitlint can assist contributors in maintaining valid commit messages.

The table below demonstrates how different commit messages result in specific release types when semantic-release runs (using the default configuration):

Commit message	Release type
fix(pencil): stop graphite breaking when too much pressure applied	Fix Release
feat(pencil): add 'graphiteWidth' option	Feature Release
perf(pencil): remove graphiteWidth option BREAKING CHANGE: The graphiteWidth option has been removed. The default graphite width of 10mm is always used for performance reasons.	Breaking Release (Note that the BREAKING CHANGE: token must be in the footer of the commit)

Automation with CI

Semantic-release is designed to run on a Continuous Integration (CI) environment after every successful build on the release branch. This approach ensures that no human intervention is required during the release process, making releases objective and emotionless.

Triggering a Release

Whenever a new commit is added to one of the release branches (e.g., main, next, or beta) through git push, merging a pull request, or merging from another branch, a CI build is triggered. This build executes the semantic-release command, initiating a release if there are any changes to the codebase that affect the package's functionality since the last release.