class 仍然會在某些上下文被認為是 JavaScript 中的關鍵字,這時仍然避免不了重命名
更恐怖的是,項目裡出現 class 和 className 兩種不互通的傳遞 CSS 類規範,編寫通用組件的時候要麼處理更費勁,要麼就是埋下未來樣式不生效的隱患
class 仍然會在某些上下文被認為是 JavaScript 中的關鍵字,這時仍然避免不了重命名
更恐怖的是,項目裡出現 class 和 className 兩種不互通的傳遞 CSS 類規範,編寫通用組件的時候要麼處理更費勁,要麼就是埋下未來樣式不生效的隱患
一般沒有直接把非 Promise 傳進去的場景吧,感覺這個需要寫個 lint 規則約束一下…
一般沒有直接把非 Promise 傳進去的場景吧,感覺這個需要寫個 lint 規則約束一下…
用 magick 以 100 的質量把原圖轉換成 jpg 格式的話可以得到跟 atproto 上那張大小幾乎一樣的圖片(為什麼還差一點點就不是很清楚了,可能算法差異)
可以判定是圖片存到 atproto 之前轉換了一下格式
用 magick 以 100 的質量把原圖轉換成 jpg 格式的話可以得到跟 atproto 上那張大小幾乎一樣的圖片(為什麼還差一點點就不是很清楚了,可能算法差異)
可以判定是圖片存到 atproto 之前轉換了一下格式
原截圖是 31.6KB,直接用瀏覽器訪問 atproto 上的 blob,HTTP 請求的總大小是 138KB,怎麼會事呢🤔
原截圖是 31.6KB,直接用瀏覽器訪問 atproto 上的 blob,HTTP 請求的總大小是 138KB,怎麼會事呢🤔
www.youtube.com/watch?v=biUF...
www.youtube.com/watch?v=biUF...
看到項目裡幾個引用的 @std,想起上次解決的辦法,覺得應該又是哪個 @std 下的包在作妖,突然心血來潮更新了一下 Deno,之前 Workflow 裡一直在用 1.x,而咱本地 1.x 和 2.x 都有,更新到了跟咱本地相同的 Deno 2 版本,結果編譯就通過了…
所以緣由應該是 jsr:@std 有一些不能向後兼容的部分(尤其是在容器中編譯為單可執行文件這樣的邊緣場景),但是沒在他們的文檔上找到任何說明
但就算它不向後兼容 1.x,咱在本地不知道為什麼還是可以用 1.x 編譯通過,太詭異了簡直是玄學
看到項目裡幾個引用的 @std,想起上次解決的辦法,覺得應該又是哪個 @std 下的包在作妖,突然心血來潮更新了一下 Deno,之前 Workflow 裡一直在用 1.x,而咱本地 1.x 和 2.x 都有,更新到了跟咱本地相同的 Deno 2 版本,結果編譯就通過了…
所以緣由應該是 jsr:@std 有一些不能向後兼容的部分(尤其是在容器中編譯為單可執行文件這樣的邊緣場景),但是沒在他們的文檔上找到任何說明
但就算它不向後兼容 1.x,咱在本地不知道為什麼還是可以用 1.x 編譯通過,太詭異了簡直是玄學
然後抱著試一試的心態把 @std/path 的導入換成了 node:path(Deno 開發的 Nodejs 兼容層),結果編譯通過了!!
當時想著它能跑了就盡量不動這裡的代碼了,只留下了一行注釋,而至於出現的原因就不了了之了
最近需要重構這個項目,這個打印其實只是當時臨時用的,於是就整個文件刪掉了,離譜的是項目又開始在 Workflow 裡編譯報錯了…
然後抱著試一試的心態把 @std/path 的導入換成了 node:path(Deno 開發的 Nodejs 兼容層),結果編譯通過了!!
當時想著它能跑了就盡量不動這裡的代碼了,只留下了一行注釋,而至於出現的原因就不了了之了
最近需要重構這個項目,這個打印其實只是當時臨時用的,於是就整個文件刪掉了,離譜的是項目又開始在 Workflow 裡編譯報錯了…