早上開時做了一個決定後,今天能開始進行開發時已經是天黑的時候了。今天什麼事都不做,就將這問題記錄下來,或許這樣的遭遇能節省其它開發者不少時間。
吃完早餐後,著手準備來做後端,也就是拿取玩家資料的部份。原先是想用golang加上gqlgen,但gqlgen一些設定一直不是很清楚,再加上golang一直沒有很熟練的情況下,決定退回去用javascript或是typescript,反正graphql-codegen對於這樣的支援反而是最完備的。但目前開發都是放在container裡,一但host的程式碼有修正,就只能夠重新docker run,多數情況下,node_modules是不進入到docker裡的,但不知道為什麼dependencies安裝需要花去不少時間,來來回回不停的修改、重啓,很花時間的(但和Unity環境比起來,好像還是快不少,編譯都是以分鐘計的),不管怎麼樣,還是要一個可以快速開發的方式,自然地就想起了nodemon。
一陣子沒有碰nodemon了,網路上找了個文章,有附git repo的。就想說拿下來後直接進行container的執行,執行相當的順利,不過script端怎麼改都沒有看到任何改變。一定是這個開發者的nodemon沒有設定好,於是就再找下一個。就這樣一個接著一個的範例去試。各式各樣的組合
參考的文章:
了這麼多文章,不管怎麼試,怎麼修改程式碼,nodemon就是沒有反應。總不可能每個開發者都沒設定好吧,但真的不知道哪裡有問題,也都覺得是不是無法開發nodejs的後台,但權衡輕重之下,nodejs和graphql的銜接還是遠遠優於golang,如果可以,還是要將開發環境建構起來。又花了時間稍微想一下,那裡是有可能導致問題的所在?最有可能的是目前的開發環境
WSL2或許是最可疑的,因為它是前幾個月才出來的,之前都是WSL1。果然按照這樣的線索去找問題,查詢後果然就跑出了幾篇文章。
這些文章是透露出nodemon和WSL2不合的訊息,但怎麼看都不知道怎麼修正目前手中碰到的問題。直到找到了這一篇,並且用不確定的心態進行嘗試,才終於找到真正的解決方案。
這篇討論了有一個關鍵的訊息
You should not need CHOKIDAR_USEPOLLING=true since file system events should be propagated to the container.
雖然它是寫著不需要,但這個關鍵字一但出現了,卜要來試試看。在docker-compose.yaml裡加上了這個環境變數後
environment:
- CHOKIDAR_USEPOLLING=true
nodemon就開始正常工作了。
這篇Docker官方的文章裡是有提到
docker run -e CHOKIDAR_USEPOLLING=true -v ${PWD}/src/:/code/src/ repository/image_name:development
之前用Mac時開發後端真是方便,不論是homebrew或是docker,都很順利,現在的windows環境,真的是很不適合開發後端。今天的時間全都耗在這上面了,接下來只能抓緊一些些的時間來規劃一下實際的開發架構。