diff --git a/Architectural-Overview.md b/Architectural-Overview.md
index fdc03ef..3d7eaaa 100644
--- a/Architectural-Overview.md
+++ b/Architectural-Overview.md
@@ -1,150 +1,15 @@
## Layer Overview
-
-
-
-* **Core TypeScript Compiler**
- * **Parser:** Starting from a set of sources, and following the productions of the language grammar, to generate an Abstract Syntax Tree (AST)
-
- * **Binder:** Linking declarations contributing to the same structure using a Symbol (e.g. different declarations of the same interface or module, or a function and a module with the same name). This allows the type system to reason about these named declarations.
-
- * **Type resolver/ Checker:** Resolving types of each construct, checking semantic operations and generate diagnostics as appropriate.
-
- * **Emitter:** Output generated from a set of inputs (.ts and .d.ts) files can be one of: JavaScript (.js), definitions (.d.ts), or source maps (.js.map)
-
- * **Pre-processor:** The "Compilation Context" refers to all files involved in a "program". The context is created by inspecting all files passed in to the compiler on the command line, in order, and then adding any files they may reference directly or indirectly through `import` statements and `/// ` tags.
-The result of walking the reference graph is an ordered list of source files, that constitute the program.
-When resolving imports, preference is given to ".ts" files over ".d.ts" files to ensure the most up-to-date files are processed.
-The compiler does a node-like process to resolve imports by walking up the directory chain to find a source file with a .ts or .d.ts extension matching the requested import.
-Failed import resolution does not result in an error, as an ambient module could be already declared.
-
-* **Standalone compiler (tsc):** The batch compilation CLI. Mainly handle reading and writing files for different supported engines (e.g. Node.js)
-
-* **Language Service:** The "Language Service" exposes an additional layer around the core compiler pipeline that are best suiting editor-like applications.
-The language service supports the common set of a typical editor operations like statement completions, signature help, code formatting and outlining, colorization, etc... Basic re-factoring like rename, Debugging interface helpers like validating breakpoints as well as TypeScript-specific features like support of incremental compilation (--watch equivalent on the command-line). The language service is designed to efficiently handle scenarios with files changing over time within a long-lived compilation context; in that sense, the language service provides a slightly different perspective about working with programs and source files from that of the other compiler interfaces.
-> Please refer to the [[Using the Language Service API]] page for more details.
-
-* **Standalone Server (tsserver):** The `tsserver` wraps the compiler and services layer, and exposes them through a JSON protocol.
-> Please refer to the [[Standalone Server (tsserver)]] for more details.
-
## Data Structures
-* **Node:** The basic building block of the Abstract Syntax Tree (AST). In general node represent non-terminals in the language grammar; some terminals are kept in the tree such as identifiers and literals.
-
-* **SourceFile:** The AST of a given source file. A SourceFile is itself a Node; it provides an additional set of interfaces to access the raw text of the file, references in the file, the list of identifiers in the file, and mapping from a position in the file to a line and character numbers.
-
-* **Program:** A collection of SourceFiles and a set of compilation options that represent a compilation unit. The program is the main entry point to the type system and code generation.
-
-* **Symbol:** A named declaration. Symbols are created as a result of binding. Symbols connect declaration nodes in the tree to other declarations contributing to the same entity. Symbols are the basic building block of the semantic system.
-
-* **Type:** Types are the other part of the semantic system. Types can be named (e.g. classes and interfaces), or anonymous (e.g. object types).
-
-* **Signature:** There are three types of signatures in the language: call, construct and index signatures.
+Moved to [the glossary](https://github.com/microsoft/TypeScript-Compiler-Notes/blob/main/GLOSSARY.md) of the complier-notes repo.
## Overview of the compilation process
-The process starts with preprocessing.
-The preprocessor figures out what files should be included in the compilation by following references (`/// ` tags and `import` statements).
+Moved to the root readme of the [complier-notes repo](https://github.com/microsoft/TypeScript-Compiler-Notes).
-The parser then generates AST `Node`s.
-These are just an abstract representation of the user input in a tree format.
-A `SourceFile` object represents an AST for a given file with some additional information like the file name and source text.
-
-The binder then passes over the AST nodes and generates and binds `Symbol`s.
-One `Symbol` is created for each named entity.
-There is a subtle distinction but several declaration nodes can name the same entity.
-That means that sometimes different `Node`s will have the same `Symbol`, and each `Symbol` keeps track of its declaration `Node`s.
-For example, a `class` and a `namespace` with the same name can *merge* and will have the same `Symbol`.
-The binder also handles scopes and makes sure that each `Symbol` is created in the correct enclosing scope.
-
-Generating a `SourceFile` (along with its `Symbol`s) is done through calling the `createSourceFile` API.
-
-So far, `Symbol`s represent named entities as seen within a single file, but several declarations can merge multiple files, so the next step is to build a global view of all files in the compilation by building a `Program`.
-
-A `Program` is a collection of `SourceFile`s and a set of `CompilerOptions`.
-A `Program` is created by calling the `createProgram` API.
-
-From a `Program` instance a `TypeChecker` can be created.
-`TypeChecker` is the core of the TypeScript type system.
-It is the part responsible for figuring out relationships between `Symbols` from different files, assigning `Type`s to `Symbol`s, and generating any semantic `Diagnostic`s (i.e. errors).
-
-The first thing a `TypeChecker` will do is to consolidate all the `Symbol`s from different `SourceFile`s into a single view, and build a single Symbol Table by "merging" any common `Symbol`s (e.g. `namespace`s spanning multiple files).
-
-After initializing the original state, the `TypeChecker` is ready to answer any questions about the program.
-Such "questions" might be:
-* What is the `Symbol` for this `Node`?
-* What is the `Type` of this `Symbol`?
-* What `Symbol`s are visible in this portion of the AST?
-* What are the available `Signature`s for a function declaration?
-* What errors should be reported for a file?
-
-The `TypeChecker` computes everything lazily; it only "resolves" the necessary information to answer a question.
-The checker will only examine `Node`s/`Symbol`s/`Type`s that contribute to the question at hand and will not attempt to examine additional entities.
-
-An `Emitter` can also be created from a given `Program`.
-The `Emitter` is responsible for generating the desired output for a given `SourceFile`; this includes `.js`, `.jsx`, `.d.ts`, and `.js.map` outputs.
-
## Terminology
-##### **Full Start/Token Start**
+### **Full Start/Token Start**
+### **Trivia**
-Tokens themselves have what we call a "full start" and a "token start". The "token start" is the more natural version, which is the position in the file where the text of a token begins. The "full start" is the point at which the scanner began scanning since the last significant token. When concerned with trivia, we are often more concerned with the full start.
-
-Function | Description
----------|------------
-`ts.Node.getStart` | Gets the position in text where the first token of a node started.
-`ts.Node.getFullStart` | Gets the position of the "full start" of the first token owned by the node.
-
-#### **Trivia**
-
-Syntax trivia represent the parts of the source text that are largely insignificant for normal understanding of the code, such as whitespace, comments, and even conflict markers.
-
-Because trivia are not part of the normal language syntax (barring ECMAScript ASI rules) and can appear anywhere between any two tokens, they are not included in the syntax tree. Yet, because they are important when implementing a feature like refactoring and to maintain full fidelity with the source text, they are still accessible through our APIs on demand.
-
-Because the `EndOfFileToken` can have nothing following it (neither token nor trivia), all trivia naturally precedes some non-trivia token, and resides between that token's "full start" and the "token start"
-
-It is a convenient notion to state that a comment "belongs" to a `Node` in a more natural manner though. For instance, it might be visually clear that the `genie` function declaration owns the last two comments in the following example:
-
-```TypeScript
-var x = 10; // This is x.
-
-/**
- * Postcondition: Grants all three wishes.
- */
-function genie([wish1, wish2, wish3]: [Wish, Wish, Wish]) {
- while (true) {
- }
-} // End function
-```
-
-This is despite the fact that the function declaration's full start occurs directly after `var x = 10;`.
-
-We follow [Roslyn's notion of trivia ownership](https://github.com/dotnet/roslyn/wiki/Roslyn%20Overview#syntax-trivia) for comment ownership. In general, a token owns any trivia after it on the same line up to the next token. Any comment after that line is associated with the following token. The first token in the source file gets all the initial trivia, and the last sequence of trivia in the file is tacked onto the end-of-file token, which otherwise has zero width.
-
-For most basic uses, comments are the "interesting" trivia. The comments that belong to a Node which can be fetched through the following functions:
-
-Function | Description
----------|------------
-`ts.getLeadingCommentRanges` | Given the source text and position within that text, returns ranges of comments between the first line break following the given position and the token itself (probably most useful with `ts.Node.getFullStart`).
-`ts.getTrailingCommentRanges` | Given the source text and position within that text, returns ranges of comments until the first line break following the given position (probably most useful with `ts.Node.getEnd`).
-
-As an example, imagine this portion of a source file:
-
-```TypeScript
-debugger;/*hello*/
- //bye
- /*hi*/ function
-```
-
-The full start for the `function` keyword begins at the `/*hello*/` comment, but `getLeadingCommentRanges` will only return the last 2 comments:
-
-```
-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
- ↑ ↑ ↑ ↑ ↑
- full start look for first comment second comment token start
- leading comments
- starting here
-```
-
-Appropriately, calling `getTrailingCommentRanges` on the end of the debugger statement will extract the `/*hello*/` comment.
-
-In the event that you are concerned with richer information of the token stream, `createScanner` also has a `skipTrivia` flag which you can set to `false`, and use `setText`/`setTextPos` to scan at different points in a file.
+See [the Scanner](https://github.com/microsoft/TypeScript-Compiler-Notes/blob/main/codebase/src/compiler/scanner.md) in the complier-notes repo.
\ No newline at end of file
diff --git a/Common-Errors.md b/Common-Errors.md
index d4befb8..416ed3e 100644
--- a/Common-Errors.md
+++ b/Common-Errors.md
@@ -1,14 +1 @@
-# Introduction
-
-The list below captures some of the commonly confusing error messages that you may encounter when using the TypeScript language and Compiler
-
-# Commonly Confusing Errors
-## "tsc.exe" exited with error code 1.
-
-*Fixes:*
-* check file-encoding is UTF-8 — https://typescript.codeplex.com/workitem/1587
-
-## external module XYZ cannot be resolved
-
-*Fixes:*
-* check if module path is case-sensitive — https://typescript.codeplex.com/workitem/2134
+Deprecated doc
\ No newline at end of file
diff --git a/Compiler-Internals.md b/Compiler-Internals.md
index 47ceade..488b51e 100644
--- a/Compiler-Internals.md
+++ b/Compiler-Internals.md
@@ -1,68 +1 @@
-This page details the compiler implementation and its philosophy.
-Because it focuses on implementation, it's necessarily out-of-date and incomplete.
-
-Before reading this page, be sure to read the [[Architectural Overview]] first.
-
-# General Design
-
-## Laziness
-
-To support language services that respond interactively, the compiler is lazy: it does not calculate any information until it is required.
-This allows it to respond quickly when the language service requests the type of a variable or its members.
-Unfortunately, laziness also makes the compiler code more complicated.
-
-As an overview, after parsing is complete, the binder does nothing but identify symbols.
-The checker then waits until a particular symbol is requested to calculate type information, etc.
-
-## Immutability
-
-Each phase of the compiler (parser, binder, etc -- see below for details) treats data structures from the previous phases as immutable.
-In addition, data structures created within each phase are not usually modified after their creation.
-This requires a look-aside table in some cases.
-For example, because the binder only looks at one file at a time, the checker needs a merged-symbols table to track merged declarations.
-It checks whether a symbol has an entry in the merged-symbols table each time before it uses a symbol.
-
-# Parser
-
-The parser is a recursive descent parser.
-It's pretty resilient to small changes, so if you search for function names matching the thing you want to change, you can probably get away with not having to think about the whole parser.
-There aren't any surprises in the general implementation style here.
-
-## Incremental parsing
-
-## ECMAScript parsing contexts
-
-## ECMAScript automatic semicolon insertion
-
-## JSDoc parsing
-
-# Binder
-
-# Checker
-
-The checker is almost 20,000 lines long, and does almost everything that's not syntactic -- it's the second of two semantic passes, after binding, which is the first semantic pass.
-Since the semantics of a entire program can change dramatically with a couple of keystrokes (e.g. renaming a class), a new checker gets created every time the language service requests information.
-Creating a checker is cheap, though, because the compiler as a whole is so lazy.
-You just have to create some basic types and get the binder to build the global symbol table.
-
-## Grammatical checking
-
-## Overload resolution
-
-## Type argument inference
-
-### Type argument fixing
-
-# Transformer
-
-The transformer is nearing completion to replace the emitter.
-The change in name is because the *emitter* translated TypeScript to JavaScript.
-The *transformer* transforms TypeScript or JavaScript (various versions) to JavaScript (various versions) using various module systems.
-The input and output are basically both trees from the same AST type, just using different features.
-There is still a small printer that writes any AST back to text.
-
-## Rewriting & synthesized nodes
-
-## Sourcemap generation
-
-# Language service
+> ### This page has moved to https://github.com/microsoft/TypeScript-Compiler-Notes/
\ No newline at end of file
diff --git a/Contributing-to-TypeScript.md b/Contributing-to-TypeScript.md
index b3efe4f..8e29f4f 100644
--- a/Contributing-to-TypeScript.md
+++ b/Contributing-to-TypeScript.md
@@ -8,6 +8,8 @@ To log a bug, just use the GitHub issue tracker. Confirmed bugs will be labelled
Before we can accept a pull request from you, you'll need to sign the Contributor License Agreement (CLA). See the "Legal" section of the [CONTRIBUTING.md guide](https://github.com/Microsoft/TypeScript/blob/main/CONTRIBUTING.md). That document also outlines the technical nuts and bolts of submitting a pull request. Be sure to follow our [[Coding Guidelines|coding-guidelines]].
+You can learn more about the compiler's codebase at https://github.com/microsoft/TypeScript-Compiler-Notes/
+
### Suggestions
We're also interested in your feedback in future of TypeScript. You can submit a suggestion or feature request through the issue tracker. To make this process more effective, we're asking that these include more information to help define them more clearly. Start by reading the [[TypeScript Design Goals]] and refer to [[Writing Good Design Proposals]] for information on how to write great feature proposals.
diff --git a/Node-Target-Mapping.md b/Node-Target-Mapping.md
index 3c3be47..93a9ffa 100644
--- a/Node-Target-Mapping.md
+++ b/Node-Target-Mapping.md
@@ -1,7 +1,9 @@
## Recommended Node TSConfig settings
You can let TypeScript compile as little as possible by knowing what the baseline support
-for ECMAScript features are available in your node version.
+for ECMAScript features are available in your node version
+
+You can also use https://github.com/tsconfig/bases/ to find `tsconfig.json`s to extend, simplifying your own JSON files to just the options for your project.
To update this file, you can use [node.green](https://node.green) to map to the different options in [microsoft/typescript@src/lib](https://github.com/Microsoft/TypeScript/tree/main/src/lib)
diff --git a/Tooling-On-The-Compiler-Repo.md b/Tooling-On-The-Compiler-Repo.md
index d0e177f..7740313 100644
--- a/Tooling-On-The-Compiler-Repo.md
+++ b/Tooling-On-The-Compiler-Repo.md
@@ -19,7 +19,7 @@ The bot which adds/removes labels and assignees lives at [microsoft/TypeScript-r
### Repros
-A scheduled task which evaulates code samples generated in [the Bug Workbench](https://www.typescriptlang.org/dev/bug-workbench).
+A scheduled task which evaluates code samples generated in [the Bug Workbench](https://www.typescriptlang.org/dev/bug-workbench).
This automation runs via a [daily GitHub Action](https://github.com/microsoft/TypeScript/blob/master/.github/workflows/twoslash-repros.yaml) where the majority of the code lives at [`microsoft/TypeScript-Twoslash-Repro-Action`](https://github.com/microsoft/TypeScript-Twoslash-Repro-Action)
diff --git a/Type-Checking-JavaScript-Files.md b/Type-Checking-JavaScript-Files.md
index 1713280..6a53ed1 100644
--- a/Type-Checking-JavaScript-Files.md
+++ b/Type-Checking-JavaScript-Files.md
@@ -1,317 +1 @@
-TypeScript 2.3 and later support type-checking and reporting errors in `.js` files with `--checkJs`.
-
-You can skip checking some files by adding `// @ts-nocheck` comment to them; conversely, you can choose to check only a few `.js` files by adding a `// @ts-check` comment to them without setting `--checkJs`.
-
-You can also ignore errors on specific lines by adding `// @ts-ignore` on the preceding line.
-Note that if you have a `tsconfig.json`, JS checking will respect strict flags like `noImplicitAny`, `strictNullChecks`, etc.
-However, because of the relative looseness of JS checking, combining strict flags with it may be surprising.
-
-Here are some notable differences on how checking works in `.js` files compared to `.ts` files:
-
-## JSDoc types are used for type information
-
-In a `.js` file, types can often be inferred just like in `.ts` files.
-Likewise, when types can't be inferred, they can be specified using JSDoc the same way that type annotations are used in a `.ts` file.
-Just like Typescript, `--noImplicitAny` will give you errors on the places that the compiler could not infer a type.
-(With the exception of open-ended object literals; see below for details.)
-
-JSDoc annotations adorning a declaration will be used to set the type of that declaration. For example:
-
-```js
-/** @type {number} */
-var x;
-
-x = 0; // OK
-x = false; // Error: boolean is not assignable to number
-```
-
-You can find the full list of supported JSDoc patterns in the [JSDoc support in JavaScript documentation](https://github.com/Microsoft/TypeScript/wiki/JSDoc-support-in-JavaScript).
-
-
-## Properties are inferred from assignments in class bodies
-
-ES2015 does not have a means for declaring properties on classes. Properties are dynamically assigned, just like object literals.
-
-In a `.js` file, the compiler infers properties from property assignments inside the class body.
-The type of properties is the type given in the constructor, unless it's not defined there, or the type in the constructor is undefined or null.
-In that case, the type is the union of the types of all the right-hand values in these assignments.
-Properties defined in the constructor are always assumed to exist, whereas ones defined just in methods, getters, or setters are considered optional.
-
-```js
-class C {
- constructor() {
- this.constructorOnly = 0
- this.constructorUnknown = undefined
- }
- method() {
- this.constructorOnly = false // error, constructorOnly is a number
- this.constructorUnknown = "plunkbat" // ok, constructorUnknown is string | undefined
- this.methodOnly = 'ok' // ok, but y could also be undefined
- }
- method2() {
- this.methodOnly = true // also, ok, y's type is string | boolean | undefined
- }
-}
-```
-
-
-If properties are never set in the class body, they are considered unknown.
-If your class has properties that are only read from, add and then annotate a declaration in the constructor with JSDoc to specify the type.
-You don't even have to give a value if it will be initialised later:
-
-```js
-class C {
- constructor() {
- /** @type {number | undefined} */
- this.prop = undefined;
- /** @type {number | undefined} */
- this.count;
- }
-}
-
-
-let c = new C();
-c.prop = 0; // OK
-c.count = "string"; // Error: string is not assignable to number|undefined
-```
-
-## Constructor functions are equivalent to classes
-
-Before ES2015, Javascript used constructor functions instead of classes.
-The compiler supports this pattern and understands constructor functions as equivalent to ES2015 classes.
-The property inference rules described above work exactly the same way.
-
-```js
-function C() {
- this.constructorOnly = 0
- this.constructorUnknown = undefined
-}
-C.prototype.method = function() {
- this.constructorOnly = false // error
- this.constructorUnknown = "plunkbat" // OK, the type is string | undefined
-}
-```
-
-## CommonJS modules are supported
-
-In a `.js` file, Typescript understands the CommonJS module format.
-Assignments to `exports` and `module.exports` are recognized as export declarations.
-Similarly, `require` function calls are recognized as module imports. For example:
-
-```js
-// same as `import module "fs"`
-const fs = require("fs");
-
-// same as `export function readFile`
-module.exports.readFile = function(f) {
- return fs.readFileSync(f);
-}
-```
-
-The module support in Javascript is much more syntactically forgiving than Typescript's module support.
-Most combinations of assignments and declarations are supported.
-
-## Classes, functions, and object literals are namespaces
-
-Classes are namespaces in `.js` files.
-This can be used to nest classes, for example:
-
-
-```js
-class C {
-}
-C.D = class {
-}
-```
-
-And, for pre-ES2015 code, it can be used to simulate static methods:
-
-```js
-function Outer() {
- this.y = 2
-}
-Outer.Inner = function() {
- this.yy = 2
-}
-```
-
-It can also be used to create simple namespaces:
-
-```js
-var ns = {}
-ns.C = class {
-}
-ns.func = function() {
-}
-```
-
-Other variants are allowed as well:
-
-```js
-// IIFE
-var ns = (function (n) {
- return n || {};
-})();
-ns.CONST = 1
-
-// defaulting to global
-var assign = assign || function() {
- // code goes here
-}
-assign.extra = 1
-```
-
-## Object literals are open-ended
-
-In a `.ts` file, an object literal that initializes a variable declaration gives its type to the declaration.
-No new members can be added that were not specified in the original literal.
-This rule is relaxed in a `.js` file; object literals have an open-ended type (an index signature) that allows adding and looking up properties that were not defined originally.
-For instance:
-
-```js
-var obj = { a: 1 };
-obj.b = 2; // Allowed
-```
-
-Object literals behave as if they have an index signature `[x:string]: any` that allows them to be treated as open maps instead of closed objects.
-
-Like other special JS checking behaviors, this behavior can be changed by specifying a JSDoc type for the variable. For example:
-
-```js
-/** @type {{a: number}} */
-var obj = { a: 1 };
-obj.b = 2; // Error, type {a: number} does not have property b
-```
-
-## null, undefined, and empty array initializers are of type any or any[]
-
-Any variable, parameter or property that is initialized with null or undefined will have type any, even if strict null checks is turned on.
-Any variable, parameter or property that is initialized with [] will have type any[], even if strict null checks is turned on.
-The only exception is for properties that have multiple initializers as described above.
-
-```js
-function Foo(i = null) {
- if (!i) i = 1;
- var j = undefined;
- j = 2;
- this.l = [];
-}
-var foo = new Foo();
-foo.l.push(foo.i);
-foo.l.push("end");
-```
-
-## Function parameters are optional by default
-
-Since there is no way to specify optionality on parameters in pre-ES2015 Javascript, all function parameters in `.js` file are considered optional.
-Calls with fewer arguments than the declared number of parameters are allowed.
-
-It is important to note that it is an error to call a function with too many arguments.
-
-For instance:
-
-```js
-function bar(a, b) {
- console.log(a + " " + b);
-}
-
-bar(1); // OK, second argument considered optional
-bar(1, 2);
-bar(1, 2, 3); // Error, too many arguments
-```
-
-JSDoc annotated functions are excluded from this rule.
-Use JSDoc optional parameter syntax to express optionality. e.g.:
-
-```js
-/**
- * @param {string} [somebody] - Somebody's name.
- */
-function sayHello(somebody) {
- if (!somebody) {
- somebody = 'John Doe';
- }
- alert('Hello ' + somebody);
-}
-
-sayHello();
-```
-
-## Var-args parameter declaration inferred from use of `arguments`
-
-A function whose body has a reference to the `arguments` reference is implicitly considered to have a var-arg parameter (i.e. `(...arg: any[]) => any`). Use JSDoc var-arg syntax to specify the type of the arguments.
-
-```js
-/** @param {...number} args */
-function sum(/* numbers */) {
- var total = 0
- for (var i = 0; i < arguments.length; i++) {
- total += arguments[i]
- }
- return total
-}
-```
-
-## Unspecified type parameters default to `any`
-
-Since there is no natural syntax for specifying generic type parameters in Javascript, an unspecified type parameter defaults to `any`.
-
-### In extends clause:
-
-For instance, `React.Component` is defined to have two type parameters, `Props` and `State`.
-In a `.js` file, there is no legal way to specify these in the extends clause. By default the type arguments will be `any`:
-
-```js
-import { Component } from "react";
-
-class MyComponent extends Component {
- render() {
- this.props.b; // Allowed, since this.props is of type any
- }
-}
-```
-
-Use JSDoc `@augments` to specify the types explicitly. for instance:
-
-```js
-import { Component } from "react";
-
-/**
- * @augments {Component<{a: number}, State>}
- */
-class MyComponent extends Component {
- render() {
- this.props.b; // Error: b does not exist on {a:number}
- }
-}
-```
-
-### In JSDoc references
-
-An unspecified type argument in JSDoc defaults to any:
-
-```js
-/** @type{Array} */
-var x = [];
-
-x.push(1); // OK
-x.push("string"); // OK, x is of type Array
-
-
-/** @type{Array.} */
-var y = [];
-
-y.push(1); // OK
-y.push("string"); // Error, string is not assignable to number
-
-```
-
-### In function calls
-
-A call to a generic function uses the arguments to infer the type parameters. Sometimes this process fails to infer any types, mainly because of lack of inference sources; in these cases, the type parameters will default to `any`. For example:
-
-```js
-var p = new Promise((resolve, reject) => { reject() });
-
-p; // Promise;
-```
+> ### This page has moved to https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html
\ No newline at end of file
diff --git a/_Sidebar.md b/_Sidebar.md
index 5d6a62c..ca35c14 100644
--- a/_Sidebar.md
+++ b/_Sidebar.md
@@ -17,10 +17,9 @@
* [[Contributing to TypeScript]]
* [[TypeScript Design Goals]]
* [[Coding Guidelines]]
-* [[Spec conformance testing]]
* [[Useful Links for TypeScript Issue Management]]
* [[Writing Good Design Proposals]]
-* [[Compiler Internals]]
+* [Compiler Repo Notes](https://github.com/microsoft/TypeScript-Compiler-Notes/)
* [Deployment](https://github.com/microsoft/TypeScript/wiki/TypeScript-Deployment)
**Building Tools for TypeScript**
@@ -37,3 +36,7 @@
**FAQs**
* [[FAQ]]
* [[FAQs for API Consumers]]
+
+**The Main Repo**
+* [[Triggering TypeScript Bot]]
+* [[Tooling on the Compiler Repo]]