整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
作者 | Kitson Kelly
譯者 | 王強
策劃 | 小智
2018 年 5 月，Ry 公開 Deno 的原型后不久我就開始參與這個項目了。對于 Deno，人們最常問的一個問題是“包管理器跑哪兒去了？”很多時候這都算不上問題，而只是一種吐槽。他們會說“我知道 Deno 很重視安全性，可是從互聯網下載資源是不安全的。”或“沒包管理器我該怎么管理依賴項啊？”
本文最初發布于 網站，經原作者授權由 InfoQ 中文站翻譯并分享。
在我看來，我們應該改變自己的思維模式。因為包管理器和中心化代碼庫隨處可見，所以很多人把它們當成了理所當然的需求。問題在于它們的流行并不是它們不可或缺的證明。這些事物之所以會出現，是因為它們以某種方式解決了問題，可大家就覺得這是解決問題的唯一途徑了。我認為這種看法是不對的。
想象一下這樣的場景：在發布網站時，我們不是登錄到一個谷歌中心服務器上，而是將我們的網站上傳到一個存儲庫中。然后當有人想查看我們的網站時，他們要使用命令行工具，在我們本地計算機上的 browser.json 文件中添加一個條目，再訪問并獲取整個網站；另外還要獲取鏈接到我們本地 目錄的其他所有網站，獲取完畢后才能啟動瀏覽器開始瀏覽。這也太瘋狂了不是嗎？那么為什么跑代碼的時候就非得用這種模式呢？
Deno CLI 的工作機制和瀏覽器很像，只不過瀏覽的是代碼而非網頁。你在代碼中導入一個 URL，Deno 將獲取對應的代碼并將其緩存在本地，就像瀏覽器那樣。另一個和瀏覽器類似的地方是，你的代碼運行在沙箱中，沙箱對其中運行的代碼（不管其來源如何）的信任度為零。你（調用代碼的人）需要從沙箱外部告訴里面的代碼可以做什么，不能做什么。最后，代碼可以要求你執行操作，你可以選擇授權或拒絕，這也和瀏覽器是一樣的。
我們了解代碼所需的一切信息都可以由 HTTP 協議提供，并且 Deno 試著充分利用這種協議，這樣就用不著發明新的了。
代碼發現
首先要認識一點：就像瀏覽器一樣，Deno CLI 不想對你運行的代碼有任何意見（opinion）。它列出了如何獲取代碼，以及如何在計算機中使用沙箱運行代碼的規則。我認為運行時應該表達的意見就到此為止才對。
在 Node.js/npm 生態系統中，我們將本地計算機上的代碼管理與中心化代碼存儲庫結合在了一起，從而幫助開發人員更方便地發現代碼。我認為它們兩者都有非常嚴重的缺陷。
在互聯網的早期，我們就嘗試過 npm 這一類的代碼發現模式。你可以將你的網站添加到 Yahoo! 網站正確的分類下，然后人們就會來瀏覽；他們可能也會使用搜索功能，但所有這些都是基于內容提供者的觀點來構建的，卻并沒有真正針對消費者的需求而優化。后來谷歌誕生了。為什么谷歌成為了贏家？因為它很好用。它將搜索詞與滿足需求的最相關網頁匹配起來，用這種方式來索引網站；索引過程考慮了多種因素，內容提供商提供的元數據只是其中之一。
雖然我們還沒有把這套模型納入 Deno，但它是可行的方案。此外，我們之所以使用谷歌是因為它為我們解決了問題，而不是有人說“你必須使用谷歌”；而且谷歌還有其他可行的替代方案。
我在推特上與 Laurie Voss 進行了一場辯論，我覺得他非常了解 npm 生態系統。他認為 Deno 需要包管理器，而本文是我的觀點的詳盡闡述。但是 Laurie 提出了一個非常合理的觀點。
GitHub 已成為開源代碼的家園，因為它非常好用并解決了很多問題；它是基于源代碼版本控制工具的事實標準 git 構建的。從 Deno CLI 的角度來看，源代碼的來源應該沒有技術上的限制，我們需要更加廣闊的生態系統，以創造并發展更多途徑來向社區展示 Deno 中的代碼，這些途徑可能是我們這些創建 CLI 的人們從未想過的創新形式。
可重復構建
在 npm 生態系統中這是一個問題。由于嚴重依賴語義版本控制，并且復雜的依賴圖往往來自 Node.js/npm 生態系統，因此想要讓構建可重復就成了一個挑戰。Yarn 引入了鎖定文件的概念，npm 也跟上了腳步。
我個人感覺這有點像是在拆東墻，補西墻：生態系統中開發人員的行為造成了一個問題，然后為了解決它又開發出了一個不完善的解決方案。長年和生態系統打交道的人都知道，很多問題的解決辦法就是 rm -rf package-lock.json && npm install。
而 Deno 為這個問題提供了兩種解決方案。首先是 Deno 緩存模塊。它可以將緩存 check in 到源代碼版本控制中，使用 --cached-only 標志就不會檢索遠程模塊。 環境變量可用于指定高速緩存的位置，以提供更大的靈活性。
其次，Deno 支持鎖定文件。--lock lock.json --lock-write 將使用給定負載所有依賴項的哈希值寫出一個鎖定文件。當使用 --lock lock.json 時，這將用于驗證將來的運行。
還有一些命令可以管理可重復的構建。deno cache 將解析所提供模塊的所有依賴項，并填充 Deno 緩存。deno bundle 可用于生成負載的單個文件“構建”，所有依賴項都已解析并包含在該文件中，因此將來的 deno run 命令只需要這一個文件即可。
信任規則
我認為這是另一個需要打破固有思維的領域。無論出于何種原因，我們都無條件地信任中心化存儲庫中的代碼。我們甚至都沒有考慮過這種信任是不是合理。不僅如此，我們相信其中的代碼已完全審查了所有依賴項，進而信任這些依賴項。我們打開快速搜索框，輸入 npm install some-random-package，然后就覺得萬事大吉了。我認為豐富的 npm 軟件包生態系統把人們慣壞了。
為了應對這種松懈和自滿帶來的風險，我們在工具鏈中加入了安全監視軟件，用來分析我們的依賴項和數不清的代碼，告訴我們哪些代碼可能存在安全隱患。一些公司會開發自己的私有存儲庫，上面托管的軟件包接受的審核可能比那個公共存儲庫中的更嚴格一些。
這就好像是房間中的那頭大象。最佳策略是我們不應該信任任何代碼。只要我們建立了這種認識，那么正視那頭大象就會變得容易一些。但是，如果我們認為包管理器和中心化存儲庫可以解決這個問題，或者哪怕是幫助緩解了這個問題，其實我們就是在自欺欺人。實際上，我認為它們的流行讓我們的警惕性下降了。“反正它是放在 npm 上，如果它有什么隱患，肯定會有人把它撤下去的。”
Deno 在這方面的工作還不盡如人意，但它起碼有一個好的開始。它在啟動時是零信任的，并提供了相當精細的權限調整。我個人不喜歡的一件事是 -A 標志，它基本上是在說“好的，那就允許一切權限”。焦頭爛額的開發人員很難經得住它的誘惑，而不會去弄清楚自己真正需要的是哪些權限。
收回這些授權也是很困難的事情，要指明“這段代碼可以做這件事，但這里的另一段代碼就不行”，或者當代碼提示自己要提升權限時，搞清楚這些代碼是從哪兒來的——這些都是很麻煩的操作。希望我們能找到一種易用的機制，并結合一些在運行時好用且高效的方法來解決這些挑戰。
不過，最近的一個變化在我看來是很不錯的，那就是 Deno 不再允許你降級 imports。如果從 導入了某些內容，那么這些內容只能從其他 位置導入。這和禁止降級傳輸的瀏覽器模型是一致的。不過我還是認為從長遠來看，最好取消所有未通過 進行的遠程導入，就像服務 Workers 需要 HTTPS 一樣。對此我們將拭目以待。
依賴管理
我認為我們需要坦率地談談 npm 生態系統中的依賴項。老實說，這個生態是有問題的。在這個生態系統中，這區區 5 行代碼每周會下載 3 千萬次：
可是過去 9 年來所有瀏覽器都有這些代碼，Node.js 根本用不著它們——這樣的生態系統是不正常的。在這個例子中，實際的代碼只有 132 個字節，但打完包就變成了 3.4kb。可運行代碼只占包大小的 3.8％。“這樣也行！”
我覺得這種現狀背后有幾點成因。其中很重要的一點是我們走反了方向，用的是顛倒過來的模型。問題在于，這種倒退的模式已經改變了我們創建網站的方式。盡管沒有中央存儲庫，但是在構建網站時，我們將下載所有依賴的代碼，并將它們烘焙到服務器上加載的內容中，然后用戶將一堆代碼下載到他們的本地計算機上。一些證據表明，所下載的代碼中只有大約 10％是所訪問的站點或 Web 應用程序獨有的，剩下的那些是我們下載到開發工作站并打包起來的代碼。 等解決方案就想要解決這種因為走錯方向而導致的問題。
另一個重要的問題是我們的依賴項沒有與我們的代碼耦合起來。我們將依賴項放入 package.json，但我們的代碼是不是會真的使用這些依賴項呢？另一方面，雖然我們的代碼表示我們正在使用其他一段代碼中的內容，但它與后者的版本之間并沒有緊密的耦合關系。問題是另外這段代碼會直接影響我們正在編寫的代碼，因為它們之間的確存在依賴關系。
下面就輪到 Deno 模型登場了，我喜歡稱其為 Deps-in-JS，因為大家都在用這種叫法。這種模型將我們的外部依賴項顯式聲明為 URL，意味著代碼與其他代碼之間的依賴關系簡潔明了，并且我們的代碼和依賴項會緊密地耦合在一起。如果要查看依賴圖，只需對一個本地或遠程模塊使用 deno info：
$ deno info https://deno.land/x/oak/examples/server.ts
local:?$deno/deps/https/deno.land/d355242ae8430f3116c34165bdae5c156dca21aeef521e45acb51fcd21c9f724
type: TypeScript
compiled: $deno/gen/https/deno.land/x/oak/examples/server.ts.js
map: $deno/gen/https/deno.land/x/oak/examples/server.ts.js.map
deps:
https://deno.land/x/oak/examples/server.ts
??├── https://deno.land/std@0.53.0/fmt/colors.ts
??└─┬ https://deno.land/x/oak/mod.ts
????├─┬ https://deno.land/x/oak/application.ts
????│ ├─┬ https://deno.land/x/oak/context.ts
????│ │ ├── https://deno.land/x/oak/cookies.ts
????│ │ ├─┬ https://deno.land/x/oak/httpError.ts
????│ │ │ └─┬ https://deno.land/x/oak/deps.ts
????│ │ │ ├── https://deno.land/std@0.53.0/hash/sha256.ts
????│ │ │ ├─┬ https://deno.land/std@0.53.0/http/server.ts
????│ │ │ │ ├── https://deno.land/std@0.53.0/encoding/utf8.ts
????│ │ │ │ ├─┬ https://deno.land/std@0.53.0/io/bufio.ts
????│ │ │ │ │ ├─┬ https://deno.land/std@0.53.0/io/util.ts
--snip--Deno 沒那么在乎代碼的“版本”。URL 就是 URL。盡管 Deno 需要適當的媒體類型以了解如何處理代碼，但關于要提供哪些代碼的所有“意見”都留給了 Web 服務器來決定。服務器可以對其核心內容實施語義版本控制，或者對 URL 到所需資源進行任何形式的“魔術”映射。Deno 并不在乎這些。例如， 實際上只是一個 URL 重定向服務器，它會重寫 URL，以在重定向的 URL 中包含一個 git commit-ish 引用。于是 @v4.0.0/mod.ts 變成了 ，這里 GitHub 扮演了一個不錯的版本化（）模塊的角色。當然，在整個代碼庫中散布“版本化”的遠程 URL 沒有多大意義，所以不要這樣做。盡管依賴項只是代碼而已，但最妙的是你可以按照自己想要的任何方式來構造它們。常見的約定是使用 deps.ts，它將重新導出你可能需要的所有依賴項。看一看 oak 服務器的例子：
// Copyright 2018-2020 the oak authors. All rights reserved. MIT license.
// This file contains the external dependencies that oak depends upon
// `std` dependencies
export?{ HmacSha256 } from?"https://deno.land/std@0.51.0/hash/sha256.ts";
export?{
??Response,
??serve,
??Server,
??ServerRequest,
??serveTLS,
} from?"https://deno.land/std@0.51.0/http/server.ts";
export?{
??Status,
??STATUS_TEXT,
} from?"https://deno.land/std@0.51.0/http/http_status.ts";
export?{
??Cookies,
??Cookie,
??setCookie,
??getCookies,
??delCookie,
} from?"https://deno.land/std@0.51.0/http/cookie.ts";
export?{
??basename,
??extname,
??join,
??isAbsolute,
??normalize,
??parse,
??resolve,
??sep,
} from?"https://deno.land/std@0.51.0/path/mod.ts";
export?{ assert } from?"https://deno.land/std@0.51.0/testing/asserts.ts";
// 3rd party dependencies
export?{
??contentType,
??lookup,
} from?"https://deno.land/x/media_types@v2.3.1/mod.ts";我創建了 Oak 服務器，維護了大約一年半，期間經歷了 Deno 和 Deno std 庫的大約 40 個發行版；其中我還將 從內部移動到了 Oak，移出 std 庫，讓它從 std 庫中“彈出”來獨立存在。但我從來沒有想過“嘿，我需要一個包管理器來幫忙”。 的好處之一是，你可以全面驗證代碼與其他代碼的兼容性。如果你的依賴項是為 Deno 編寫的“原始”，那就最好不過了，但是，假設你希望一邊利用 對 的預處理，另一邊還想安全地使用該遠程代碼。Deno 支持幾種不同的方法來實現這一點，但最無縫的是對 X--Types 標頭的支持。此標頭向 Deno 指示類型文件所在的位置，可在類型檢查你所依賴的 文件時使用。Pika CDN 支持此功能。CDN 上任何具有與之相關聯的類型的軟件包都將充當該標頭，而 Deno 也將獲取這些類型，并在檢查文件類型時使用它。
綜上所述，你仍然可能需要將遠程（或本地）依賴項“重新映射”到代碼中表達的內容上。在這種情況下，可以使用 import-maps 的一個不穩定實現。這是一個 W3C 提案規范。它允許提供一個映射，該映射會將代碼中的特定依賴項映射到另一個源，可以是本地文件抑或遠程模塊。
我們曾在 Deno 中實現了它很長一段時間，因為我們真的希望它會被廣泛采用。遺憾的是，這只是 Chrome 的一項實驗，尚未得到更廣泛的采用。于是我們決定在 Deno 1.0 中將它放在 -- 標志后面。我個人認為它還是很有可能走向死胡同，應該避免使用它。
但是，但是，但是...
我想還是會有很多人對 Deno 的模型提出異議。我認為 Deno 嘗試采取的策略（我非常贊同）是在出現實際問題時再做處理。我聽到的很多反對意見來自剛入門 Deno 的新手，他們從未與 Deno 項目合作過，也沒有試圖理解不同的可能性。
話雖如此，如果我們都遇到了同一個問題，并且迫切需要在 Deno CLI 中進行某些更改，我相信 Deno 會去做的。但是很多所謂的問題根本就不存在，或者還有其他解決方法，用不著你的運行時操心那么多事情，或與外部程序耦合來管理代碼。
因此，我希望大家嘗試一下不用包管理器或中心化的包存儲庫，看看這樣下來會有怎樣的結果。你可能再也不會回頭了！
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
