Rush and changelog generation - Part 1

This really breaks my heart 💔... Rush is not supporting conventional commits.
In fact the whole process of committing code and generating changelogs is using unique approach.

The process flow by Rush

If you work on libraries that get published as NPM packages, your repo probably requires you to include change log entries as part of your PR. You will know because your PR build will fail on the rush change --verify step.
To write change logs, first commit any pending work to Git. Then type rush change from anywhere under your repo working folder. This command will examine your Git history to determine which project folders have diffs. Based on that, it will prompt you to write a change log entry for each one. Each change log entry gets stored in a separate file under common/changes. You should add and commit these files to Git.

Later, Rush's automated publishing workflow will inspect these files to determine which packages need to be published. It will delete the files and copy your messages into the package's CHANGELOG.md file.
Source: Everyday commands / rush change

A look under the hood

OK, let's see what's happening here.
Imagine you have a spfx-utils solution with some code in UtilsLibrary.ts file.

1. Switch to a new features/cc branch: git checkout -b features/cc git push --set-upstream origin features/cc
2. Edit the code in a UtilsLibrary.ts file, belonging to the spfx-utils solution
3. Commit changes: git commit -am "feat(date): Add getCurrentTime()"
4. Run rush change The first thing I see is that rush change compares my changes to the master branch. It's actually documented:
5. To compare the features/cc to its remote, specify --branch parameter: rush change -b origin/features/cc.Also, rush change doesn't really care about the commits. It asks for a change description and change type, leaving it up to the developer to decide on the version bump. It won't even display the previous commits (which maybe sometimes is not a bad idea 😉 ). rush change generates common\changes_branchname-timestamp.json_ file: If you press Enter to skip changes description, a change file with a change type none will be created.
6. Rush recommends including rush change --verify in the PR process to ensure that developers generate change files. Let's see what will happen now, that the files are created.
7. rush change --verify --target-branch origin/features/cc returns
8. This is because files created by rush change must be committed. Run: git add common/changesgit commit -m "docs: Add changefile(s)"
9. Check again: rush change --verify -b origin/features/cc. All is good:
10. Add another function to the UtilsLibrary.ts file.
11. Commit changed files: git commit -am "feat(date): Add getCurrentDate()"
12. What would happen if I run rush change --verify -b origin/features/cc again? Will rush detect the commits I made since the last rush change? Nope:

Summary

• If you don't specify the branch parameter (-b or --target-branch), the checked out branch is compared against the "master" branch.
• Rush will NOT generate changelogs based on your commits.
• Rush recommends using rush change files to generate change files which are later used to generate changelogs.
• Rush does NOT support conventional commits and developers needs to decide on the version bump (major/minor/patch).
• Developers have to commit change files. Otherwise rush change --verify will fail.
• rush change --verify doesn't check if there were any commits AFTER already existing change files were generated. After running rush change (and committing the change file), developers may add new commits and rush change --verify will not complain.