Lerna 的套件管理術 — Fong
在開發上，當程式碼規模越來越大、分散在各個repo的時候，管理上越來越繁雜，要怎麼管理、重用、維持DRY(Do not repeat yourself)原則？
問題
- 重複使用的程式在各個地方到處使用，更動程式時卻沒有一併更改
- 更新舊 npm package困難，有些package可能過時便不更新了
- 程式碼散布在各個repo，難以追蹤、修改
- github repos/microservices 中 CI/CD 依賴性難管理
MonoRepo
MonoRepo優點：
- 提升對於整體軟體架構理解力
- 重用性 & single sources of truth
- 簡化依賴性管理，清楚知道程式碼之間的關係
- 跨專案模組的重構 & Debug只要在一個Repo進行
- 每個專案都有一致的 CI/CD pipeline 設定
MonoRepo缺點：
- 各子專案設定的彈性比較少(因為追求統一)
- 沒辦法對各個子專案作 Read/Write 權限管理
- 程式碼 Size 直線上升
- 導入時的設定較複雜
Lerna
- 用於CI、CD的進行、Version的管理，把 JS 專案當作 Multiple package 來管理的工具
- 在一個 Repo 中，可以獨立地測試、建置 Image、部屬、發佈各個 Package
- 可以在隔離的環境中重構並開發
- 根據Package有無被修改來觸發
Definitions
Lerna Package：
- 被管理的 JS Package 單位
- 可以做完一個獨立的專案、套件
- Lerna Package 間可以互相依賴
Lerna Workspace：
- 放置、分類 Lerna Packages 的地方
JavaScript 中鼓勵用非同步的 API，但用了就會提升效能避免阻塞嗎？- 陳柏融（PJCHENder）
Single Threaded Language：
Event Loop
- Stack：執行與撰寫程式碼的地方
- WebAPIs：瀏覽器所提供的API，同時負責解決非同步API，將處裡的結果傳給Queue，經由Event Loop再回傳給Stack
耗能的I/O操作
- 例子：加密與解密、讀取、覆寫檔案
- Node.js藉由Event Loop來進行程式碼，而Event Loop由C++進行多執行緒來處理，最後藉由callback傳回給Node.js
有了非同步、Event Loop，還需要擔心Javascript single thread問題嗎?
- 情況1：將程式碼放到Promise的then之中
- 情況2：使用SetTimeout
- 情況3：程式碼放到Async/Await中
即使使用上述方法，還是會造成程式碼的阻塞，大部分看得到的程式碼都會回到single thread中執行
使用Node.js 的 multi-thread (mdn web worker)
用不用 TypeScript 隨便你，反正我是用了- Will 保哥(多奇教育訓練)
JavaScript是個"弱型別"的程式語言
- JS設計不是個嚴謹的程式語言，可以隨意設計物件內容
- 對於變數的型別並沒有特地去限制，所以宣告變數/常數的當下無法知道型別
- 由於這個特性，當函式帶有參數時並不會知道是什麼內容，相對的需要各種檢查(record忘記加上s，所以得到undefined)
TypeScript彌補JS的缺點
- TS提供型別的定義跟規範，幫助建立中、大型應用程式
- 宣告變數/常數的當下就可以設計型別
- 能根據定義做提示，減少出錯
- 如果沒有單元測試或TS的處理，JS很容易出錯
使用TypeScript的理由：
- 強型別
- 更著重設計
- 適合多人開發的專案
- 與現有專案無縫整合
- 非常完整的開發工具支援
- 持續發展的社群
採用 TypeScript 前你該考慮的十件事 — Jeremy Lu
TypeScript的優點：
- 可以視為永遠update to date的文件
- tooling — autocomplete 、jump to definition、 quick access to documentation 、refactoring 、renaming
- type check
- 業界流行
雖然前面說了TypeScript的優點，但缺點也是不少的：
- 需要更多時間寫正確 type
- 為了 compile 過，常常需要改變寫法
- 閱讀code變更慢（code 變多），每次閱讀要再花更多時間
- 需要更多時間維護，typing會因程式變動而過時
- 3rd party library 是否支援？（eg. day.js, moment）
- 平均增加 30~50 % 開發時間！
- 不安全 - non-soundness 可能造成 runtime 出現無法預期的錯誤
- 用 any 等於沒使用TypeScript
- 錯誤的安全假象 - 還是需要大量的tests，等於用人工智慧實現completeness
- If it compiles, it runs → 不適用於TypeScript
替代方案：
- flowtype - JS世界最友善的strong type系統(soundness優先)
- 降維打擊 - 乾脆不用，但調整 mindset，採用FP手法 （OO -> FP），第一步可採用ramda、sanctuary等FP library，第二步學習正統FP手法
- 換開工法 - 使用狀態機、xstate
- 換語言 - AltJS -> Elm、PureScript、ReScript ；to WASM -> Haskell、Rust
