精讀《Deno v1.8 發佈說明》

精讀《Deno v1.8 發佈說明》

• 原文地址：Deno 1.8 Release Notes
• 原文做者：Bartek Iwańczuk, Luca Casonato, Ryan Dahl
• 譯者：@hylerrix
• 原文發佈時間/翻譯時間：20210302/20210305
• 本文屬於《Deno 鑽研之術》系列，原文翻譯內容會同步更新到 Deno 中文網 上（TL;DR。若是以爲本文精讀筆記太長，能夠在這裏只讀原文翻譯 deno-cn.vercel.app/posts）。

今天咱們發佈了 Deno v1.8.0。此版本涵蓋了大量的新功能和標準化工做：

• 實驗性支持 WebGPU API：在 Deno 中爲開箱即用的 GPU 加速機器學習鋪平道路。
• 啓用內置的國際化 API：支持全部 JS 標準下的 Intl API 開箱即用。
• 翻新測試覆蓋工具：測試覆蓋功能支持輸出 lcov 報告。
• 落地 Import Maps 標準：Web 兼容的依賴重寫現已發佈。
• 支持獲取私有模塊：可使用受權的 token 令牌從私有的服務端獲取遠程模塊。

若是你已經安裝了 Deno，能夠經過 deno upgrade 命令來更新到 1.8 版本。若是你是第一次體驗 Deno，你能夠嘗試使用以下命令之一：

# 使用 Shell (macOS and Linux)
$ curl -fsSL https://deno.land/x/install/install.sh | sh
# 使用 PowerShell (Windows):
$ iwr https://deno.land/x/install/install.ps1 -useb | iex
# 使用 Homebrew (macOS):
$ brew install deno
# 使用 Scoop (Windows):
$ scoop install deno
# 使用 Chocolatey (Windows):
$ choco install deno
複製代碼

精讀筆記

• cURL：提供一個 libcurl 庫和一個 curl 命令，支持經過多種網絡協議傳輸各類類型的數據。起始於 1996 年，做者最初的想法是自動爲 IRC （因特網中繼聊天）用戶獲取因特網上能夠查到的貨幣匯率。2020 時新的網站每個月服務流量超過 10TB。
• PowerShell：微軟開發的任務自動化和配置管理框架。最初僅是 Windows 組件（基於 .NET Framew），後於 2016 年開源並提供跨平臺支持（基於 .NET Core）。由命令行 Shell 和相關的腳本語言構成。
• Homebrew：MacOS（或 Linux）下缺失的包管理器，基於 Ruby 和 Git，免費且開源。孵化出的 Homebrew Cask 能夠用來管理和分發二進制應用程序。
• Scoop：Windows 下的命令行安裝器。相比 PowerShell 能以最小的安裝量安裝程序，更貼近 Unix 風格。無須管理員權限便可安裝應用到本身的主目錄。
• Chocolatey：Windows 下的軟件管理工具。誕生於 2011 年，起初的設想是爲 Windows 提供一個統一的包管理器。基於現代自動化和 DevOps 方法構建。
• 推薦：使用 cURL 下載 Deno 的最新版本，將來使用 deno upgrade 自更新便可。

實驗性支持 WebGPU API

WebGPU API 給開發者提供一個底層、高性能和跨平臺的方式來經過 JavaScript 在 GPU 硬件上編碼。這個 API 是 WebGL 在網絡上的有力繼承者。相關規範雖未正式肯定，但目前 Firefox、Chromium 和 Safari 已逐步開始支持，Deno 也同樣在跟進。

該 API 可讓開發者從 Deno 內部進行 GPU 渲染和通用 GPU 計算。一旦該 API 標準化結束並在 Deno 中被取消 unstable 標記，這將正式爲開發者提供一種從 Web、服務器和開發機器上訪問 GPU 資源的便捷方法。

GPU 能夠容許開發者使某些數值算法高度並行。這在渲染圖形和遊戲外也頗有用。在機器學習中高效使用 GPU 開啓了複雜的神經網絡體系——常被稱爲「深度學習」。計算機視覺、翻譯、圖像生成和強化學習等領域的飛速發展都源於有效利用了 GPU 硬件。

現在，大多數神經網絡都是在 Python 中定義的，而計算交由 GPU 負責。咱們相信若是存在適當基礎架構的狀況下， JavaScript（而不是 Python），也能夠成爲表達數學思想的理想語言。在 Deno 中提供開箱即用的 WebGPU 支持是朝向這個方向的一步。咱們的目標是經過支持 GPU 加速，以在 Deno 上運行 Tensorflow.js。咱們指望這將在將來幾周或幾個月內落實。

這是一個演示如何訪問鏈接的 GPU 設備並讀取名稱和其所支持的功能的基本示例：

// 執行 `deno run --unstable https://deno.land/posts/v1.8/webgpu_discover.ts`

// 嘗試從用戶代理來獲取一個 adapter 適配器
const adapter = await navigator.gpu.requestAdapter();
if (adapter) {
  // 打印出這個適配器的一些基本詳情
  console.log(`Found adapter: ${adapter.name}`);
  const features = [...adapter.features.values()];
  console.log(`Supported features: ${features.join(", ")}`);
} else {
  console.error("No adapter found");
}
複製代碼

這是一個小示例，演示 GPU 如何使用渲染着色器在綠色背景上渲染一個簡單的紅色三角形：

$ deno run --unstable --allow-write=output.png https://raw.githubusercontent.com/crowlKats/webgpu-examples/f3b979f57fd471b11a28c5b0c91d0447221ba77b/hello-triangle/mod.ts
複製代碼

注意這裏使用 WebAssembly 來編寫的 PNG。更多示例能夠查看：github.com/crowlKats/w…

最終的 PR 足足佔用了 15.5 萬行代碼，而且在跟進後花了整整 5個月的時間來合併。這很是感謝 crowlKats 領導了將 WebGPU 集成到 Deno 的工做。咱們也很是感謝爲 Deno 中的 WebGPU 支持奠基基礎的 wgpu 和 gfx-rs 項目的全部貢獻者。也特別感謝 WebGPU 規範的編輯 kvark 以及 webgpu 和 gfx-rs 的首席開發者們，他們均爲實現 WebGPU API 提供了出色的指導。

精讀筆記：

• GPU：圖形處理器。相比於傳統 CPU，是專門運行繪圖運算工做的微處理器，也專爲通用計算設計。GPU 的並行架構可並行運行大量計算，在 3D 渲染、運行分析、深度學習和機器學習算法時都頗有用。
• OpenGL：開放圖形庫。用於渲染 2D、3D 矢量圖形的跨語言、跨平臺的 API，經常使用於 CAD、虛擬現實、科學可視化程序和電子遊戲開發。儘管這些 API 徹底能夠經過軟件實現，但它是爲大部分或所有使用硬件加速而設計。與語言和平臺均無關，純粹專一於渲染。
• DirectX：由微軟公司建立的一系列專爲多媒體以及遊戲開發的 API。其中的 Direct3D 與 OpenGL 同爲電腦繪圖軟件和電腦遊戲最常使用的兩套繪圖編程介面之一。
• WebGL：OpenGL 的 JavaScript 綁定。用於在不使用插件的狀況下載任何兼容的網頁瀏覽器中呈現交互式 2D 和 3D 圖形。WebGL 可將影像處理和 GPU 加速使用方式當作網頁 Canvas 的一部分。WebGL 基於 OpenGL ES，使用 HTML5 Canvas 並容許利用文檔對象模型接口。可利用部分 JavaScript 實現自動存儲器管理等。
• WebGPU：公開了用於在 GPU 上加速圖形和計算的將來 Web 標準和 JavaScript API，旨在提供「現代 3D 圖形和計算功能」。與 WebGL 不一樣的是，WebGPU 不是任何現有的 native API 的直接端口，能夠從某種角度上看做是下一代 WebGL。
• 硬件加速：是指在計算機中把計算量很是大工做分配給專門的硬件來處理以減輕 CPU 的工做量之技術。
• 機器學習：人工智能的一個分支。理論主要是設計和分析一些讓計算機能夠自動「學習」的算法——從數據中自動分析得到規律，並利用規律對位置數據進行預測的算法。
• 深度學習：是機器學習的分支之一，一種以神經網絡爲架構，對資料進行表徵學習的算法。
• 神經網絡：在機器學習和認知科學領域，是一種模仿生物神經網絡的結構和功能的數學模型或計算模型，用於對函數進行估計或近似。神經網絡由大量的人工神經元聯結進行計算。大多數狀況下人工神經網絡能在外界信息的基礎上改變內部結構，是一種自適應系統。普遍用於機器視覺和語音識別等領域。
• Tensorflow.js：使用 JavaScript 訓練和部署機器學習模型，並直接在瀏覽器或 Node.js 中使用機器學習模型。Deno 將來將也支持。
• wgpu：基於 gfx-hal 的原生 WebGPU 實現，由 Rust 語言編寫。
• gfx-rs：開源組織，專一於 Rust 中的可移植圖形和計算。
• three.js：JavaScript 3D 庫。目的是使用默認的 WebGL 渲染器建立易於使用、輕巧的 3D 庫，同時提供 Canvas 2D、SVG 和 CSS 3D 等渲染器。將來也會計劃支持 WebGPU 渲染。

支持 ICU

支持 ICU 已成爲 Deno 下第二受關注的功特性。咱們很高興地宣佈 Deno v.1.8 現已隨附了完整的 ICU 支持。

全部基於 ICU 的 JavaScript API 如今均可以與瀏覽器 API 相兼容。

在 REPL 中能夠進行以下嘗試：

$ deno
Deno 1.8.0
exit using ctrl+d or close()
> const d = new Date(Date.UTC(2020, 5, 26, 7, 0, 0));
undefined
> d.toLocaleString("de-DE", {
    weekday: "long",
    year: "numeric",
    month: "long",
    day: "numeric",
});
"Freitag, 26. Juni 2020"
複製代碼

精讀筆記：

• ICU：Unicode 國際組件。用於 Unicode 支持、軟件國際化和軟件全球化，可普遍移植到許多操做系統和環境中，在全部平臺上以及 C、C++、Java 之間爲應用程序提供相同的結果。
• ICU 提供：Unicode 文本處理、完整字符屬性和字符集轉換、Unicode 正則表達式、完整的 Unicode 集、字符/單詞和行邊界、語言敏感的整理和搜索、經過通用語言環境數據庫庫（CLDR）的全面的語言環境數據和資源包體系結構、多日曆和時區，以及基於規則的日期/時間/數字/貨幣/好消息的格式設置和解析。
• Unicode：整理、編碼了世界上大部分的文字系統，使得電腦能夠用更爲簡單的方式來呈現和處理文字。基於 Unicode 的全球化軟件可最大程度地擴大市場範圍並下降成本。全球化軟件能夠一次構建和安裝，但能夠處理來自世界各地的用戶和來自世界各地的用戶的文本，並適應他們的文化習俗。經過消除每種語言的構建，安裝和維護更新，將成本降到最低。
• 基於 Unicode 的常見字符集：UTF-八、UTF-1六、UTF-32 等。JavaScript 使用的是已被 Unicode 兼容掉的舊 UCS-2 字符集（由於那時還沒出 UTF-16 ），ES6 增強了對 Unicode 的支持。根據標準，JSON 數據必須是 UTF-8 編碼。Emoji 表情是四個字節。
• 中文字符集的發展歷程：GB2312 -> GBK -> GB18030 / DBCS。

改進覆蓋率工具鏈：deno coverage

此版本經過擴大咱們測試覆蓋範圍的基礎架構，增長了一些強大的新功能。主要的變化是測試覆蓋率如今分爲覆蓋率集合和覆蓋率報告兩個部分。

此前，覆蓋範圍的收集和報告都在單個子命令中進行，只須要在執行 deno test 時指定 --coverage 標誌便可。如今，用於 deno test 的 --coverage 標誌將接收一個參數——用來存儲收集的配置文件的目錄路徑。這就是覆蓋率集合。接下來第二步能夠調用 deno coverage 並制定存儲覆蓋率配置文件的目錄路徑。該子命令能夠再控制檯上輸出格式化友好的文本報告，也能夠輸出 lcov 文件（--lcov 標誌）以供 genhtml、coveralls.io 或 codecov.io 之類的工具使用。

幾天來，咱們一直在 deno_std 上對該功能進行測試。咱們將每次提交的覆蓋率報告同步上傳到 codecov.io 上。你能夠在這裏查看相關內容：codecov.io/gh/denoland… Github Actions 工做流上僅進行了以下 10 行的更改：

- name: Run tests
-    run: deno test --unstable --allow-all
+    run: deno test --coverage=./cov --unstable --allow-all
+
+  - name: Generate lcov
+    run: deno coverage --unstable --lcov ./cov > cov.lcov
+
+  - name: Upload coverage
+    uses: codecov/codecov-action@v1
+    with:
+      name: ${{ matrix.os }}-${{ matrix.deno }}
+      files: cov.lcov
複製代碼

有關與 coverals.io 集成的相關示例，能夠參考這個倉庫：github.com/lucacasonat…

精讀筆記：

• LCOV：GCC 覆蓋率測試工具 gcov 的圖形化前端，收集多個源文件的 gcov 數據，並建立 HTML 頁面，其中包含帶有覆蓋率信息註釋的源代碼。LCOV 支持語句、功能和分支覆蓋率的度量。
• GCOV：是源代碼覆蓋率分析工具，能夠跟蹤每一個語句的精確執行次數等。
• genhtml：lcov 命令的附帶工具，能夠將 lcov 格式的文件生成 HTML 頁面來瀏覽。
• coveralls.io：經過顯示測試中未覆蓋的代碼部分來幫助分析測試覆蓋率，同時提供開源項目的測試覆蓋狀況的 badge 圖標。
• codecov.io：輔助生成代碼覆蓋的線上網站之一，能夠配合 Github Action 將 lcov 文件上傳並在線查看覆蓋率狀況等。

Import maps 現已穩定

標準化的 Import maps 已在 Chrome 89 中支持 ，隨後咱們也進項了相應的更新以匹配該規範的最新版本，如今也被認爲很穩定。這意味着接下來使用 --import-map 時再也不須要 --unstable 標誌。

$ deno run --import-map=./import_map.json ./mod.ts
複製代碼

此外，--import-map 標誌如今不只接受本地路徑，並且接受 URL 路徑，從而可使開發者從遠程服務器加載 import maps。

$ deno run --import-map=https://example.com/import_map.json ./mod.ts
複製代碼

Import maps 容許用戶使用所謂的「裸」說明符來表示依賴關係，而不是相對或絕對文件地址/HTTP URL：

// Deno 默認狀況下不支持此類說明符
// 但經過 import maps 用戶能夠將裸說明符從新映射到指定的 URL
import * as http from "std/http";
複製代碼

{  "imports": {    "std/http": "https://deno.land/std@0.85.0/http/mod.ts"  }}
複製代碼

用戶應該記住，import maps 不可組合的：這意味着你只能爲 deno run / deno test 提供單個的 import maps。所以，庫做者仍應使用常規非「裸」的說明符（相對或絕對的文件路徑 / http URLs）；不然庫用戶將須要手動將你的庫（和你的庫依賴項）額裸說明符添加到用戶本身的 import maps 中。

Import maps 一個更有用的功能是可以將常規說明符從新映射爲一個徹底不一樣的說明符。例如，若是你的模塊圖中深嵌套了一些破碎（broken）的依賴關係，你能夠在將其上游修復前將其自主修復到指定版本。或者若是你使用將哈希值注入到模塊文件名的構建過程，則能夠直接在源碼中引入該文件（無需 hash 值）並僅在運行時使用 import maps 從新映射說明符。

有關更多的示例和詳細說明，請參考 import maps 規範。

精讀筆記 - import maps：

• 該提案容許控制 JavaScript import 語句和 import() 表達式獲取如何 URL。
• 同時容許「裸的導入說明符」起做用（如 import moment from "moment"）。
• import maps 則能夠說明模塊路徑如何解析。
• 提供 <script type="importmap"> 和 <link rel="modulepreload" href="import:lodash"> 支持。
• 相似於 Service Workers，import maps 是應用級產物，不該該被手動組合，應該由控制整個 app 視角的人或工具生成。庫裏包含 import map 沒有意義，應讓整個應用決定如何映射 URL。
• ...以及更多 github.com/WICG/import…

支持 token 權限令牌來獲取模塊

不是全部的代碼都是在互聯網上公開的。此前 Deno 沒法從須要身份驗證的服務器上下載代碼。在這次版本中咱們增長了用戶首次獲取模塊時可使用身份驗證令牌的功能。

爲了達到這個目的，Deno CLI 將嘗試查找一個名爲 DENO_AUTH_TOKENS 的環境變量，以肯定在請求遠程模塊時英考慮使用的身份驗證令牌。環境變量的值採用以分號（;）分隔的 n 個令牌的格式，其中每一個令牌的格式爲 {token}@{hostname[:port]}。

例如，單個 token 令牌看起來像這樣：

DENO_AUTH_TOKENS=a1b2c3d4e5f6@deno.land
複製代碼

多個 token 令牌可能像這樣：

DENO_AUTH_TOKENS=a1b2c3d4e5f6@deno.land;f1e2d3c4b5a6@example.com:8080
複製代碼

當 Deno 將要獲取一個遠程模塊時，若是遠程模塊的 hostname 主機名匹配到了環境變量中的 hostname 主機名：Deno 將會在請求頭中設置一個 Authorization header 字段，其值格式爲 Bearer { token }。這將支持遠程服務器識別出該請求頭是已通過身份驗證的用戶的受權請求，並在服務器上提供適當資源和模塊的訪問。

有關從私有 Github 存儲庫中提取信息的更詳細的使用指南和配置環境說明，能夠參考相關的手冊條目。

精讀筆記：

• Authorization Header：包含用於在服務器以 401 未經受權狀態和 WWW-Authenticate 標頭響應後（一般但不是必須）向服務器認證用戶代理的屏蔽。一般是 Basic 類型（Base 64 編碼，但並不意味着加密，以明文形式發送且編碼可逆，最好將 HTTPS 與 Basic 身份驗證結合使用）。
• Bearer：RFC 6750，此類 token 來獲取 OAuth 2.0 相關的權限資源。除此以外還有 Basic、Digest（只有 md5 哈希在 Firefox 中支持）、HOBA（基於原點的身份驗證，基於數字簽名）、Mutual、AWS4-HMAC-SHA256。

Deno.test 支持 Exit 清理器

Deno.test API 已經有兩個清理器能夠幫助開發者確保代碼不會「泄露」操做或資源——即在測試用例結束以前，全部打開的文件/網絡句柄都已關閉，而且沒有其餘掛起的系統調用。

Deno 1.8 添加了一個新的清理器能夠確保通過測試的代碼不會調用 Deno.exit()。異常 exit 語句可能會提供假正的測試結果，而且常常被濫用或忘記刪除。

默認狀況下，全部測試都會啓用這個清理器，但能夠再測試定義中將 sanitizeExit 布爾值設置爲 false 來禁用此功能。

Deno.test({  name: "false success",  fn() {    Deno.exit(0);  },  sanitizeExit: false,});// 此條測試語句永不會執行Deno.test({  name: "failing test",  fn() {    throw new Error("this test fails");  },});
複製代碼

你能夠本身運行此腳本： deno test https://deno.land/posts/v1.8/exit_sanitizer.ts。

Deno.permissions API 現已穩定

Deno 的安全模型基於權限機制。當前，只有在啓動應用程序時才能授予這些權限。這在大多數狀況下都適用。但在某些狀況下，在運行時請求/撤銷權限會帶來更好的用戶體驗。

在 Deno 1.8 中，如今有一個穩定的 API 能夠 query 查詢、request 請求和 revoke 撤銷權限。這些 API 包含在 Deno.premissions 對象中。這是一個如何工做的示例：

function homedir() {  try {    console.log(`Your home dir is: ${Deno.env.get("HOME")}`);  } catch (err) {    console.log(`Failed to get the home directory: ${err}`);  }}// 嘗試獲取 home 目錄（這裏會失敗，由於沒有 env 權限）homedir();const { granted } = await Deno.permissions.request({ name: "env" });if (granted) {  console.log(`You have granted the "env" permission.`);} else {  console.log(`You have not granted the "env" permission.`);}// 嘗試獲取 home 目錄（這裏會在用戶贊成受權後成功）homedir();await Deno.permissions.revoke({ name: "env" });// 嘗試獲取 home 目錄（這裏會失敗，由於用戶取消了受權）homedir();
複製代碼

你能夠本身運行此腳本：deno run https://deno.land/posts/v1.8/permission_api.ts。

精讀筆記：

• Deno.permissions 對象：包含 query、revoke、request 三個方法，PermissionDescriptor 類。
• Deno 的權限類型：--allow-all、--alow-env、--alow-hrtime、--alow-net、--alow-plugin、--alow-read、--alow-run、--alow-write。

Deno.link 和 Deno.symlink API 現已穩定

此版本帶來了與符號連接相關的四個穩定的 API：

• Deno.link
• Deno.linkSync
• Deno.symlink
• Deno.symlinkSync

在穩定以前，須要對這些 API 進行安全檢查，而且須要適當的權限才能使用它們。

Deno.link 和 Deno.linkSync 須要對源路徑和目標路徑都具備讀寫權限。

Deno.symlink 和 Deno.symlinkSync 須要對目標路徑具備寫權限。

精讀筆記：

• Deno.link 和 Deno.linkSync：建立新路徑做爲到舊路徑的硬連接。前者是異步，後者是同步。
• Deno.symlink 和 Deno.symlinkSync：建立新路徑做爲到舊路徑的連接。options.type 參數能夠設置爲 file 或 dir。

更細粒度的 Deno.metrics

隨着 Deno 變得更加穩定，對於開發者來講，使用更簡便的方法來檢測它們的應用程序變得愈來愈重要。這須要從最底層（運行時自己）開始支持。在 Deno 中，JS 的全部特權操做（轉到 Rust 的操做）都是經過 JS 和 Rust 之間的單箇中心接口來實現的。咱們稱經過該接口的請求爲「ops」。例如，調用 Deno.open 將調用特權端的 op_open_async，這將返回打開文件的資源 ID（或返回一個錯誤）。

早在兩年多前的 2018 年 10 月 11 日，咱們添加了一種可讓開發者來查看全部 Rust 和 JS 之間 ops 指標的新方法：Deno.metrics。該 API 如今公開開始、完成的同步/異步操做的數量，以及經過操做接口發送的數據量。以前僅限於全部不一樣操做的組合數據。沒有辦法肯定哪一個 ops 被調用了多少次，一般只有一個整體結果。

與 --unstable 一塊兒運行時，此版本向 Deno.metrics 添加了一個名爲 ops 的新字段。此字段包含每一個操做的信息，這些信息涉及 API 的調用頻率以及經過 API 傳輸的數據量。這容許對運行時進行更精細的檢測。

下面是如何使用的示例：

$ deno --unstableDeno 1.8.0exit using ctrl+d or close()> Deno.metrics().ops["op_open_async"]undefined> await Deno.open("./README.md")File {}> Deno.metrics().ops["op_open_async"]{  opsDispatched: 1,  opsDispatchedSync: 0,  opsDispatchedAsync: 1,  opsDispatchedAsyncUnref: 0,  opsCompleted: 1,  opsCompletedSync: 0,  opsCompletedAsync: 1,  opsCompletedAsyncUnref: 0,  bytesSentControl: 54,  bytesSentData: 0,  bytesReceived: 22}
複製代碼

在即將發佈的將來版本中，Deno.test 中的異步操做清理工具將使用此新信息，以在測試完成以前未完成異步操做時提供更多可操做性的錯誤。咱們已經看到此功能用於檢測應用程序並將數據經過管道傳輸到監視軟件中。

• Deno.open：打開一個文件，並將其解析爲 Deno.File 的實例。若是使用 create 或 createNew 打開，則該文件不須要打開前存在。結束文件操做後，調用者有責任主動關閉文件。
• Deno.metrics：跟蹤 Deno 特權方面的指標，主要用於 Deno 的開發中。ops 是 Deno JavaScript 和 Deno Rust 之間的過渡。

在 deno fmt 中支持 JSON 格式

deno fmt 現已支持格式化爲 .json 和 .jsonc 文件。就像 JS/TS 同樣，格式化工具還能夠在 Markdown 文件中格式化 json 和 jsonc 代碼塊。

精讀筆記：

• JSON：基於 ES3 的子集，一種文本格式，徹底獨立於語言。在大多數語言中，是經過數組、向量、列表或序列來實現的。
• JSONC：JSONC 支持註釋。
• JSON-C：JSON 的一種變體，主要針對 C 開發，JSONC 實現了引用計數對象模型，能夠輕鬆用 C 構造 JSON 對象，輸出 JSON 格式的字符串，並將 JSON 格式的字符串解析回 JSON 對象的 C 表示形式。

在 Deno.emit 中支持 IIFE 包

內置的打包器能夠打包出當即調用函數表達式（IIFE）格式的包。

默認狀況下，輸出格式仍爲 esm，但用戶能夠將 EmitOptions.bundle 選項設置爲 iife 來更改此格式：

const { files } = await Deno.emit("/a.ts", {  bundle: "iife",  sources: {    "/a.ts": `import { b } from "./b.ts";        console.log(b);`,    "/b.ts": `export const b = "b";`,  },});console.log(files["deno:///bundle.js"]);
複製代碼

輸出結果爲：

(function() {    const b = "b";    console.log(b);    return {    };})();
複製代碼

你能夠本身運行此腳本：deno run --unstable https://deno.land/posts/v1.8/emit_iife.ts。

爲不支持 ESM 的較舊瀏覽器建立打包時，這個特性特別有用。

精讀筆記：

• ESM 模塊：標準化後的 JavaScript 模塊預發，逐步被 Node、各大主流瀏覽器支持。能夠更爲方便地提供拆分和懶加載等。
• IIFE 模塊：是一種 JavaScript 函數，在定義後當即運行。能夠是一種設計模式，也成自執行匿名函數，包含兩個主要部分：匿名函數（防止變量污染等）和當即調用的表達式 ()。

deno lsp 現已穩定

在過去的幾個月中，咱們一直在努力替換舊的 VS Code 編輯器集成下的 Deno 擴展。舊的擴展僅適用於 VS Code，且解析出的類型並不老是與 Deno CLI 中對應的類型相匹配。

在 Deno 1.6 的 canary 版本中，咱們發佈了內置的語言服務器 deno lsp。LSP 容許咱們僅經過同一份代碼向支持 LSP 協議的全部編輯器提供編輯器集成功能。內置的語言服務器與 Deno CLI 的其他部分基於相同的架構——所以，它提供的 TypeScript 診斷與 CLI 的其他部分相同。

兩週前，在 Deno 1.7.5 中咱們穩定了 deno lsp 並將官方 VS Code 拓展切換到最新。到目前爲止，咱們已收到了很好的反饋，並將努力解決全部用戶建議的問題。若是你在拓展程序中遇到問題，請在咱們的問題跟蹤器中報告該問題。由於咱們沒法解決咱們並不知道的問題。

除了官方的 VS Code 集成外，還建立了不少基於 deno lsp 構建的社區集成。

• Vim 與 CoC：github.com/fannheyward…
• Neovim：github.com/neovim/nvim…
• Emacs：emacs-lsp.github.io/lsp-mode/pa…
• Kakoune: deno.land/manual/gett…
• Sublime：deno.land/manual/gett…

精讀筆記：

• Deno canary （金絲雀）版本：提供更爲頻繁的分支變更，能夠支持預測試將來版本的功能。能夠從 dl.deno.land/ 中下載。
• LSP 協議：語言服務器協議。定義了在編輯器或 IDE與語言服務器之間使用的協議，該語言服務器提供諸如自動完成、轉到定義、查找全部引用等語言功能。語言服務器索引格式（LSIF，相似於 「 else if」）是爲了支持開發工具或 Web UI 中的豐富代碼導航，而不須要源代碼的本地副本。逐步被更多語言支持。使用 JSON-RPC 發送消息格式。

TypeScript 4.2

Deno 1.8 同步支持了最新的 TypeScript 穩定版本。

你能夠在 Announcing TypeScript 4.2 文章中獲取更多關於 TypeScript 4.2 的新特性信息。

精讀筆記 - TypeScript 4.2 新特性包括但不止於：

參考：TypeScript 4.2 發佈

• 更智能的類型別名保護。TypeScript 4.2 將經過保留一段時間內最初編寫和構造的內容來跟蹤類型的構造方法，還會跟蹤並區分將別名鍵入其餘別名的實例。
• 元組類型中 rest 元素支持放在任意位置。此前 TypeScript 僅容許 rest 元素位於元組中的最後一個位置，如今 rest 元素能夠再元組中的任何位置出現。惟一的限制是，後面不能存在其它可選元素或 rest 元素。
• 更嚴格地檢查 in 操做符。在 JavaScript 中，在 in 運算符的右側使用非對象類型是一個運行時錯誤。如今，TypeScript 4.2 確保能夠在編碼時捕獲它。
• 支持 abstract 構造簽名。將 abstract 修飾符添加到構造簽名表示能夠在 abstract 構造函數中傳遞。
• 支持 --explainFiles 選項。使用此選項時，TypeScript 編譯器將給出一些很是冗長的輸出，理清文件如何最終訪問到全部相關文件。
• 經過 --strictNullChecks 選項支持 && 和 || 表達式來優化邏輯表達式中的未調用函數檢查。
• 可選屬性和字符串索引簽名之間的規則更加寬鬆。
• 支持快速聲明缺失的函數。

譯者結語

全文譯完，並在每一個章節作了簡單的精讀筆記。本次翻譯是「精讀」系列的第二篇，上一篇是《精讀《Deno 2020 官方回顧及 2021 展望》》。

《Deno 鑽研之術》的精讀系列將重點圍繞官方博客展開，同時每翻譯完一篇文章，也會爭取 PR 合併到目前的 Deno 中文網上。歡迎對 @hylerrix/deno-tutorial 倉庫進行 star 或關注公衆號 (@ningowood) 來及時接收消息，攜手助力 Deno 在 2021 變得更好！

© github.com/hylerrix/de… 2020~2021