變更日誌的意義與重要性​

變更日誌是什麼？​

在軟體專案中，變更日誌（Change Log） 是一份用來記錄專案功能變更、問題修復、優化內容的重要「歷史日記」。這份日誌的對象通常是開發者、測試人員。它可以幫助專案參與者快速掌握專案歷史，甚至在需要版本回滾時節省大量時間。

變更日誌最主要的目的是為了讓大家能「看懂版本變化」。它有幾個很實用的好處：

1. 讓專案更透明，無論是團隊成員還是用戶，都能快速知道每次更新改了些什麼。
2. 提高團隊效率，讓團隊成員快速理解改動，避免重複查詢。
3. 輔助問題追蹤與版本回滾

前言​

在上一篇文章中，我們介紹了如何透過 Commitizen 與 Gitmoji 規範化提交訊息。但規範的建立並不保證會被嚴格執行，許多團隊仍可能面臨這樣的情況：

「提交訊息格式看起來很簡單，但實際操作時，不是漏寫了類型，就是格式寫錯了。」

這種情況下，提交訊息的規範就形同虛設。因此，若要確保提交訊息始終符合規範，勢必得設立一道自動化檢核機制來攔截不合格的提交。

這正是 Commitlint 發揮作用的地方！它專門校驗提交訊息是否符合規範，無論是 Conventional Commits 還是 Gitmoji，都可透過自定義配置嚴格檢查，避免不合格的提交進入版本控制歷史。當然，工具的強大功能需要在正確的時間觸發才能發揮作用，搭配 Husky，我們能利用 Git hooks 在提交前自動執行 Commitlint 的校驗邏輯，將自動化檢核落實於日常開發流程。

本篇文章將帶你實作以下內容：

1. 不使用 Gitmoji 的提交校驗：延續前一篇的配置，透過 @commitlint/config-conventional 校驗提交訊息。
2. 使用 Gitmoji 的提交校驗：加入 commitlint-config-gitmoji 與 commitlint-config-cz，支援帶有 Emoji 的訊息格式。
3. 整合 Husky：將 Commitlint 校驗嵌入 Git Hooks，阻止不符合規範的提交。

前言​

最近我在研究 Git 專案的專業開發流程，比如怎麼按照 Conventional Commits 規範撰寫提交訊息，還有如何根據 Semantic Versioning 原則管理版本號等等。研究過程中，我花了不少時間瀏覽 Github 上一些知名的開源專案，透過它們的提交紀錄、PR 歷史、Change log 和 Release notes，一步步學習怎麼建立一套高效又規範化的工作流程。

經過一段時間的摸索，我慢慢整理出一些具體的流程，未來可以應用在新專案上，比如：

1. 使用互動式問答工具，輔助撰寫符合規範的提交訊息。
2. 配合 Git Hook，自動檢查提交訊息是否遵循規範。
3. 利用規範化的提交紀錄自動生成 Changelog

在實踐這些流程的過程中，我研究了不少相關工具。有趣的是，我發現許多開源專案的提交訊息裡經常出現 Emoji，看起來不僅直觀，還挺有趣的。稍微查了一下後，我才知道這其實是一套叫 Gitmoji 的規範。於是，我決定順便研究一下怎麼把 Gitmoji 整合到剛剛提到的流程中。

由於內容較多，我將以上三個工作階段分成三篇文章來介紹，並在每篇文章中詳細講解有使用 Gitmoji 和未使用 Gitmoji 的情況下，該如何安裝、配置所需工具，以及實際使用的效果。

前言:
最近在公司被分派一個 Koa backend 的功能開發任務，雖然我平時多數時間主要負責前端相關的工作，不過因為學生時期有稍微接觸過一點 Express，它與 Koa 都是 Node.js 知名 web 框架，所以閱讀程式碼時並不會太陌生。這兩者雖然有不少相似之處，但實際使用後發現，它們在設計理念和使用體驗上有很大的不同。

前言：
最近我在更新公司內部的前端 Codebase，其中一項任務是為應用加入多國語系（i18n）的支持。雖然在舊專案上一直有在使用 i18n 的功能，但這是我第一次接觸 i18n 的配置，正好藉此機會把學習過程和實作細節記錄下來。

在過去，當我們談論到 JavaScript 前端開發環境時，很難不提到 Webpack 。這款在 2012 年誕生的強大工具，在過去的 10 年內一直是最主流的前端打包工具 。然而，在 2020 年一個名為 Vite 的新興工具迅速崛起，挑戰著 Webpack 的霸主地位。根據 2023 年 State of JavaScript 網站所統計的資料顯示，Vite 僅花了短短三年就成為使用規模第二大的 Build Tools，如果單看 Interest 或 Positivity 指標的話，甚至都穩坐第一名的位置。

前情提要：
近期在幫公司開發一個提供內部前端成員使用的 npm package。在開發的過程中有一個比較麻煩的點是，我過去從來沒有開發過 npm package 的經驗，對於如何設置開發環境、打包、發布、維護可說是完全從零開始研究。再加上公司不希望這個 package 開源給外部使用，也沒有計劃要付費使用 npm Orgs 的私人 npm 功能。因此，除了研究如何開發 npm package 之外，同時還得研究是否有免費且適合我們公司的私人 npm library 的解決方案。

初學 JavaScript 時，偶爾會在教學文或討論區中看到這樣的說法：

「在 JavaScript 中，萬物皆為物件。」

便在潛意識中埋下一個 JS 中所有變數都是物件的種子。如今因為工作上大量使用 JS 這個語言，對 JS 這個語言有比較深一點的了解後，便想要回來探討這個議題。

先講結論，這個說法是不正確的。

但是，我相信正在看這篇文章的你應該也跟我一樣，會想要了解為什麼訪間會有 「JavaScript 萬物皆為物件」 的說法，以及這個說法背後的論點是什麼？反對這個說法的論點是什麼？本篇文章將帶大家探討這個議題，挖掘正反兩方的論點，並釐清一些 JS 的觀念。

最近拿到了公司配的 macbook pro 13(2022) 工作機，趁這個機會整理一下我常使用的軟題和工具，順便記錄一下一台新 mac 安裝各種工具的過程中遇到的小問題以及我做了哪些配置。

圖片來源： Maintain code consistency using ESLint, Prettier, husky and lint-staged