已經來到 2026 年一月的尾聲，現在才在開始展望（？） 2026 可能相對有點晚。

但，眼看著新學期再過不到一個月即將展開，作為弄出了這一堆一堆的教材的人，總感覺要在技術飛速迭代的此刻，講清楚為什麼自己還要做這件事情，以及為什麼我仍然認為大家可以試著學這些東西。

希望這一點隻字片語，可以為坐在書桌前面發愁的人，一點點小小的回應或提醒。

如果你有看過 tutorial 的話，應該見過 fnm 了吧？

fnm 是一個專門用來管理 node 版本的工具。 雖說確實是好用，但若你跟筆者一樣，會用許多不同的語言(JavaScript, Python, Rust, Zig...)做事， 可能也會覺得版本管理工具東一個西一個，維護起來很麻煩吧？

mise 就是一個集成工具。 你可以用它來管理許多程式語言，甚至開發工具的版本。 筆者甚至連編輯器(neovim)都用它來管理呢！

這個專案沒什麼好顧慮的，就大膽地把這次踩坑記錄下來吧！

今天筆者終於來看了 Github 發給我的 Vulnerability Alerts。

簡單來說，是一個名為 qs 的套件爆出了安全疑慮。

GitHub 的警告非常明瞭：解決方案就是「升版」，必須將 qs 從 6.13.x 升級到 ^6.14.1。

在試圖追 bun 的程式碼時， 發現用平常用的 neovim 怎麼用怎麼不順。

在 Visual Studio Code(VS Code) 就可以簡單的 jump to definition 的東西， 在 neovim 卻跳不動。

為什麼？可能是因為 project-level 的設定不一致而導致。

在更新這個部落格的依賴套件時，發現我還是對這些 JS 開發基礎建設的認識太少了。

雖然我目前還不具備鑽研底層 runtime 的能力與時間，但學習一下 package manager 的原理應該還是可以的。

出於個人偏好，我將會調查一下 pnpm 以及 bun 的設計思路以及一些程式碼片段，希望可以有一些初步的理解。

本篇是第二篇，有關一些背景及前置知識，歡迎查閱上一篇

在更新這個部落格的依賴套件時，發現我還是對這些 JS 開發基礎建設的認識太少了。

雖然我目前還不具備鑽研底層 runtime 的能力與時間，但學習一下 package manager 的原理應該還是可以的。

出於個人偏好，我將會調查一下 pnpm 以及 bun 的設計思路以及一些程式碼片段，希望可以有一些初步的理解。

不知道你是不是也跟我一樣，覺得 MySQL 會出些很麻煩但又很無解的問題？我相信這可以幫到你。