Binder

Most JavaScript transpilers out there are simpler than TypeScript because they provide little in the way of code analysis. The typical JavaScript transpilers only have the following flow:

SourceCode ~~Scanner~~> Tokens ~~Parser~~> AST ~~Emitter~~> JavaScript

While the above architecture is true as a simplified understanding of TypeScript js generation, a key feature of TypeScript is its Semantic system. In order to assist type checking (performed by the checker), the binder (in binder.ts) is used to connect the various parts of the source code into a coherent type system that can then be used by the checker. The main responsibility of the binder is to create Symbols.

Symbol

Symbols connect declaration nodes in the AST to other declarations contributing to the same entity. Symbols are the basic building blocks of the Semantic system. The symbol constructor is defined in core.ts (and binder actually uses the objectAllocator.getSymbolConstructor to get its hands on it). Here is the symbol constructor:

function Symbol(flags: SymbolFlags, name: string) {
    this.flags = flags;
    this.name = name;
    this.declarations = undefined;
}

SymbolFlags is a flag enum and is really used to identify additional classifications of the symbol (e.g. variable scope flags FunctionScopedVariable or BlockScopedVariable among others)

Usage by Checker

The binder is actually used internally by the type checker which in turn is used by the program. The simplified call stack looks like:

program.getTypeChecker ->
    ts.createTypeChecker (in checker)->
        initializeTypeChecker (in checker) ->
            for each SourceFile `ts.bindSourceFile` (in binder)
            // followed by
            for each SourceFile `ts.mergeSymbolTable` (in checker)

The unit of work for the binder is a SourceFile. The binder.ts is driven by checker.ts.