為什麼這篇electron-packager教學鄉民發文收入到精華區：因為在electron-packager教學這個討論話題中，有許多相關的文章在討論，這篇最有參考價值！作者brli7848 (星の妄想)看板Soft_Job標題Re: [討論] 請大家聊聊 JavaSc...
在開始之前，先說個笑話
※ 引述《keev (a)》之銘言：
: 我會試著反駁 互相交流
然而下面這串推文直接被無視
: 推 vi000246: 還要學打包工具 好麻煩 11/03 00:22
: 推 s06yji3: 要打包真的好麻煩，參數也太多太細。 11/03 00:31
: 推 fiiox3: 打包真的.....從來不覺得自己懂過XD 11/03 00:34
好的，沒事幹新年開始就考古，我就廢.jpg
先來看個實際存在的專案結構在 npm install 後
zettlr/node_modules/archiver-utils/node_modules/readable-stream/node_modules/
inherits/LICENSE
三層啊！大大們！光是一個 lib 就埋了三層啊！
有哪個 C/C++/Java/python 編譯完的專案 lib 埋這麼多層的?
我認識的頂多就 /usr/lib/project_name/something.so
或 /usr/lib/python3.??/site_packages/project_name/something.pyc
先不說在 Windows 那種幾乎所有軟體都吃自己不分享的系統
OSX 跟 Linux/BSD 上面大多都是 shared lib 的情境下，這樣搞是要?
喔對了，獨眼龍都知道有個 yarn --flat 可以用，但是，在座有成功用這個參數安裝後
專案動得起來的嗎?
然後，或許有人還記得，早期的 npm 甚至會因為使用者下載源碼的時間落差
導致取用的函式庫版本更迭，導致明明 package.json 沒問題，專案卻無法編譯的慘況
所以才又出了個 .lock 規格，然後官方還建議這個一定要放進去版控
恩恩，然後就 https://i.imgur.com/jQaZa1A.png
想當然爾，菜雞小弟就丟去論壇發問，結果回應居然是:
: 請 npx install 某包 -g
: (隨回應附上 npm 官方文件來源)
大大！是 -g 啊！在系統固有的套件管理員之外用 global 啊！
是不是沒在 package.json 裡看過
scripts: {
"postinstall": "",
}
啊?
這隨便寫加上無腦建議人家 sudo npm -g
有沒有突然覺得公司裡 IT 呼吸的空氣真甜美？
我橫豎睡不著，仔細看了半夜的 npm 官方文件，才從字縫裡看出字來 NPM_CONFIG_PREFIX
聖光啊!!!
都已經 2020 了，相依管理這種千禧年初就早在業界已經談到爛、解法多到爛的情況下
js 生態系居然還端出這種垃圾專案管理程式，然後所有人都撇過頭去，只敢討論 NaN 到
底在做什麼、到底有沒有符合標準這種技術細節
喔對了，說到直接建議使用者安裝新軟體
https://github.com/ganeshrvel/npm-electron-root-path/blob/master/lib/index.js
https://github.com/domenic/sorted-object/blob/master/lib/sorted-object.js
從沒看過這麼頹廢、衰敗、小學生等級的套件
後者還天殺的有 382,233 Weekly Downloads!!!
https://www.npmjs.com/package/sorted-object
這種資料結構 101 型還可以寫成套件，還可以拿來引用?
業界是多少人懶得寫 function 還是不會寫而只會 call function? 太瘋狂了!!
這還不包括整個社群瘋狂重造車輪，接著寫完就拋棄！！！
請問現在要寫個 electron app，我該用 electron-builder、electron-forge、還是
electron-packager?
一個寫完，然後發現太大太雜不好維護，就他X的另起爐灶，然後整個社群就hype惹
我以為我在觀察國高中的童軍康輔社團而不是專業人士社群呢顆顆
npmjs.com 上面多少最後更新在兩年以上，但是每週下載數依舊很高的套件
喔還有很天才的，按照官方文件寫 package.json
結果 npm install 拚命跳出某lib在某版本前有問題，建議更新到某版以上的warning
還有永遠會跳出來的fsevent warning，就說我不是Mac了!!!(怒
還沒開始寫程式，光是搞定框架就挫折連連，是要怎麼舉出 JavaScript 的缺陷呢?
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.39.76.65 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1609942455.A.51A.html
推 tommady: 我無法闡述更多，只能推 01/06 22:26
推 deeeplove: 推 01/06 22:30
→ deeeplove: 現在學到崩潰 01/06 22:31
推 abola921: 淚推，同情npm 用戶 01/06 22:34
→ LipaCat5566: 這都不是語言本身的問題吧 01/06 22:39
推 zxcasdjason1: npm算是用順手 但看完你這篇我是感觸很深的笑了 01/06 22:45
推 jlhc: 這不是語言的問題那甚麼才是語言的問題... 01/06 22:46
→ jlhc: 笑了給推 01/06 22:47
推 cloudskyblue: 就是這樣啊～ ♂ 01/06 22:48
→ cloudskyblue: 攤手 01/06 22:48
→ zxcasdjason1: 但換角度說 js就是彈性大 重構比維護更有效益下 的 01/06 22:49
→ zxcasdjason1: 確是這樣呢 01/06 22:49
重構比維護更有效益？小工程師敢跟 lead 說老子覺得重構比繼續每天攪義大利麵還有效益？
lead 敢去跟主管說我覺得敝 team 繼續每天攪義大利麵很無意義，建議重構？
技術主管敢去跟其他部門開會說我覺得公司的軟體重構比維護更有效益？
看誰先被釘牆上然後卷舖蓋QQ
阿這時候就別羨慕人家其他師字輩可以學一套混30年
是你各位自己說出重構比維護更有效益的呀 大大每隔一下就重構 底下就吃屎重學新東西
幫QQ
推 peterlai: npm 包來包去真的恐怖，還有一堆奇怪的套件 01/06 23:10
推 alihue: 還好我只用 npm is-odd 01/06 23:12
推 lturtsamuel: npm出來還被說是仰賴地獄的救贖 現在被婊成這樣 蠻好 01/06 23:15
→ lturtsamuel: 奇大家都用什麼語言跟套件管理的 01/06 23:15
→ lturtsamuel: 我只有rust+cargo 覺得比npm好用 其他java ruby pyth 01/06 23:16
→ lturtsamuel: on感覺問題都比npm多 01/06 23:16
pip 下去，他就是平鋪一層 lib/要找哪個環節的哪個函式庫在雷很方便
java 看是哪個框架，至少 gradle 下去也是所有的東西在一個地方排排站
沒看過埋了一層又一層嫌人家找的不夠開心的
→ lturtsamuel: 順便問一下 有人用過比cargo更屌的建置工具嗎== 01/06 23:18
推 lturtsamuel: 仔細看這篇文章 大部分都是在婊函式庫作者 呃 這算語 01/06 23:33
→ lturtsamuel: 言問題嗎？那張diff截圖也看不出來是要表達什麼問題 01/06 23:33
就是古早時代，同兩個被依賴的函式庫，只因為安裝順序不同就沒事幹產生新lock檔搞人
阿然後社群解法是
$ npx npm-merge-driver install -g
→ lturtsamuel: 更令我不能理解的是資料結構為什麼不能寫成套件？還 01/06 23:35
cd ../../../ 這種一行文，寫成套件被笑剛好而已資料結構你說爬樹還搜尋甚至動到演算法的，寫成套件嘉惠後人就算了
swap A B？！
→ lturtsamuel: 有跟你報當前版本有安全性疑慮 你不開心的點是？ 01/06 23:35
這是我的錯，沒講清楚我是指說 package.json 裡我已經努力使用最新版了
結果某個函式庫它的 N層後 的相依有 CVE，然後我要負責？
→ lturtsamuel: 如果你想表達開源函式庫的文件過時了 呃 這在哪個語 01/06 23:38
→ lturtsamuel: 言都嘛有 連公司裡面文件都時常過時 到底干js屁事 01/06 23:38
推 x123356: 同意樓上 全篇看下來覺得關JS什麼事 01/07 00:03
→ x123356: 前面幾篇認真討論的才真的是JS本身的問題 01/07 00:03
你各位寫 JS 到現在都不用 nodejs / npm / npm 衍生物來安裝東西？還是說覺得語言的 flaw 跟它本身奠基在哪個 framework 沒有關係？
推 GLaDOS1105: 詳細來說這個是 JavaScript 生態的問題 不過的確這和 01/07 00:08
→ GLaDOS1105: 語言本身可以一起討論 01/07 00:08
推 mirror0227: wwww這篇怨念很深 01/07 00:29
→ x000032001: 大概是只有spec上的才是語言問題 其他都是使用者的毛 01/07 00:40
問題是，就像上面的資料結構人家 PEP, C conf, C++ std 每年都在努力讓語言更好上手，加進一堆常備函式
結果大 JS 生態圈的回應是：「反正社群有」，「不會npm i嗎？」，「我就彈性大啊」
燈愣！？是當作所有開發者的網路流量都不用錢？還是覺得討論 spec 不酷，太古板？
推 lturtsamuel: 工具鏈或標準庫的問題當然也能算是語言一部分 問題這 01/07 00:50
→ lturtsamuel: 篇都婊到開源函式庫了...你有閒自己寫資料結構別人不 01/07 00:50
→ lturtsamuel: 一定有啊 你可以不爽不要用 特別去婊一個自己不使用 01/07 00:50
→ lturtsamuel: 的函式庫 是在幹嘛？ 01/07 00:50
left-pad 事件言猶在耳→ lturtsamuel: 這篇唯一講得有道理的就是那個層層包裝的依賴關係 但 01/07 00:52
→ lturtsamuel: 正是這個做法解決了很多c c++ java的依賴地獄 你有沒 01/07 00:52
→ lturtsamuel: 有看過因為openssl版本多一位數導致一個c++專案編譯 01/07 00:52
→ lturtsamuel: 不過 最後要用一些奇淫手段引入兩個openssl 從結果上 01/07 00:52
→ lturtsamuel: 來說做的就是npm一樣的事情 01/07 00:52
一個專案引用同一個函式的兩個版本，這是工程師在雷的問題吧？要同時支援兩個版本是你組織的問題還是程式的問題？
這裡說的是同一個釋出版，而不是只說為了承諾而維護老版本的專案
推 lturtsamuel: 在c++引入兩個不同版本的lib才叫痛苦咧 什麼symbol衝 01/07 00:55
→ lturtsamuel: 突header衝突 搞死你 01/07 00:55
你可以重新針對新symbol/header編譯…喔對了，要用函式庫就乖乖去跟好人家的釋出管道跟新聞…
當然，這種習慣被 nodejs 生態系搞到光 track down 就炸裂那就是另外一回事惹
推 guanting886: 推怨念深 01/07 01:16
→ guanting886: 可是這是NPM捏XD 01/07 01:17
所以最後才會說都還沒開始探討 JS 語言本身，光是怎麼開始就已經全身是傷了推 askaleroux: 專案最近用Lerna 全部都monoRepo 01/07 01:44
→ askaleroux: 最近用一些套件真的他媽賭爛 01/07 01:45
→ askaleroux: 幹都不寫type的 我寫type script找不到function用 01/07 01:45
→ askaleroux: 都要一個一個通靈去看 媽的 01/07 01:45
→ askaleroux: javascript要是我可以不要用 鬼才想用 01/07 01:45
推 Bencrie: 耶 其實現在有多一層啦 /usr/lib/x86_64-linux-gnu/ 01/07 02:11
至少人家都一起在 lib/x86_64-linux-gnu/下排排站，頂多因為專案太大，提供太多lib所以多一層像是 qt5/libQt5Core.so 這樣子把自己的東西都放一起
還一層一層往下放 lib/ 資料夾咧？嚇死人
推 tsao1211: 生態也算是一部分，沒生態根本也不會有人討論 01/07 03:30
噓 MoonCode: 01/07 05:41
本篇第一噓，恭喜推 superpai: 你可以改用bower啊 01/07 05:52
While Bower is maintained, we recommend using Yarn and Webpack or Parcel forfront-end projects
雖然 Bower 有在維護，但是前端專案我們建議使用 yarn 加上 webpack 或 parcel
不是我說的喔， https://bower.io 標題下面第一行
推 OhNo386: js問題就是太容易學了，才會ㄧ堆人學然後一堆人重複造輪 01/07 06:26
→ OhNo386: 子，不過這應該很難避免，易學難精總還是有它的代價。 01/07 06:26
→ OhNo386: 這應該都是高階語言的通病啊 01/07 06:31
→ jobintan: 要用NPM打包的JS我都會與React一塊用。 01/07 07:15
→ jobintan: 不過我都用Yarn居多。 01/07 07:15
說真的啦，反正都會跳警告，至少 yarn 還會跟你說是幾層後的東西有人戳npm呢?
found 15 low severity vulnerabilities
run `npm audit fix` to fix them, or `npm audit` for details
然後就，過去惹@@?!
喔對了， npm audit fix 後有機率這個剛 clone 下來的專案會直接 error 給你看
→ meowyih: 都二個月前的文了還挖起來繼續戰啊... 01/07 09:03
→ ab4daa: 可憐哪 01/07 09:04
推 Csongs: 自己寫side project 也很痛苦，不知業界node js怎管 01/07 09:10
※ 編輯: brli7848 (114.39.76.65 臺灣), 01/07/2021 10:34:24推 mmis1000: 我倒是希望全世界都是結構阿，要不至少也強制不同版本路 01/07 10:34
→ mmis1000: 徑不衝突，那種同時跑兩個專案會因為全域依賴衝突跑不起 01/07 10:34
→ mmis1000: 來的依賴管理簡直笑死人，沒docker我都不知道怎麼辦 01/07 10:34
apt, dnf, yast, pacman 應該都遇不到這個問題？→ shadow0326: venv: 01/07 10:41
好用推 mmis1000: 然後我不知道你用的npm到底是幾個版本前的，他大概 3 年 01/07 10:41
→ mmis1000: 前裝出來的就是平的了，你的工具到底多老 01/07 10:41
btw, I use Arch.沒意外應該 nodejs, npm 都是最新的穩定版
→ SoftwareSing: npm 現在裝的都是平的 01/07 11:31
→ SoftwareSing: 除非你曾經有不同lib依賴同一個lib的不同版本 01/07 11:32
→ SoftwareSing: 但都是用B的同一個版本的情況，裝出來會是平的 01/07 11:45
那個三層結構是去年7月間去戳程式時的實際情況以你的例子不就是因為依賴的上游有人偷懶只用舊版
導致依賴性一直往下長嗎？
阿這個舊版剛好依賴一個舊版的上游...，boom! cve warning!!
推 lturtsamuel: 笑了 我要用的兩個函式庫要依賴兩個openssl版本 我能 01/07 15:12
→ lturtsamuel: 怎麼辦 01/07 15:12
看來只能用妖術了呢…拍拍已經compiled出來還不能改原碼重編的函式庫，有時候就…很難搞呀
推 jlhc: 現在是比爛就是了xdxd 01/07 15:25
※ 編輯: brli7848 (42.77.106.21 臺灣), 01/07/2021 17:02:51→ leo5916267: Js寫的越深越覺得自己一直在繞圈圈， 01/07 18:14
→ xatier: 某樓一直繞圈圈，不愧是寫 JS 的高手ㄋ 01/07 19:56
→ xatier: 工具幫忙解決相依性問題是一回事，生態圈鼓勵大家隨便一把 01/07 19:57
→ xatier: 抓相依性，從不去思考是不是一定非得引入這個相依，出事了 01/07 19:58
→ xatier: 就硬 override ，那才是真正的問題。說到底不是 JS 本身的 01/07 19:58
→ xatier: 問題，而是生態圈主流作法和 **人的問題** ^^ 01/07 19:58
→ xatier: 再好的依賴管理工具也無法解決習慣亂拉依賴的人 01/07 20:02
推 SmallpTsai: 說的好 XDDD 01/07 22:36
→ ku399999: 雖然已經有人解釋npm了 但我還是想貼個笑話 01/08 10:13
推 strlen: 那都是套件的問題 跟語言本身無關（捧讀 01/08 11:55
推 Geison: 這怨念，是受了什麼刺激哈哈 01/08 13:36
推 mmis1000: apt那叫哪門子的能選版本…你就只能用他上面有的阿，要 01/08 13:54
→ mmis1000: 是沒有，你要嘛重寫程式要嘛自建repo 01/08 13:54
是不知道你是用了什麼軟體，版本會在 apt 找不到啦…通常 Ubuntu 會提供至少同一套 lib 的兩個版本，像是 openssl2/1.1
你要的上面找不到，有兩個可能
1. 你要的太新，選的發行版太舊：要麼就自己用系統 toolchain 編新版甚至架 repo
要麼更新系統的版號←可能會被炸（無論是公司或是系統）就是惹
2. 你要的太舊，選的發行版沒收：那就乖乖重寫阿…連 py2轉3都要考慮半天的 u 家都
不收的東西，可能連上游都不想理了，遇到bug/安全漏洞向誰哭？
喔，另外一種情況，你的 apt 是指 Debian，那就…docker 囉
推 mmis1000: 另外，目錄結構是lock的一部分，如果這個專案過去的安裝 01/08 14:03
→ mmis1000: 方式就是超深樹狀，那同一個lock安裝後的結果也會是 01/08 14:03
好問題，那要怎麼更新 lock，然後避免在協作下更新 lock 導致 git 大塞車大抱怨？或許現在近期好很多了啦，但是如我上面截圖，這種自己換位子的
要怎麼讓同組其他同事不炸conflict？
推 newjett0617: 推 01/08 23:17
※ 編輯: brli7848 (42.77.23.173 臺灣), 01/09/2021 13:17:02→ cy91244: 只要用 npm ci 就不會動到lock file；升級或新增deps就 01/09 18:30
→ cy91244: 要發PR,merge後其他人再npm ci安裝。 01/09 18:30
→ brli7848: 問題是不動lock就是要面對那個積塵已久的超深樹狀啊 01/09 19:54
→ brli7848: 2018…我第一次掉坑的時候是2015呢…當時什麼都… 01/09 19:57
→ cy91244: 可以動啊，你想要 npm dedup 也行，就是動了就是發 PR 01/09 21:29
→ cy91244: 其他人一樣等merge 後再 npm ci 01/09 21:29
恩，剛好驗證我上面回的上面一腦衝重構，底下就得吃屎學新東西
好好的 npm i 不維護，結果只能跑去生一個新的 ci 指令
然後社群裡就充斥著樓上的解法「阿你可以這樣繞一圈就過啦」
問題是…整個網路上累積幾年的 npm i 教學，然後…現在是每個新人都要踩一遍雷？QQ
推 daddy29: 前端腦 河河 01/09 22:28
推 Nitricacid: 精闢 01/10 11:58
※ 編輯: brli7848 (42.77.23.173 臺灣), 01/10/2021 15:03:32推 clang: 推怨念深 01/17 21:15