Merge pull request microsoft#2031 from jablko/patch-3

Add links to tsconfig reference

Author: Orta Therox

packages/documentation/copy/en/declaration-files/Library Structures.md

@@ -323,4 +323,4 @@ the top-level module object can _never_ be callable.
 
 The most common solution here is to define a `default` export for a callable/constructable object;
 module loaders commonly detect this situation automatically and replace the top-level object with the `default` export.
-Typescript can handle this for you, if you have [`"esModuleInterop": true`](/tsconfig/#esModuleInterop) in tsconfig.json.
+Typescript can handle this for you, if you have [`"esModuleInterop": true`](/tsconfig#esModuleInterop) in tsconfig.json.

packages/documentation/copy/en/declaration-files/Publishing.md

@@ -11,7 +11,7 @@ There are two main ways you can publish your declaration files to npm:
 1. bundling with your npm package
 2. publishing to the [@types organization](https://www.npmjs.com/~types) on npm.
 
-If your types are generated by your source code, publish the types with your source code. Both TypeScript and JavaScript projects can generate types via [`--declaration`](/tsconfig#declaration).
+If your types are generated by your source code, publish the types with your source code. Both TypeScript and JavaScript projects can generate types via [`declaration`](/tsconfig#declaration).
 
 Otherwise, we recommend submitting the types to DefinitelyTyped, which will publish them to the `@types` organization on npm.
 
@@ -31,9 +31,9 @@ For example:
 }
 ```
 
-Note that the `"typings"` field is synonymous with `"types"`, and could be used as well.
+Note that the `"typings"` field is synonymous with `types`, and could be used as well.
 
-Also note that if your main declaration file is named `index.d.ts` and lives at the root of the package (next to `index.js`) you do not need to mark the `"types"` property, though it is advisable to do so.
+Also note that if your main declaration file is named `index.d.ts` and lives at the root of the package (next to `index.js`) you do not need to mark the `types` property, though it is advisable to do so.
 
 ## Dependencies
 

packages/documentation/copy/en/handbook-v1/Basic Types.md

@@ -274,7 +274,7 @@ function warnUser(): void {
 }
 ```
 
-Declaring variables of type `void` is not useful because you can only assign `null` (only if `--strictNullChecks` is not specified, see next section) or `undefined` to them:
+Declaring variables of type `void` is not useful because you can only assign `null` (only if [`strictNullChecks`](/tsconfig#strictNullChecks) is not specified, see next section) or `undefined` to them:
 
 ```ts twoslash
 // @strict: false
@@ -297,13 +297,13 @@ let n: null = null;
 By default `null` and `undefined` are subtypes of all other types.
 That means you can assign `null` and `undefined` to something like `number`.
 
-However, when using the `--strictNullChecks` flag, `null` and `undefined` are only assignable to `unknown`, `any` and their respective types (the one exception being that `undefined` is also assignable to `void`).
+However, when using the [`strictNullChecks`](/tsconfig#strictNullChecks) flag, `null` and `undefined` are only assignable to `unknown`, `any` and their respective types (the one exception being that `undefined` is also assignable to `void`).
 This helps avoid _many_ common errors.
 In cases where you want to pass in either a `string` or `null` or `undefined`, you can use the union type `string | null | undefined`.
 
 Union types are an advanced topic that we'll cover in a later chapter.
 
-> As a note: we encourage the use of `--strictNullChecks` when possible, but for the purposes of this handbook, we will assume it is turned off.
+> As a note: we encourage the use of [`strictNullChecks`](/tsconfig#strictNullChecks) when possible, but for the purposes of this handbook, we will assume it is turned off.
 
 ## Never
 

packages/documentation/copy/en/handbook-v1/Functions.md

@@ -313,7 +313,7 @@ let pickedCard = cardPicker();
 alert("card: " + pickedCard.card + " of " + pickedCard.suit);
 ```
 
-Even better, TypeScript will warn you when you make this mistake if you pass the `--noImplicitThis` flag to the compiler.
+Even better, TypeScript will warn you when you make this mistake if you pass the [`noImplicitThis`](/tsconfig#noImplicitThis) flag to the compiler.
 It will point out that `this` in `this.suits[pickedSuit]` is of type `any`.
 
 ## `this` parameters
@@ -364,7 +364,7 @@ alert("card: " + pickedCard.card + " of " + pickedCard.suit);
 ```
 
 Now TypeScript knows that `createCardPicker` expects to be called on a `Deck` object.
-That means that `this` is of type `Deck` now, not `any`, so `--noImplicitThis` will not cause any errors.
+That means that `this` is of type `Deck` now, not `any`, so [`noImplicitThis`](/tsconfig#noImplicitThis) will not cause any errors.
 
 ### `this` parameters in callbacks
 

packages/documentation/copy/en/handbook-v1/Unions and Intersections.md

@@ -302,7 +302,7 @@ function logger(s: NetworkState) {
 ```
 
 There are two ways to do this.
-The first is to turn on `--strictNullChecks` and specify a return type:
+The first is to turn on [`strictNullChecks`](/tsconfig#strictNullChecks) and specify a return type:
 
 ```ts twoslash
 // @errors: 2366
@@ -332,7 +332,7 @@ function logger(s: NetworkState): string {
 
 Because the `switch` is no longer exhaustive, TypeScript is aware that the function could sometimes return `undefined`.
 If you have an explicit return type `string`, then you will get an error that the return type is actually `string | undefined`.
-However, this method is quite subtle and, besides, [`--strictNullChecks`](/tsconfig#strictNullChecks) does not always work with old code.
+However, this method is quite subtle and, besides, [`strictNullChecks`](/tsconfig#strictNullChecks) does not always work with old code.
 
 The second method uses the `never` type that the compiler uses to check for exhaustiveness:
 

packages/documentation/copy/en/handbook-v2/Basics.md

@@ -280,7 +280,7 @@ Why should converting it over to TypeScript stop you from running it?
 
 So TypeScript doesn't get in your way.
 Of course, over time, you may want to be a bit more defensive against mistakes, and make TypeScript act a bit more strictly.
-In that case, you can use the `--noEmitOnError` compiler option.
+In that case, you can use the [`noEmitOnError`](/tsconfig#noEmitOnError) compiler option.
 Try changing your `hello.ts` file and running `tsc` with that flag:
 
 ```sh
@@ -392,7 +392,7 @@ TypeScript has the ability to rewrite code from newer versions of ECMAScript to
 This process of moving from a newer or "higher" version of ECMAScript down to an older or "lower" one is sometimes called _downleveling_.
 
 By default TypeScript targets ES3, an extremely old version of ECMAScript.
-We could have chosen something a little bit more recent by using the `--target` flag.
+We could have chosen something a little bit more recent by using the [`target`](/tsconfig#target) option.
 Running with `--target es2015` changes TypeScript to target ECMAScript 2015, meaning code should be able to run wherever ECMAScript 2015 is supported.
 So running `tsc --target es2015 hello.ts` gives us the following output:
 
@@ -421,8 +421,8 @@ This can require a little extra work, but generally speaking it pays for itself
 When possible, a new codebase should always turn these strictness checks on.
 
 TypeScript has several type-checking strictness flags that can be turned on or off, and all of our examples will be written with all of them enabled unless otherwise stated.
-The `--strict` flag in the CLI, or `"strict": true` in a [`tsconfig.json`](https://www.typescriptlang.org/docs/handbook/tsconfig-json.html) toggles them all on simultaneously, but we can opt out of them individually.
-The two biggest ones you should know about are `noImplicitAny` and `strictNullChecks`.
+The [`strict`](/tsconfig#strict) flag in the CLI, or `"strict": true` in a [`tsconfig.json`](https://www.typescriptlang.org/docs/handbook/tsconfig-json.html) toggles them all on simultaneously, but we can opt out of them individually.
+The two biggest ones you should know about are [`noImplicitAny`](/tsconfig#noImplicitAny) and [`strictNullChecks`](/tsconfig#strictNullChecks).
 
 ## `noImplicitAny`
 
@@ -431,10 +431,10 @@ This isn't the worst thing that can happen - after all, falling back to `any` is
 
 However, using `any` often defeats the purpose of using TypeScript in the first place.
 The more typed your program is, the more validation and tooling you'll get, meaning you'll run into fewer bugs as you code.
-Turning on the `noImplicitAny` flag will issue an error on any variables whose type is implicitly inferred as `any`.
+Turning on the [`noImplicitAny`](/tsconfig#noImplicitAny) flag will issue an error on any variables whose type is implicitly inferred as `any`.
 
 ## `strictNullChecks`
 
 By default, values like `null` and `undefined` are assignable to any other type.
 This can make writing some code easier, but forgetting to handle `null` and `undefined` is the cause of countless bugs in the world - some consider it a [billion dollar mistake](https://www.youtube.com/watch?v=ybrQvs4x0Ps)!
-The `strictNullChecks` flag makes handling `null` and `undefined` more explicit, and _spares_ us from worrying about whether we _forgot_ to handle `null` and `undefined`.
+The [`strictNullChecks`](/tsconfig#strictNullChecks) flag makes handling `null` and `undefined` more explicit, and _spares_ us from worrying about whether we _forgot_ to handle `null` and `undefined`.

packages/documentation/copy/en/handbook-v2/Classes.md

@@ -69,7 +69,7 @@ pt.x = "0";
 
 #### `--strictPropertyInitialization`
 
-The `strictPropertyInitialization` setting controls whether class fields need to be initialized in the constructor.
+The [`strictPropertyInitialization`](/tsconfig#strictPropertyInitialization) setting controls whether class fields need to be initialized in the constructor.
 
 ```ts twoslash
 // @errors: 2564

packages/documentation/copy/en/handbook-v2/Everyday Types.md

@@ -635,17 +635,17 @@ The `as const` suffix acts like `const` but for the type system, ensuring that a
 
 JavaScript has two primitive values used to signal absent or uninitialized value: `null` and `undefined`.
 
-TypeScript has two corresponding _types_ by the same names. How these types behave depends on whether you have the `strictNullChecks` option on.
+TypeScript has two corresponding _types_ by the same names. How these types behave depends on whether you have the [`strictNullChecks`](/tsconfig#strictNullChecks) option on.
 
 ### `strictNullChecks` off
 
-With `strictNullChecks` _off_, values that might be `null` or `undefined` can still be accessed normally, and the values `null` and `undefined` can be assigned to a property of any type.
+With [`strictNullChecks`](/tsconfig#strictNullChecks) _off_, values that might be `null` or `undefined` can still be accessed normally, and the values `null` and `undefined` can be assigned to a property of any type.
 This is similar to how languages without null checks (e.g. C#, Java) behave.
-The lack of checking for these values tends to be a major source of bugs; we always recommend people turn `strictNullChecks` on if it's practical to do so in their codebase.
+The lack of checking for these values tends to be a major source of bugs; we always recommend people turn [`strictNullChecks`](/tsconfig#strictNullChecks) on if it's practical to do so in their codebase.
 
 ### `strictNullChecks` on
 
-With `strictNullChecks` _on_, when a value is `null` or `undefined`, you will need to test for those values before using methods or properties on that value.
+With [`strictNullChecks`](/tsconfig#strictNullChecks) _on_, when a value is `null` or `undefined`, you will need to test for those values before using methods or properties on that value.
 Just like checking for `undefined` before using an optional property, we can use _narrowing_ to check for values that might be `null`:
 
 ```ts twoslash

packages/documentation/copy/en/handbook-v2/Modules.md

@@ -27,7 +27,7 @@ Conversely, to consume a variable, function, class, interface, etc. exported fro
 Before we start, it's important to understand what TypeScript considers a module.
 The JavaScript specification declares that any JavaScript files without an `export` or top-level `await` should be considered a script and not a module.
 
-Inside a script file variables and types are declared to be in the shared global scope, and it's assumed that you'll either use the [`--outFile`](/tsconfig#outFile) compiler option to join multiple input files into one output file, or use multiple `<script>` tags in your HTML to load these files (in the correct order!).
+Inside a script file variables and types are declared to be in the shared global scope, and it's assumed that you'll either use the [`outFile`](/tsconfig#outFile) compiler option to join multiple input files into one output file, or use multiple `<script>` tags in your HTML to load these files (in the correct order!).
 
 If you have a file that doesn't currently have any `import`s or `export`s, but you want to be treated as a module, add the line:
 
@@ -306,29 +306,29 @@ squareTwo;
 
 ### CommonJS and ES Modules interop
 
-There is a mis-match in features between CommonJS and ES Module because ES Modules only support having the default export as an object, and never as a function. TypeScript has a compiler flag to reduce the friction between the two different sets of constraints with [`esModuleInterop`](/tsconfig/#esModuleInterop).
+There is a mis-match in features between CommonJS and ES Module because ES Modules only support having the default export as an object, and never as a function. TypeScript has a compiler flag to reduce the friction between the two different sets of constraints with [`esModuleInterop`](/tsconfig#esModuleInterop).
 
 ## TypeScript's Module Resolution Options
 
 Module resolution is the process of taking a string from the `import` or `require` statement, and determining what file that string refers to.
 
-TypeScript includes two resolution strategies: Classic and Node. Classic, the default when the compiler flag [`module`](/tsconfig/#module) is not `commonjs`, is included for backwards compatibility.
+TypeScript includes two resolution strategies: Classic and Node. Classic, the default when the compiler option [`module`](/tsconfig#module) is not `commonjs`, is included for backwards compatibility.
 The Node strategy replicates how Node.js works in CommonJS mode, with additional checks for `.ts` and `.d.ts`.
 
-There are many TSConfig flags which influence the module strategy within TypeScript: [`moduleResolution`](/tsconfig/#moduleResolution), [`baseUrl`](/tsconfig/#baseUrl), [`paths`](/tsconfig/#paths), [`rootDirs`](/tsconfig/#rootDirs).
+There are many TSConfig flags which influence the module strategy within TypeScript: [`moduleResolution`](/tsconfig#moduleResolution), [`baseUrl`](/tsconfig#baseUrl), [`paths`](/tsconfig#paths), [`rootDirs`](/tsconfig#rootDirs).
 
 For the full details on how these strategies work, you can consult the [Module Resolution](/docs/handbook/module-resolution.html).
 
 ## TypeScript's Module Output Options
 
 There are two options which affect the emitted JavaScript output:
 
-- [`target`](/tsconfig/#target) which determines which JS features are downleveled (converted to run in older JavaScript runtimes) and which are left intact
-- [`module`](/tsconfig/#module) which determines what code is used for modules to interact with each other
+- [`target`](/tsconfig#target) which determines which JS features are downleveled (converted to run in older JavaScript runtimes) and which are left intact
+- [`module`](/tsconfig#module) which determines what code is used for modules to interact with each other
 
-Which `target` you use is determined by the features available in the JavaScript runtime you expect to run the TypeScript code in. That could be: the oldest web browser you support, the lowest version of Node.js you expect to run on or could come from unique constraints from your runtime - like Electron for example.
+Which [`target`](/tsconfig#target) you use is determined by the features available in the JavaScript runtime you expect to run the TypeScript code in. That could be: the oldest web browser you support, the lowest version of Node.js you expect to run on or could come from unique constraints from your runtime - like Electron for example.
 
-All communication between modules happens via a module loader, the compiler flag [`module`](/tsconfig#module) determines which one is used.
+All communication between modules happens via a module loader, the compiler option [`module`](/tsconfig#module) determines which one is used.
 At runtime the module loader is responsible for locating and executing all dependencies of a module before executing it.
 
 For example, here is a TypeScript file using ES Modules syntax, showcasing a few different options for [`module`](/tsconfig#module):
@@ -378,7 +378,7 @@ export const twoPi = valueOfPi * 2;
 
 > Note that ES2020 is effectively the same as the original `index.ts`.
 
-You can see all of the available options and what their emitted JavaScript code looks like in the [TSConfig Reference for `module`](/tsconfig/#module).
+You can see all of the available options and what their emitted JavaScript code looks like in the [TSConfig Reference for `module`](/tsconfig#module).
 
 ## TypeScript namespaces
 

packages/documentation/copy/en/handbook-v2/More on Functions.md

@@ -751,7 +751,7 @@ const args = [8, 5] as const;
 const angle = Math.atan2(...args);
 ```
 
-Using rest arguments may require turning on [`downlevelIteration`](/tsconfig/#downlevelIteration) when targeting older runtimes.
+Using rest arguments may require turning on [`downlevelIteration`](/tsconfig#downlevelIteration) when targeting older runtimes.
 
 <!-- TODO link to downlevel iteration -->