這次要介紹的是我為 KOReader 檔案瀏覽（Mosaic）所做的另一個 userpatch：2-browser-folder-cover.lua。這個 patch 可以讓資料夾在 Mosaic 檢視時顯示封面圖片，支援放置自訂 .cover 檔案，若無自訂封面則會自動從該資料夾或其子資料夾的第一本有封面的書籍取得封面。

下載路徑：https://github.com/chiahsien/KOReader.Patches

Xcode 的 project.pbxproj 檔案採用文字格式儲存專案結構，但 Xcode 在新增檔案或修改設定時，不保證項目的插入順序一致。多人協作時，即使修改不同的檔案或 target，也可能因為項目順序差異而產生 merge conflict。這些衝突往往與實際變更無關，純粹是格式問題。

我的解決方案

將 project.pbxproj 中的各個區塊按固定規則排序，確保相同內容產生相同的檔案結構。配合 git pre-commit hook，每次提交前自動排序，團隊成員的專案檔就能維持一致的順序，大幅降低無意義的衝突。

我開發了一個腳本工具來執行這個任務，也已經在多個專案上跑了好幾年，GitHub repo 放在這裡：https://github.com/chiahsien/sort-Xcode-project-file

雖然目前推崇使用 Swift Package Manager 進行模組化，Xcode 16 也引入了 buildable folders 功能來減少專案檔變更，甚至也有 Tuist 或 Xcode Gen 這類的工具來生成專案檔，但這些新技術主要針對新專案或願意大幅重構的專案。對於已經開發多年、結構複雜的舊專案，貿然改用 SPM 模組化或轉換成 folder references 風險過高。此時，這個排序工具仍是最務實的選擇，能以最小成本解決 merge conflict 問題。

在專案開發到一定規模後，你可能會發現某些 feature 其實相對獨立：它們有自己的流程、畫面、資源檔，甚至可以被其他專案重用。這時候，最乾淨、最有彈性的做法，就是把它抽成 Swift Package。

以我最近在做的功能為例，它是一個完整的獨立模組 - 有多個頁面、支援多國語言、使用圖片與動畫資源。為了避免日後整合時出現命名衝突、相依過重或編譯過慢的問題，我選擇把它獨立成一個 Swift Package。在將 feature 抽出到 Package 的過程我也踩到了一些坑，趁著這個機會記錄下來，以免日後忘記。

為什麼要把 Feature 打包成 Swift Package？

建立專屬的 Swift Package 有幾個明顯的好處：

• ✅ 可獨立開發與測試：模組化後不必依賴主專案，可單獨編譯與驗證。
• ⚙️ 降低相依與衝突：減少命名重複、依賴鏈過長等問題。
• 🚀 加快編譯速度：主專案不需每次都重新編譯整個功能。
• 🔄 方便整合與重用：未來可以直接被其他 app 或團隊使用。

工程師都會有自己習慣的電腦設定，我自然也不例外。本文記錄了我自己的環境建置，方便以後換電腦或換工作時可以快速 setup。

我用的瀏覽器主要是 Chromium based，從早期愛用的 Google Chrome，到現在改用 Vivaldi、Brave Browser、Arc、Dia。有時還會用 WebKit based 而且支援 Chrome/Firefox 套件的 Orion Browser。

每次換工作都是一次整理工作環境的機會，我的瀏覽器也藉此重裝，雖然每次的工作都不完全一樣，但我發現有些 extension 是不管在之前還是現在的工作、不管是公司還是家裏都會安裝的。以下就是我必備的幾個 extension：

我在 KOBO 電子書閱讀器上額外安裝了 KOReader 系統，它的眾多設定讓我可以調整出自己最喜歡的樣子來觀看電子書，無論是 ePUB、PDF、CBZ 格式，高度自訂化佈局讓閱讀成為一件舒服的事。

最近有一個困擾我的地方，就是它的書本排序方式雖然很多，但卻沒有我想要的排序方式，我想要讓書本「先按照作者排序，然後如果是系列套書就按照系列順序排序，最後再按照書名或是出版日期排序」，這樣才符合我整理書本的習慣。

還好 KOReader 提供了讓使用者開發與安裝 user patch 的功能，那就自己來寫一個 patch 滿足我的需求吧！

p.s.: 也有開發者搜集了很多實用的 user patch，可以來這裡看看！