Anders Hejlsberg: Introducing TypeScript
https://channel9.msdn.com/posts/Anders-Hejlsberg-Introducing-TypeScript
TypeScript 是 JavaScript 的超集，TypeScript結合了類型檢查和靜態分析，顯式接口。TypeScript是微軟的開源項目，它是由C#之父Anders Hejlsberg發起的。
為什么會有 TypeScript?
JavaScript 只是一個腳本語言，并非真正設計用于開發大型 Web 應用，JavaScript 沒有提供類和模塊等概念，對于一個真正的應用開發，TypeScript 擴展JavaScript 并實現了這些特性。TypeScript 主要特點包括：
- TypeScript 是微軟推出的開源語言，使用 Apache 授權協議
- TypeScript 是 JavaScript 的超集.
- TypeScript 增加了可選類型、類和模塊
- TypeScript 可以編譯成可讀的、標準的 JavaScript
- TypeScript 支持開發大規模 JavaScript 應用，支持所有瀏覽器，主機和操作系統
- TypeScript 設計用于開發大型應用，并保證編譯后的 JavaScript 代碼兼容性
- TypeScript 擴展了 JavaScript 的語法，因此已有的 JavaScript 代碼可直接與 TypeScript 一起運行無需更改
- TypeScript 文件擴展名是 ts，而 TypeScript 編譯器會編譯成 js 文件
- TypeScript 語法與 JScript .NET 相同
- TypeScript 非常易學和易于理解
語言特性
類
接口
模塊
類型注解
編譯時類型檢查
Arrow 函數 (類似 C# 的 Lambda 表達式)
JavaScript 與 TypeScript 的區別
TypeScript 是 JavaScript 的超集，擴展了 JavaScript 的語法，因此現有的 JavaScript 代碼無需做任何修改便可與TypeScript一起使用，TypeScript 通過類型注解提供編譯時的靜態類型檢查。TypeScript 可處理已有的 JavaScript 代碼，并只對其中的 TypeScript 代碼進行編譯。
-
核心TypeScript編譯器
-
語法分析器（Parser）：
以一系列原文件開始, 根據語言的語法, 生成抽象語法樹（AST）
-
聯合器（Binder）：
使用一個
Symbol將針對相同結構的聲明聯合在一起（例如：同一個接口或模塊的不同聲明，或擁有相同名字的函數和模塊）。這能幫助類型系統推導出這些具名的聲明。 -
類型解析器與檢查器（Type resolver / Checker）：
解析每種類型的構造，檢查讀寫語義并生成適當的診斷信息。
-
生成器（Emitter）：
從一系列輸入文件（.ts和.d.ts）生成輸出，它們可以是以下形式之一：JavaScript（.js），聲明（.d.ts），或者是source maps（.js.map）。
-
預處理器（Pre-processor）：
“編譯上下文”指的是某個“程序”里涉及到的所有文件。上下文的創建是通過檢查所有從命令行上傳入編譯器的文件，按順序，然后再加入這些文件直接引用的其它文件或通過
import語句和/// <reference path=... />標簽間接引用的其它文件。
-
沿著引用圖走下來你會發現它是一個有序的源文件列表，它們組成了整個程序。 當解析導出（import）的時候，會優先選擇“.ts”文件而不是“.d.ts”文件，以確保處理的是最新的文件。 編譯器會進行與Nodejs相似的流程來解析導入，沿著目錄鏈查找與將要導入相匹配的帶.ts或.d.ts擴展名的文件。 導入失敗不會報error，因為可能已經聲明了外部模塊。
-
獨立編譯器（tsc）：
批處理編譯命令行界面。主要處理針對不同支持的引擎讀寫文件（比如：Node.js）。
-
語言服務：
“語言服務”在核心編譯器管道上暴露了額外的一層，非常適合類編輯器的應用。
語言服務支持一系列典型的編輯器操作比如語句自動補全，函數簽名提示，代碼格式化和突出高亮，著色等。 基本的重構功能比如重命名，調試接口輔助功能比如驗證斷點，還有TypeScript特有的功能比如支持增量編譯（在命令行上使用--watch）。 語言服務是被設計用來有效的處理在一個長期存在的編譯上下文中文件隨著時間改變的情況；在這樣的情況下，語言服務提供了與其它編譯器接口不同的角度來處理程序和源文件。
請參考 [[Using the Language Service API]] 以了解更多詳細內容。
數據結構
-
Node:
抽象語法樹（AST）的基本組成塊。通常
Node表示語言語法里的非終結符；一些終結符保存在語法樹里比如標識符和字面量。 -
SourceFile:
給定源文件的AST。
SourceFile本身是一個Node；它提供了額外的接口用來訪問文件的源碼，文件里的引用，文件里的標識符列表和文件里的某個位置與它對應的行號與列號的映射。 -
Program:
SourceFile的集合和一系列編譯選項代表一個編譯單元。Program是類型系統和生成代碼的主入口。 -
Symbol:
具名的聲明。
Symbols是做為聯合的結果而創建。Symbols連接了樹里的聲明節點和其它對同一個實體的聲明。Symbols是語義系統的基本構建塊。 -
Type:
Type是語義系統的其它部分。Type可能被命名（比如，類和接口），或匿名（比如，對象類型）。 -
Signature:
一共有三種
Signature類型：調用簽名（call），構造簽名（construct）和索引簽名（index）。
編譯過程概述
整個過程從預處理開始。 預處理器會算出哪些文件參與編譯，它會去查找如下引用（/// <reference path=... />標簽和import語句）。
語法分析器（Parser）生成抽象語法樹（AST）Node. 這些僅為用戶輸出的抽象表現，以樹的形式。 一個SourceFile對象表示一個給定文件的AST并且帶有一些額外的信息如文件名及源文件內容。
然后，聯合器（Binder）處理AST節點，結合并生成Symbols。 一個Symbol會對應到一個命名實體。 這里有個一微妙的差別，幾個聲明節點可能會是名字相同的實體。 也就是說，有時候不同的Node具有相同的Symbol，并且每個Symbol保持跟蹤它的聲明節點。 比如，一個名字相同的class和namespace可以合并，并且擁有相同的Symbol。 聯合器也會處理作用域，以確保每個Symbol都在正確的封閉作用域里創建。
生成SourceFile（還帶有它的Symbols們）是通過調用createSourceFile
API。
到目前為止，Symbol代表的命名實體可以在單個文件里看到，但是有些聲明可以從多文件合并，因此下一步就是構建一個全局的包含所有文件的視圖，也就是創建一個Program。
一個Program是SourceFile的集合并帶有一系列CompilerOptions。 通過調用createProgram
API來創建Program。
通過一個Program實例創建TypeChecker。
TypeChecker是TypeScript類型系統的核心。 它負責計算出不同文件里的Symbols之間的關系，將Type賦值給Symbol，并生成任何語義Diagnostic（比如：error）。
TypeChecker首先要做的是合并不同的SourceFile里的Symbol到一個單獨的視圖，創建單一的Symbol表，合并所有普通的Symbol（比如：不同文件里的namespace）。
在原始狀態初始化完成后，TypeChecker就可以解決關于這個程序的任何問題了。 這些“問題”可以是：
- 這個
Node的Symbol是什么？ - 這個
Symbol的Type是什么？ - 在AST的某個部分里有哪些
Symbol是可見的？ - 某個函數聲明的
Signature都有哪些？ - 針對某個文件應該報哪些錯誤？
TypeChecker計算所有東西都是“懶惰的”；為了回答一個問題它僅“解決”必要的信息。
TypeChecker僅會檢測和這個問題有關的Node，Symbol或Type，不會檢測額外的實體。
對于一個Program同樣會生成一個Emitter。
Emitter負責生成給定SourceFile的輸出；它包括：.js，.jsx，.d.ts和.js.map。
術語
完整開始/令牌開始（Full Start/Token Start）
令牌本身就具有我們稱為一個“完整開始”和一個“令牌開始”。“令牌開始”是指更自然的版本，它表示在文件中令牌開始的位置。“完整開始”是指從上一個有意義的令牌之后掃描器開始掃描的起始位置。當關心瑣事時，我們往往更關心完整開始。
| 函數 | 描述 |
|---|---|
ts.Node.getStart |
取得某節點的第一個令牌起始位置。 |
ts.Node.getFullStart |
取得某節點擁有的第一個令牌的完整開始。 |
瑣碎內容（Trivia）
語法的瑣碎內容代表源碼里那些對理解代碼無關緊要的內容，比如空白，注釋甚至一些沖突的標記。
因為瑣碎內容不是語言正常語法的一部分（不包括ECMAScript API規范）并且可能在任意2個令牌中的任意位置出現，它們不會包含在語法樹里。但是，因為它們對于像重構和維護高保真源碼很重要，所以需要的時候還是能夠通過我們的APIs訪問。
因為EndOfFileToken后面可以沒有任何內容（令牌和瑣碎內容），所有瑣碎內容自然地在非瑣碎內容之前，而且存在于那個令牌的“完整開始”和“令牌開始”之間。
雖然這個一個方便的標記法來說明一個注釋“屬于”一個Node。比如，在下面的例子里，可以明顯看出genie函數擁有兩個注釋：
var x = 10; // This is x.
/**
* Postcondition: Grants all three wishes.
*/
function genie([wish1, wish2, wish3]: [Wish, Wish, Wish]) {
while (true) {
}
} // End function
這是盡管事實上，函數聲明的完整開始是在var x = 10;后。
我們依據Roslyn's notion of trivia ownership處理注釋所有權。通常來講，一個令牌擁有同一行上的所有的瑣碎內容直到下一個令牌開始。任何出現在這行之后的注釋都屬于下一個令牌。源文件的第一個令牌擁有所有的初始瑣碎內容，并且最后面的一系列瑣碎內容會添加到end-of-file令牌上。
對于大多數普通用戶，注釋是“有趣的”瑣碎內容。屬于一個節點的注釋內容可以通過下面的函數來獲取：
| 函數 | 描述 |
|---|---|
ts.getLeadingCommentRanges |
提供源文件和一個指定位置，返回指定位置后的第一個換行與令牌之間的注釋的范圍（與ts.Node.getFullStart配合會更有用）。 |
ts.getTrailingCommentRanges |
提供源文件和一個指定位置，返回到指定位置后第一個換行為止的注釋的范圍（與ts.Node.getEnd配合會更有用）。 |
做為例子，假設有下面一部分源代碼：
debugger;/*hello*/
//bye
/*hi*/ function
function關鍵字的完整開始是從/*hello*/注釋，但是getLeadingCommentRanges僅會返回后面2個注釋：
d e b u g g e r ; / * h e l l o * / _ _ _ _ _ [CR] [NL] _ _ _ _ / / b y e [CR] [NL] _ _ / * h i * / _ _ _ _ f u n c t i o n
↑ ↑ ↑ ↑ ↑
完整開始 查找 第一個注釋 第二個注釋 令牌開始
開始注釋
適當地，在debugger語句后調用getTrailingCommentRanges可以提取出/*hello*/注釋。
如果你關心令牌流的更多信息，createScanner也有一個skipTrivia標記，你可以設置成false，然后使用setText/setTextPos來掃描文件里的不同位置。
參考資料
TypeScript入門指南（JavaScript的超集)
https://tutorialzine.com/2016/07/learn-typescript-in-30-minutes
TypeScript Handbook（中文版）：
http://www.runoob.com/manual/gitbook/TypeScript/_book/index.html
http://www.tslang.cn/#download-links
有人說：“TypeScript 讓 JavaScript 又變成了 Java，而我們不需要另一個 Java，所以我們不需要 TypeScript“。這樣說的人一定不知道，TypeScript 的類型系統中有：Intersection TypesUnion Types & Discriminated Unions (aka "Algebraic Data Types.")String Literal TypesPolymorphic this TypesIndex TypesMapped Types...這些吧。特別是 Generic Types 組合上 Mapped Types 描述能力爆表。如果你的代碼超過 1000 行，而且你不打算浪費時間，那么試試 TypeScript。當然前提是你是有經驗的開發人員，如果是編程初學者，建議還是先從 JavaScript 開始。
作者：林建入
鏈接：https://www.zhihu.com/question/21879449/answer/233768634
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
