Thiết lập commitlint để buộc một tiêu chuẩn cho các thông điệp cam kết của chúng ta
Ngoài linting code của chúng ta, chúng ta cũng có thể lint các thông điệp của chúng ta. Bạn có thể nhận thấy
rằng chúng ta đang gắn xong tiền tố các thông điệp cam kết của chúng ta với một dạng (dạng chore). Các dạng
làm nó dễ dàng hơn để đi theo cái gì được thay đổi trong một cam kết. Để buộc việc sử dụng các dạng, chúng ta
có thể thiết lập commitlint. Đi theo các bước này để thiết lập nó:
1. Cài đặt commitlint và một cấu hình theo thông lệ cho commitlint:
$ npm install –save-dev @commitlint/cli@18.4.3 \
@commitlint/config-conventional@18.4.3
2. Tạo một .commitlintrc.json file mới trong root của dự án của chúng ta và thêm các nội dung sau:
{
“extends”: [“@commitlint/config-conventional”]
}
3. Thêm một commit-msg hook vào Husky:
$ npx husky add .husky/commit-msg \
‘npx commitlint –edit ${1}’
4. Bây giờ, nếu chúng ta thử thêm các files được thay đổi của chúng ta và cam kết không cần một dạng hay một
dạng sai, chúng ta sẽ nhận một lỗi từ commitlint và sẽ không thể thực hiện một cam kết như vậy. Nếu chúng ta
thêm dạng đúng, nó sẽ thành công:
$ git add .
$ git commit -m “no type”
$ git commit -m “wrong: type”
$ git commit -m “chore: configure commitlint”
Ảnh sau thể hiện Husky trong thực tế. Nếu chúng ta viết một thông điệp cam kết không đúng, nó sẽ bác bỏ nó và không
để chúng ta cam kết code. Chỉ nếu chúng ta nhập một thông điệp cam kết định dạng đúng đắn cam kết sẽ đi qua:
Các thông điệp cam kết trong cấu hình thông lệ commitlint (https://www.conventionalcommits.org/) được cấu trúc
theo một cách nơi một dạng phải được liệt kê trước tiên, sau đó một phạm vi tùy chọn đi theo, và sau đó mô tả đi
theo, như type(scope): description. Các dạng có thể là như sau:
• fix: Để sửa lỗi
• feat: Để có đặc tính mới
• refactor: Để tái cấu trúc code mà không thêm các đặc tính hoặc sửa các lỗi
• build: Để thay đổi hệ thống xây dựng hoặc dependencies
• ci: Để thay đổi trong cấu hình CI/CD
• docs: Chỉ để thay đổi tài liệu hướng dẫn
• perf: Để tối ưu hóa hiệu suất
• style: Để sửa định dạng code
• test: Để thêm hoặc điều chỉnh các tests
Scope là tùy chọn và sử dụng tốt nhất trong một monorepo để chỉ ra rằng các thay đổi được thực hiện đối với
một app hay thư viện nhất định bên trong nó.