diff --git a/packages/documentation/copy/en/handbook-v2/Basics.md b/packages/documentation/copy/en/handbook-v2/Basics.md
index 79b870e76501..6bc4e0f21566 100644
--- a/packages/documentation/copy/en/handbook-v2/Basics.md
+++ b/packages/documentation/copy/en/handbook-v2/Basics.md
@@ -388,11 +388,11 @@ to
 Why did this happen?
 
 Template strings are a feature from a version of ECMAScript called ECMAScript 2015 (a.k.a. ECMAScript 6, ES2015, ES6, etc. - _don't ask_).
-TypeScript has the ability to rewrite code from newer versions of ECMAScript to older ones such as ECMAScript 3 or ECMAScript 5 (a.k.a. ES5).
+TypeScript has the ability to rewrite code from newer versions of ECMAScript to older supported versions such as ECMAScript 2015.
 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 ES5, an extremely old version of ECMAScript.
-We could have chosen something a little bit more recent by using the [`target`](/tsconfig#target) option.
+By default TypeScript targets the most recent supported ECMAScript version.
+We could have chosen something older 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:
 
@@ -403,15 +403,14 @@ function greet(person, date) {
 greet("Maddison", new Date());
 ```
 
-> While the default target is ES5, the great majority of current browsers support ES2015.
-> Most developers can therefore safely specify ES2015 or above as a target, unless compatibility with certain ancient browsers is important.
+> Modern runtimes support ES2015 and newer.
+> Most developers can therefore safely use a recent target unless compatibility with older browsers is important.
 
 ## Strictness
 
 Different users come to TypeScript looking for different things in a type-checker.
 Some people are looking for a more loose opt-in experience which can help validate only some parts of their program, and still have decent tooling.
-This is the default experience with TypeScript, where types are optional, inference takes the most lenient types, and there's no checking for potentially `null`/`undefined` values.
-Much like how `tsc` emits in the face of errors, these defaults are put in place to stay out of your way.
+You can configure TypeScript for a looser opt-in experience where types are optional, inference takes more lenient types, and there's less checking for potentially `null`/`undefined` values.
 If you're migrating existing JavaScript, that might be a desirable first step.
 
 In contrast, a lot of users prefer to have TypeScript validate as much as it can straight away, and that's why the language provides strictness settings as well.
diff --git a/packages/documentation/copy/en/handbook-v2/Modules.md b/packages/documentation/copy/en/handbook-v2/Modules.md
index d84f9f9e7575..d78b46668851 100644
--- a/packages/documentation/copy/en/handbook-v2/Modules.md
+++ b/packages/documentation/copy/en/handbook-v2/Modules.md
@@ -28,7 +28,7 @@ Before we start, it's important to understand what TypeScript considers a module
 The JavaScript specification declares that any JavaScript files without an `import` declaration, `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 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:
 
@@ -404,4 +404,4 @@ You can see all of the available options and what their emitted JavaScript code
 
 ## TypeScript namespaces
 
-TypeScript has its own module format called `namespaces` which pre-dates the ES Modules standard. This syntax has a lot of useful features for creating complex definition files, and still sees active use [in DefinitelyTyped](https://github.com/DefinitelyTyped/DefinitelyTyped). While not deprecated, the majority of the features in namespaces exist in ES Modules and we recommend you use that to align with JavaScript's direction. You can learn more about namespaces in [the namespaces reference page](/docs/handbook/namespaces.html).
+TypeScript has its own module format called `namespaces` which pre-dates the ES Modules standard. This syntax has a lot of useful features for creating complex definition files, and still sees active use [in DefinitelyTyped](https://github.com/DefinitelyTyped/DefinitelyTyped). While the `namespace` keyword is not deprecated, the legacy `module` keyword for namespaces is deprecated in TypeScript 6.0. The majority of the features in namespaces exist in ES Modules and we recommend you use that to align with JavaScript's direction. You can learn more about namespaces in [the namespaces reference page](/docs/handbook/namespaces.html).
diff --git a/packages/documentation/copy/en/handbook-v2/More on Functions.md b/packages/documentation/copy/en/handbook-v2/More on Functions.md
index 4d40edb5bada..e31efe167190 100644
--- a/packages/documentation/copy/en/handbook-v2/More on Functions.md	
+++ b/packages/documentation/copy/en/handbook-v2/More on Functions.md	
@@ -775,7 +775,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 a recent [`target`](/tsconfig#target) when targeting older runtimes.
 
 <!-- TODO link to downlevel iteration -->
 
diff --git a/packages/documentation/copy/en/handbook-v2/Type Declarations.md b/packages/documentation/copy/en/handbook-v2/Type Declarations.md
index c03614a85f96..3d6d4607c6a6 100644
--- a/packages/documentation/copy/en/handbook-v2/Type Declarations.md	
+++ b/packages/documentation/copy/en/handbook-v2/Type Declarations.md	
@@ -52,8 +52,8 @@ For example, the `startsWith` method of strings is available only starting with
 Being aware of what version of JavaScript your code ultimately runs on is important because you don't want to use APIs that are from a newer version than the platform you deploy to.
 This is one function of the [`target`](/tsconfig#target) compiler setting.
 
-TypeScript helps with this problem by varying which `lib` files are included by default based on your [`target`](/tsconfig#target) setting.
-For example, if [`target`](/tsconfig#target) is `ES5`, you will see an error if trying to use the `startsWith` method, because that method is only available in `ES6` or later.
+TypeScript helps with this problem by varying which `lib` files are included by default based on your [`target`](/tsconfig#target) setting.
+For example, if [`target`](/tsconfig#target) is `ES2015`, you will see an error if trying to use the `replaceAll` method, because that method is only available in `ES2021` or later.
 
 ### `lib` setting
 
@@ -85,7 +85,8 @@ For example, if you installed the `react` npm package, you can install its corre
 npm install --save-dev @types/react
 ```
 
-TypeScript automatically finds type definitions under `node_modules/@types`, so there's no other step needed to get these types available in your program.
+When you import a package in your source code, TypeScript will automatically look for its type definitions, including definitions under `node_modules/@types`.
+If an `@types` package provides globals that you use without importing, such as `process` from `@types/node` or `describe` from `@types/jest`, add the package name to the [`types`](/tsconfig#types) field of your `tsconfig.json`.
 
 ### Your Own Definitions
 
diff --git a/packages/documentation/copy/en/modules-reference/Reference.md b/packages/documentation/copy/en/modules-reference/Reference.md
index 5695c26ea8e2..c8ae4e5fec4c 100644
--- a/packages/documentation/copy/en/modules-reference/Reference.md
+++ b/packages/documentation/copy/en/modules-reference/Reference.md
@@ -368,7 +368,7 @@ export default "default export";
 
 #### Examples
 
-> Output is shown with `esModuleInterop: false`.
+> Output is shown with `esModuleInterop` enabled.
 
 ```ts
 // @Filename: main.ts
@@ -467,7 +467,6 @@ System.register(["mod"], function (exports_1, context_1) {
 - Designed for AMD loaders like RequireJS.
 - You probably shouldn’t use this. Use a bundler instead.
 - Emitted files are AMD modules, but dependencies may be any format.
-- Supports `outFile`.
 
 #### Examples
 
@@ -747,17 +746,16 @@ Multiple file paths can be provided for a path mapping. If resolution fails for
 
 #### `baseUrl`
 
-> `baseUrl` was designed for use with AMD module loaders. If you aren’t using an AMD module loader, you probably shouldn’t use `baseUrl`. Since TypeScript 4.1, `baseUrl` is no longer required to use [`paths`](#paths) and should not be used just to set the directory `paths` values are resolved from.
+> `baseUrl` was designed for use with AMD module loaders. If you aren’t using an AMD module loader, you probably shouldn’t use `baseUrl`. Since TypeScript 4.1, `baseUrl` is no longer required to use [`paths`](#paths), and in TypeScript 6.0 it is deprecated.
 
-The `baseUrl` compiler option can be combined with any `moduleResolution` mode and specifies a directory that bare specifiers (module specifiers that don’t begin with `./`, `../`, or `/`) are resolved from. `baseUrl` has a higher precedence than [`node_modules` package lookups](#node_modules-package-lookups) in `moduleResolution` modes that support them.
-
-When performing a `baseUrl` lookup, resolution proceeds with the same rules as other relative path resolutions. For example, in a `moduleResolution` mode that supports [extensionless relative paths](#extensionless-relative-paths) a module specifier `"some-file"` may resolve to `/src/some-file.ts` if `baseUrl` is set to `/src`.
+For code that used `baseUrl` as a common prefix for [`paths`](#paths), remove `baseUrl` and add that prefix to each `paths` entry.
+For code that used `baseUrl` as a lookup root for arbitrary bare specifiers, use an explicit catch-all `paths` entry instead.
 
 Resolution of relative module specifiers are never affected by the `baseUrl` option.
 
 #### `node_modules` package lookups
 
-Node.js treats module specifiers that aren’t relative paths, absolute paths, or URLs as references to packages that it looks up in `node_modules` subdirectories. Bundlers conveniently adopted this behavior to allow their users to use the same dependency management system, and often even the same dependencies, as they would in Node.js. All of TypeScript’s `moduleResolution` options except `classic` support `node_modules` lookups. (`classic` supports lookups in `node_modules/@types` when other means of resolution fail, but never looks for packages in `node_modules` directly.) Every `node_modules` package lookup has the following structure (beginning after higher precedence bare specifier rules, like `paths`, `baseUrl`, self-name imports, and package.json `"imports"` lookups have been exhausted):
+Node.js treats module specifiers that aren’t relative paths, absolute paths, or URLs as references to packages that it looks up in `node_modules` subdirectories. Bundlers conveniently adopted this behavior to allow their users to use the same dependency management system, and often even the same dependencies, as they would in Node.js. All of TypeScript’s module resolution modes for modern code support `node_modules` lookups. Every `node_modules` package lookup has the following structure (beginning after higher precedence bare specifier rules, like `paths`, self-name imports, and package.json `"imports"` lookups have been exhausted):
 
 1. For each ancestor directory of the importing file, if a `node_modules` directory exists within it:
    1. If a directory with the same name as the package exists within `node_modules`:
@@ -1153,7 +1151,7 @@ import { foo } from "pkg";
 
 Recall that in `--module nodenext --moduleResolution nodenext`, the `--module` setting first [determines](#module-format-detection) whether the import will be emitted to the `.js` file as an `import` or `require` call, then passes that information to TypeScript’s module resolver, which decides whether to match `"import"` or `"require"` conditions in `"pkg"`’s package.json `"exports"` accordingly. Let’s assume that there’s no package.json in scope of this file. The file extension is `.ts`, so the output file extension will be `.js`, which Node.js will interpret as CommonJS, so TypeScript will emit this `import` as a `require` call. So, the module resolver will use the `require` condition as it resolves `"exports"` from `"pkg"`.
 
-The same process happens in `--moduleResolution bundler`, but the rules for deciding whether to emit an `import` or `require` call for this import statement will be different, since `--moduleResolution bundler` necessitates using [`--module esnext`](#es2015-es2020-es2022-esnext) or [`--module preserve`](#preserve). In both of those modes, ESM `import` declarations always emit as ESM `import` declarations, so TypeScript’s module resolver will receive that information and use the `"import"` condition as it resolves `"exports"` from `"pkg"`.
+The same process happens in `--moduleResolution bundler`, but the rules for deciding whether to emit an `import` or `require` call for this import statement will be different. If `--moduleResolution bundler` is paired with [`--module esnext`](#es2015-es2020-es2022-esnext) or [`--module preserve`](#preserve), ESM `import` declarations emit as ESM `import` declarations, so TypeScript’s module resolver will receive that information and use the `"import"` condition as it resolves `"exports"` from `"pkg"`.
 
 This explanation may be somewhat unintuitive, since `--moduleResolution bundler` is usually used in combination with `--noEmit`—bundlers typically process raw `.ts` files and perform module resolution on untransformed `import`s or `require`s. However, for consistency, TypeScript still uses the hypothetical emit decided by `module` to inform module resolution and type checking. This makes [`--module preserve`](#preserve) the best choice whenever a runtime or bundler is operating on raw `.ts` files, since it implies no transformation. Under `--module preserve --moduleResolution bundler`, you can write imports and requires in the same file that will resolve with the `import` and `require` conditions, respectively:
 
@@ -1166,7 +1164,7 @@ import pkg2 = require("pkg"); // Resolved with "require" condition
 
 #### Implied and enforced options
 
-- `--moduleResolution bundler` must be paired with `--module esnext` or `--module preserve`.
+- `--moduleResolution bundler` can be paired with `--module esnext`, `--module preserve`, or `--module commonjs`.
 - `--moduleResolution bundler` implies `--allowSyntheticDefaultImports`.
 
 #### Supported features
@@ -1184,7 +1182,7 @@ import pkg2 = require("pkg"); // Resolved with "require" condition
 
 ### `node10` (formerly known as `node`)
 
-`--moduleResolution node` was renamed to `node10` (keeping `node` as an alias for backward compatibility) in TypeScript 5.0. It reflects the CommonJS module resolution algorithm as it existed in Node.js versions earlier than v12. It should no longer be used.
+`--moduleResolution node` was renamed to `node10` (keeping `node` as an alias for backward compatibility) in TypeScript 5.0. It reflects the CommonJS module resolution algorithm as it existed in Node.js versions earlier than v12. It is deprecated in TypeScript 6.0 and should no longer be used.
 
 #### Supported features
 
diff --git a/packages/documentation/copy/en/modules-reference/Theory.md b/packages/documentation/copy/en/modules-reference/Theory.md
index 5e64354c5bb7..9088456e2e31 100644
--- a/packages/documentation/copy/en/modules-reference/Theory.md
+++ b/packages/documentation/copy/en/modules-reference/Theory.md
@@ -240,11 +240,11 @@ and still claim to implement “standards-compliant ESM.” Needless to say, Typ
 
 The available `moduleResolution` options are:
 
-- [**`classic`**](/docs/handbook/modules/reference.html#classic): TypeScript’s oldest module resolution mode, this is unfortunately the default when `module` is set to anything other than `commonjs`, `node16`, or `nodenext`. It was probably made to provide best-effort resolution for a wide range of [RequireJS](https://requirejs.org/docs/api.html#packages) configurations. It should not be used for new projects (or even old projects that don’t use RequireJS or another AMD module loader), and is scheduled for deprecation in TypeScript 6.0.
-- [**`node10`**](/docs/handbook/modules/reference.html#node10-formerly-known-as-node): Formerly known as `node`, this is the unfortunate default when `module` is set to `commonjs`. It’s a pretty good model of Node.js versions older than v12, and sometimes it’s a passable approximation of how most bundlers do module resolution. It supports looking up packages from `node_modules`, loading directory `index.js` files, and omitting `.js` extensions in relative module specifiers. Because Node.js v12 introduced different module resolution rules for ES modules, though, it’s a very bad model of modern versions of Node.js. It should not be used for new projects.
+- [**`classic`**](/docs/handbook/modules/reference.html#classic): TypeScript’s oldest module resolution mode. It was probably made to provide best-effort resolution for a wide range of [RequireJS](https://requirejs.org/docs/api.html#packages) configurations. It is deprecated in TypeScript 6.0 and should not be used.
+- [**`node10`**](/docs/handbook/modules/reference.html#node10-formerly-known-as-node): Formerly known as `node`, this reflects Node.js versions older than v12. It supports looking up packages from `node_modules`, loading directory `index.js` files, and omitting `.js` extensions in relative module specifiers. Because Node.js v12 introduced different module resolution rules for ES modules, though, it’s a very bad model of modern versions of Node.js. It is deprecated in TypeScript 6.0 and should not be used for new projects.
 - [**`node16`**](/docs/handbook/modules/reference.html#node16-nodenext-1): This is the counterpart of `--module node16` and `--module node18` and is set by default with that `module` setting. Node.js v12 and later support both ESM and CJS, each of which uses its own module resolution algorithm. In Node.js, module specifiers in import statements and dynamic `import()` calls are not allowed to omit file extensions or `/index.js` suffixes, while module specifiers in `require` calls are. This module resolution mode understands and enforces this restriction where necessary, as determined by the [module format detection rules](#module-format-detection) instated by `--module node16`/`node18`. (For `node16` and `nodenext`, `module` and `moduleResolution` go hand-in-hand: setting one to `node16` or `nodenext` while setting the other to something else is an error.)
 - [**`nodenext`**](/docs/handbook/modules/reference.html#node16-nodenext-1): Currently identical to `node16`, this is the counterpart of `--module nodenext` and is set by default with that `module` setting. It’s intended to be a forward-looking mode that will support new Node.js module resolution features as they’re added.
-- [**`bundler`**](/docs/handbook/modules/reference.html#bundler): Node.js v12 introduced some new module resolution features for importing npm packages—the `"exports"` and `"imports"` fields of `package.json`—and many bundlers adopted those features without also adopting the stricter rules for ESM imports. This module resolution mode provides a base algorithm for code targeting a bundler. It supports `package.json` `"exports"` and `"imports"` by default, but can be configured to ignore them. It requires setting `module` to `esnext`.
+- [**`bundler`**](/docs/handbook/modules/reference.html#bundler): Node.js v12 introduced some new module resolution features for importing npm packages—the `"exports"` and `"imports"` fields of `package.json`—and many bundlers adopted those features without also adopting the stricter rules for ESM imports. This module resolution mode provides a base algorithm for code targeting a bundler. It supports `package.json` `"exports"` and `"imports"` by default, but can be configured to ignore them.
 
 ### TypeScript imitates the host’s module resolution, but with types
 
diff --git a/packages/documentation/copy/en/modules-reference/appendices/ESM-CJS-Interop.md b/packages/documentation/copy/en/modules-reference/appendices/ESM-CJS-Interop.md
index 9a24cc5c46b5..c549c46c83f1 100644
--- a/packages/documentation/copy/en/modules-reference/appendices/ESM-CJS-Interop.md
+++ b/packages/documentation/copy/en/modules-reference/appendices/ESM-CJS-Interop.md
@@ -280,7 +280,7 @@ In a TypeScript _application_ (as opposed to a library that others may consume)
 
 In an application that gets processed by a third-party transpiler or bundler, on the other hand, enabling `esModuleInterop` is more important. All major bundlers and transpilers use an `esModuleInterop`-like emit strategy, so TypeScript needs to adjust its checking to match. (The compiler always reasons about what will happen in the JavaScript files that `tsc` would emit, so even if another tool is being used in place of `tsc`, emit-affecting compiler options should still be set to match the output of that tool as closely as possible.)
 
-`allowSyntheticDefaultImports` without `esModuleInterop` should be avoided. It changes the compiler’s checking behavior without changing the code emitted by `tsc`, allowing potentially unsafe JavaScript to be emitted. Additionally, the checking changes it introduces are an incomplete version of the ones introduced by `esModuleInterop`. Even if `tsc` isn’t being used for emit, it’s better to enable `esModuleInterop` than `allowSyntheticDefaultImports`.
+Before TypeScript 6.0, `allowSyntheticDefaultImports` without `esModuleInterop` changed the compiler’s checking behavior without changing the code emitted by `tsc`, allowing potentially unsafe JavaScript to be emitted. TypeScript 6.0 and later always enables `esModuleInterop` and `allowSyntheticDefaultImports`.
 
 Some people object to the inclusion of the `__importDefault` and `__importStar` helper functions included in `tsc`’s JavaScript output when `esModuleInterop` is enabled, either because it marginally increases the output size on disk or because the interop algorithm employed by the helpers seems to misrepresent Node.js’s interop behavior by checking for `__esModule`, leading to the hazards discussed earlier. Both of these objections can be addressed, at least partially, without accepting the flawed checking behavior exhibited with `esModuleInterop` disabled. First, the `importHelpers` compiler option can be used to import the helper functions from `tslib` rather than inlining them into each file that needs them. To discuss the second objection, let’s look at a final example:
 
@@ -357,7 +357,7 @@ import express = require("express");
 // ...
 ```
 
-Examples like this have led to conventional wisdom that says libraries should _not_ enable `esModuleInterop`. This advice is a reasonable start, but we’ve looked at examples where the type of a namespace import changes, potentially _introducing_ an error, when enabling `esModuleInterop`. So whether libraries compile with or without `esModuleInterop`, they run the risk of writing syntax that makes their choice infectious.
+Examples like this led to conventional wisdom that libraries should _not_ enable `esModuleInterop`. In TypeScript 6.0 and later, `esModuleInterop` is always enabled, so libraries should avoid namespace imports for callable CommonJS exports and prefer syntax that remains portable for consumers.
 
 Library authors who want to go above and beyond to ensure maximum compatibility would do well to validate their declaration files against a matrix of compiler options. But using `verbatimModuleSyntax` completely sidesteps the issue with `esModuleInterop` by forcing CommonJS-emitting files to use CommonJS-style import and export syntax. Additionally, since `esModuleInterop` only affects CommonJS, as more libraries move to ESM-only publishing over time, the relevance of this issue will decline.
 
diff --git a/packages/documentation/copy/en/modules-reference/guides/Choosing Compiler Options.md b/packages/documentation/copy/en/modules-reference/guides/Choosing Compiler Options.md
index b3025b78fd16..85535a90d7fa 100644
--- a/packages/documentation/copy/en/modules-reference/guides/Choosing Compiler Options.md	
+++ b/packages/documentation/copy/en/modules-reference/guides/Choosing Compiler Options.md	
@@ -184,7 +184,7 @@ Let’s examine why we picked each of these settings:
   }
   ```
   is only an error under `strictNullChecks`. On the other hand, it’s very difficult to write code that errors only when `strict` is _disabled_, so it’s highly recommended for libraries to compile with `strict`.
-- **`verbatimModuleSyntax: true`**. This setting protects against a few module-related pitfalls that can cause problems for library consumers. First, it prevents writing any import statements that could be interpreted ambiguously based on the user’s value of `esModuleInterop` or `allowSyntheticDefaultImports`. Previously, it was often suggested that libraries compile without `esModuleInterop`, since its use in libraries could force users to adopt it too. However, it’s also possible to write imports that only work _without_ `esModuleInterop`, so neither value for the setting guarantees portability for libraries. `verbatimModuleSyntax` does provide such a guarantee.[^1] Second, it prevents the use of `export default` in modules that will be emitted as CommonJS, which can require bundler users and Node.js ESM users to consume the module differently. See the appendix on [ESM/CJS Interop](/docs/handbook/modules/appendices/esm-cjs-interop.html#library-code-needs-special-considerations) for more details.
+- **`verbatimModuleSyntax: true`**. This setting protects against a few module-related pitfalls that can cause problems for library consumers. First, it prevents writing any import statements that could be interpreted ambiguously by consumers. Previously, it was often suggested that libraries compile without `esModuleInterop`, since its use in libraries could force users to adopt it too. `esModuleInterop` is now always enabled, and `verbatimModuleSyntax` helps guarantee that import syntax remains portable.[^1] Second, it prevents the use of `export default` in modules that will be emitted as CommonJS, which can require bundler users and Node.js ESM users to consume the module differently. See the appendix on [ESM/CJS Interop](/docs/handbook/modules/appendices/esm-cjs-interop.html#library-code-needs-special-considerations) for more details.
 - **`declaration: true`** emits type declaration files alongside the output JavaScript. This is needed for consumers of the library to have any type information.
 - **`sourceMap: true`** and **`declarationMap: true`** emit source maps for the output JavaScript and type declaration files, respectively. These are only useful if the library also ships its source (`.ts`) files. By shipping source maps and source files, consumers of the library will be able to debug the library code somewhat more easily. By shipping declaration maps and source files, consumers will be able to see the original TypeScript sources when they run Go To Definition on imports from the libraries. Both of these represent a tradeoff between developer experience and library size, so it’s up to you whether to include them.
 - **`rootDir: "src"`** and **`outDir: "dist"`**. Using a separate output directory is always a good idea, but it’s _necessary_ for libraries that publish their input files. Otherwise, [extension substitution](/docs/handbook/modules/reference.html#file-extension-substitution) will cause the library’s consumers to load the library’s `.ts` files instead of `.d.ts` files, causing type errors and performance problems.
diff --git a/packages/documentation/copy/en/project-config/Compiler Options in MSBuild.md b/packages/documentation/copy/en/project-config/Compiler Options in MSBuild.md
index b17c75003d4a..aed1e671219b 100644
--- a/packages/documentation/copy/en/project-config/Compiler Options in MSBuild.md	
+++ b/packages/documentation/copy/en/project-config/Compiler Options in MSBuild.md	
@@ -340,7 +340,7 @@ There is a series of mappings for common TypeScript settings, these are settings
 <td><code><a href='/tsconfig/#baseUrl'>--baseUrl</a></code></td>
 </tr>
 <tr class="option-description even"><td colspan="3">
-<p>Specify the base directory to resolve bare specifier module names.</p>
+<p>Deprecated in TypeScript 6.0. Use <a href="#paths"><code>paths</code></a> entries instead.</p>
 
 </tr></td>
 <tr class='odd' name='declarationDir'>
diff --git a/packages/documentation/copy/en/project-config/Compiler Options.md b/packages/documentation/copy/en/project-config/Compiler Options.md
index 9fe309c03ebb..331026366dcd 100644
--- a/packages/documentation/copy/en/project-config/Compiler Options.md	
+++ b/packages/documentation/copy/en/project-config/Compiler Options.md	
@@ -8,28 +8,28 @@ disable_toc: true
 
 ## Using the CLI
 
-Running `tsc` locally will compile the closest project defined by a `tsconfig.json`, or you can compile a set of TypeScript
-files by passing in a glob of files you want. When input files are specified on the command line, `tsconfig.json` files are
-ignored.
+Running `tsc` locally will compile the closest project defined by a `tsconfig.json`.
+You can compile specific files by passing them on the command line, but in TypeScript 6.0 and later this is an error if a `tsconfig.json` would otherwise be loaded.
+Use `--ignoreConfig` when you want to compile command-line files with only the options passed on the command line.
 
 ```sh
 # Run a compile based on a backwards look through the fs for a tsconfig.json
 tsc
 
 # Emit JS for just the index.ts with the compiler defaults
-tsc index.ts
+tsc --ignoreConfig index.ts
 
 # Emit JS for any .ts files in the folder src, with the default settings
-tsc src/*.ts
+tsc --ignoreConfig src/*.ts
 
 # Emit files referenced in with the compiler settings from tsconfig.production.json
 tsc --project tsconfig.production.json
 
 # Emit d.ts files for a js file with showing compiler options which are booleans
-tsc index.js --declaration --emitDeclarationOnly
+tsc --ignoreConfig index.js --declaration --emitDeclarationOnly
 
-# Emit a single .js file from two files via compiler options which take string arguments
-tsc app.ts util.ts --target esnext --outfile index.js
+# Emit JavaScript files to a specific folder via compiler options which take string arguments
+tsc --ignoreConfig app.ts util.ts --target esnext --outDir dist
 ```
 
 ## Compiler Options
@@ -305,7 +305,7 @@ tsc app.ts util.ts --target esnext --outfile index.js
   <td><code><a href='/tsconfig/#allowSyntheticDefaultImports'>--allowSyntheticDefaultImports</a></code></td>
   <td><p><code>boolean</code></p>
 </td>
-  <td><p><code>true</code> if <a href="#esModuleInterop"><code>esModuleInterop</code></a> is enabled, <a href="#module"><code>module</code></a> is <code>system</code>, or <a href="#module-resolution"><code>moduleResolution</code></a> is <code>bundler</code>; <code>false</code> otherwise.</p>
+  <td><p><code>true</code></p>
 </td>
 </tr>
 <tr class="option-description even"><td colspan="3">
@@ -372,7 +372,7 @@ tsc app.ts util.ts --target esnext --outfile index.js
   <td></td>
 </tr>
 <tr class="option-description even"><td colspan="3">
-<p>Specify the base directory to resolve bare specifier module names.</p>
+<p>Deprecated in TypeScript 6.0. Use <a href="#paths"><code>paths</code></a> entries instead.</p>
 </td></tr>
 
 <tr class='odd' name='charset'>
@@ -846,7 +846,7 @@ tsc app.ts util.ts --target esnext --outfile index.js
   <td><code><a href='/tsconfig/#module'>--module</a></code></td>
   <td><p><code>none</code>, <code>commonjs</code>, <code>amd</code>, <code>umd</code>, <code>system</code>, <code>es6</code>/<code>es2015</code>, <code>es2020</code>, <code>es2022</code>, <code>esnext</code>, <code>node16</code>, <code>node18</code>, <code>node20</code>, <code>nodenext</code>, or <code>preserve</code></p>
 </td>
-  <td><p><code>CommonJS</code> if <a href="#target"><code>target</code></a> is <code>ES5</code>; <code>ES6</code>/<code>ES2015</code> otherwise.</p>
+  <td><p><code>esnext</code></p>
 </td>
 </tr>
 <tr class="option-description even"><td colspan="3">
@@ -1112,7 +1112,7 @@ tsc app.ts util.ts --target esnext --outfile index.js
   <td></td>
 </tr>
 <tr class="option-description even"><td colspan="3">
-<p>Deprecated setting. Use <a href="#outFile"><code>outFile</code></a> instead.</p>
+<p>Deprecated setting. Use an external bundler instead.</p>
 </td></tr>
 
 <tr class='odd' name='outDir'>
@@ -1132,7 +1132,7 @@ tsc app.ts util.ts --target esnext --outfile index.js
   <td></td>
 </tr>
 <tr class="option-description even"><td colspan="3">
-<p>Specify a file that bundles all outputs into one JavaScript file. If <a href="#declaration"><code>declaration</code></a> is true, also designates a file that bundles all .d.ts output.</p>
+<p>Removed in TypeScript 6.0. Use an external bundler instead.</p>
 </td></tr>
 
 <tr class='odd' name='paths'>
@@ -1465,7 +1465,7 @@ tsc app.ts util.ts --target esnext --outfile index.js
   <td><code><a href='/tsconfig/#target'>--target</a></code></td>
   <td><p><code>es3</code>, <code>es5</code>, <code>es6</code>/<code>es2015</code>, <code>es2016</code>, <code>es2017</code>, <code>es2018</code>, <code>es2019</code>, <code>es2020</code>, <code>es2021</code>, <code>es2022</code>, <code>es2023</code>, <code>es2024</code>, <code>es2025</code>, or <code>esnext</code></p>
 </td>
-  <td><p><code>es2023</code> if <a href="#module"><code>module</code></a> is <code>node20</code>; <code>esnext</code> if <a href="#module"><code>module</code></a> is <code>nodenext</code>; <code>ES5</code> otherwise.</p>
+  <td><p>The most recent stable ECMAScript version.</p>
 </td>
 </tr>
 <tr class="option-description odd"><td colspan="3">
diff --git a/packages/documentation/copy/en/project-config/Project References.md b/packages/documentation/copy/en/project-config/Project References.md
index 17bcedce8ec3..5be4cffbf58a 100644
--- a/packages/documentation/copy/en/project-config/Project References.md	
+++ b/packages/documentation/copy/en/project-config/Project References.md	
@@ -72,7 +72,6 @@ The `path` property of each reference can point to a directory containing a `tsc
 When you reference a project, new things happen:
 
 - Importing modules from a referenced project will instead load its _output_ declaration file (`.d.ts`)
-- If the referenced project produces an [`outFile`](/tsconfig#outFile), the output file `.d.ts` file's declarations will be visible in this project
 - Build mode (see below) will automatically build the referenced project if needed
 
 By separating into multiple projects, you can greatly improve the speed of typechecking and compiling, reduce memory usage when using an editor, and improve enforcement of the logical groupings of your program.
@@ -180,11 +179,6 @@ In general, not much is needed to transition a repo using relative modules.
 Simply place a `tsconfig.json` file in each subdirectory of a given parent folder, and add `reference`s to these config files to match the intended layering of the program.
 You will need to either set the [`outDir`](/tsconfig#outDir) to an explicit subfolder of the output folder, or set the [`rootDir`](/tsconfig#rootDir) to the common root of all project folders.
 
-### Structuring for outFiles
-
-Layout for compilations using [`outFile`](/tsconfig#outFile) is more flexible because relative paths don't matter as much.
-The TypeScript repo itself is a good reference here - we have some "library" projects and some "endpoint" projects; "endpoint" projects are kept as small as possible and pull in only the libraries they need.
-
 <!--
 ### Structuring for monorepos
 
diff --git a/packages/documentation/copy/en/project-config/tsconfig.json.md b/packages/documentation/copy/en/project-config/tsconfig.json.md
index ed3eefc0fd98..9932e1214f42 100644
--- a/packages/documentation/copy/en/project-config/tsconfig.json.md
+++ b/packages/documentation/copy/en/project-config/tsconfig.json.md
@@ -20,7 +20,8 @@ A project is compiled in one of the following ways:
 - By invoking tsc with no input files, in which case the compiler searches for the `tsconfig.json` file starting in the current directory and continuing up the parent directory chain.
 - By invoking tsc with no input files and a `--project` (or just `-p`) command line option that specifies the path of a directory containing a `tsconfig.json` file, or a path to a valid `.json` file containing the configurations.
 
-When input files are specified on the command line, `tsconfig.json` files are ignored.
+In TypeScript 6.0 and later, specifying input files on the command line is an error if a `tsconfig.json` file would otherwise be loaded.
+Use `--ignoreConfig` when you want to compile command-line files with only the options passed on the command line.
 
 ## Examples
 
@@ -60,11 +61,11 @@ Example `tsconfig.json` files:
   ```json  tsconfig
   {
     "compilerOptions": {
-      "module": "system",
+      "module": "commonjs",
       "noImplicitAny": true,
       "removeComments": true,
       "preserveConstEnums": true,
-      "outFile": "../../built/local/tsc.js",
+      "outDir": "../../built/local",
       "sourceMap": true
     },
     "include": ["src/**/*"],
diff --git a/packages/documentation/copy/en/reference/Decorators.md b/packages/documentation/copy/en/reference/Decorators.md
index fcdc59c9392e..cbded62619f8 100644
--- a/packages/documentation/copy/en/reference/Decorators.md
+++ b/packages/documentation/copy/en/reference/Decorators.md
@@ -22,7 +22,7 @@ To enable experimental support for decorators, you must enable the [`experimenta
 **Command Line**:
 
 ```shell
-tsc --target ES5 --experimentalDecorators
+tsc --target ES2015 --experimentalDecorators
 ```
 
 **tsconfig.json**:
@@ -30,7 +30,7 @@ tsc --target ES5 --experimentalDecorators
 ```json tsconfig
 {
   "compilerOptions": {
-    "target": "ES5",
+    "target": "ES2015",
     "experimentalDecorators": true
   }
 }
@@ -232,11 +232,11 @@ The expression for the method decorator will be called as a function at runtime,
 2. The name of the member.
 3. The _Property Descriptor_ for the member.
 
-> NOTE&emsp; The _Property Descriptor_ will be `undefined` if your script target is less than `ES5`.
+> NOTE&emsp; In TypeScript versions that support targets below `ES5`, the _Property Descriptor_ will be `undefined` for those targets.
 
 If the method decorator returns a value, it will be used as the _Property Descriptor_ for the method.
 
-> NOTE&emsp; The return value is ignored if your script target is less than `ES5`.
+> NOTE&emsp; In TypeScript versions that support targets below `ES5`, the return value is ignored for those targets.
 
 The following is an example of a method decorator (`@enumerable`) applied to a method on the `Greeter` class:
 
@@ -292,11 +292,11 @@ The expression for the accessor decorator will be called as a function at runtim
 2. The name of the member.
 3. The _Property Descriptor_ for the member.
 
-> NOTE&emsp; The _Property Descriptor_ will be `undefined` if your script target is less than `ES5`.
+> NOTE&emsp; In TypeScript versions that support targets below `ES5`, the _Property Descriptor_ will be `undefined` for those targets.
 
 If the accessor decorator returns a value, it will be used as the _Property Descriptor_ for the member.
 
-> NOTE&emsp; The return value is ignored if your script target is less than `ES5`.
+> NOTE&emsp; In TypeScript versions that support targets below `ES5`, the return value is ignored for those targets.
 
 The following is an example of an accessor decorator (`@configurable`) applied to a member of the `Point` class:
 
@@ -497,7 +497,7 @@ To enable this experimental support, you must set the [`emitDecoratorMetadata`](
 **Command Line**:
 
 ```shell
-tsc --target ES5 --experimentalDecorators --emitDecoratorMetadata
+tsc --target ES2015 --experimentalDecorators --emitDecoratorMetadata
 ```
 
 **tsconfig.json**:
@@ -505,7 +505,7 @@ tsc --target ES5 --experimentalDecorators --emitDecoratorMetadata
 ```json tsconfig
 {
   "compilerOptions": {
-    "target": "ES5",
+    "target": "ES2015",
     "experimentalDecorators": true,
     "emitDecoratorMetadata": true
   }
diff --git a/packages/documentation/copy/en/reference/Iterators and Generators.md b/packages/documentation/copy/en/reference/Iterators and Generators.md
index d8abda1e4ef1..e885542bc5d0 100644
--- a/packages/documentation/copy/en/reference/Iterators and Generators.md	
+++ b/packages/documentation/copy/en/reference/Iterators and Generators.md	
@@ -71,12 +71,12 @@ for (let pet of pets) {
 
 ### Code generation
 
-#### Targeting ES5
+#### Targeting ES5 in older TypeScript versions
 
-When targeting an ES5-compliant engine, iterators are only allowed on values of `Array` type.
+In TypeScript versions before 6.0, when targeting an ES5-compliant engine, iterators were only allowed on values of `Array` type.
 It is an error to use `for..of` loops on non-Array values, even if these non-Array values implement the `Symbol.iterator` property.
 
-The compiler will generate a simple `for` loop for a `for..of` loop, for instance:
+The compiler generated a simple `for` loop for a `for..of` loop, for instance:
 
 ```ts
 let numbers = [1, 2, 3];
diff --git a/packages/documentation/copy/en/reference/Namespaces and Modules.md b/packages/documentation/copy/en/reference/Namespaces and Modules.md
index cce66125b8f5..b275fc0b58db 100644
--- a/packages/documentation/copy/en/reference/Namespaces and Modules.md	
+++ b/packages/documentation/copy/en/reference/Namespaces and Modules.md	
@@ -31,7 +31,7 @@ Thus, for new projects modules would be the recommended code organization mechan
 Namespaces are a TypeScript-specific way to organize code.  
 Namespaces are simply named JavaScript objects in the global namespace.
 This makes namespaces a very simple construct to use.
-Unlike modules, they can span multiple files, and can be concatenated using [`outFile`](/tsconfig#outFile).
+Unlike modules, they can span multiple files.
 Namespaces can be a good way to structure your code in a Web Application, with all dependencies included as `<script>` tags in your HTML page.
 
 Just like all global namespace pollution, it can be hard to identify component dependencies, especially in a large application.
@@ -124,5 +124,5 @@ Here's a revised example:
 ### Trade-offs of Modules
 
 Just as there is a one-to-one correspondence between JS files and modules, TypeScript has a one-to-one correspondence between module source files and their emitted JS files.
-One effect of this is that it's not possible to concatenate multiple module source files depending on the module system you target.
-For instance, you can't use the [`outFile`](/tsconfig#outFile) option while targeting `commonjs` or `umd`, but with TypeScript 1.8 and later, [it's possible](./release-notes/typescript-1-8.html#concatenate-amd-and-system-modules-with---outfile) to use [`outFile`](/tsconfig#outFile) when targeting `amd` or `system`.
+One effect of this is that it's not possible for TypeScript to concatenate multiple module source files into one output file.
+Use a bundler if you need a single JavaScript output file.
diff --git a/packages/documentation/copy/en/reference/Namespaces.md b/packages/documentation/copy/en/reference/Namespaces.md
index 5ad3795b352d..0a6c03445587 100644
--- a/packages/documentation/copy/en/reference/Namespaces.md
+++ b/packages/documentation/copy/en/reference/Namespaces.md
@@ -9,11 +9,12 @@ translatable: true
 > **A note about terminology:**
 > It's important to note that in TypeScript 1.5, the nomenclature has changed.
 > "Internal modules" are now "namespaces".
-> "External modules" are now simply "modules", as to align with [ECMAScript 2015](https://www.ecma-international.org/ecma-262/6.0/)'s terminology, (namely that `module X {` is equivalent to the now-preferred `namespace X {`).
+> "External modules" are now simply "modules", to align with [ECMAScript 2015](https://www.ecma-international.org/ecma-262/6.0/)'s terminology.
+> Use `namespace X {` when declaring a namespace; the old `module X {` spelling is deprecated in TypeScript 6.0.
 
 This post outlines the various ways to organize your code using namespaces (previously "internal modules") in TypeScript.
 As we alluded in our note about terminology, "internal modules" are now referred to as "namespaces".
-Additionally, anywhere the `module` keyword was used when declaring an internal module, the `namespace` keyword can and should be used instead.
+Additionally, anywhere the `module` keyword was used when declaring an internal module, the `namespace` keyword should be used instead.
 This avoids confusing new users by overloading them with similarly named terms.
 
 ## First steps
@@ -193,19 +194,7 @@ for (let s of strings) {
 Once there are multiple files involved, we'll need to make sure all of the compiled code gets loaded.
 There are two ways of doing this.
 
-First, we can use concatenated output using the [`outFile`](/tsconfig#outFile) option to compile all of the input files into a single JavaScript output file:
-
-```Shell
-tsc --outFile sample.js Test.ts
-```
-
-The compiler will automatically order the output file based on the reference tags present in the files. You can also specify each file individually:
-
-```Shell
-tsc --outFile sample.js Validation.ts LettersOnlyValidator.ts ZipCodeValidator.ts Test.ts
-```
-
-Alternatively, we can use per-file compilation (the default) to emit one JavaScript file for each input file.
+We can use per-file compilation (the default) to emit one JavaScript file for each input file.
 If multiple JS files get produced, we'll need to use `<script>` tags on our webpage to load each emitted file in the appropriate order, for example:
 
 ##### MyTestPage.html (excerpt)
diff --git a/packages/documentation/copy/en/reference/Triple-Slash Directives.md b/packages/documentation/copy/en/reference/Triple-Slash Directives.md
index 873ac4f6ad70..f75d7365b1de 100644
--- a/packages/documentation/copy/en/reference/Triple-Slash Directives.md	
+++ b/packages/documentation/copy/en/reference/Triple-Slash Directives.md	
@@ -22,8 +22,7 @@ It serves as a declaration of _dependency_ between files.
 
 Triple-slash references instruct the compiler to include additional files in the compilation process.
 
-They also serve as a method to order the output when using [`out`](/tsconfig#out) or [`outFile`](/tsconfig#outFile).
-Files are emitted to the output file location in the same order as the input after preprocessing pass.
+In TypeScript versions before 6.0, they also served as a method to order concatenated output when using `outFile`.
 
 ### Preprocessing input files
 
@@ -78,11 +77,11 @@ For example, adding `/// <reference lib="es2017.string" />` to one of the files
 
 ## `/// <reference no-default-lib="true"/>`
 
-This directive marks a file as a _default library_.
-You will see this comment at the top of `lib.d.ts` and its different variants.
+This directive is deprecated in TypeScript 6.0.
+It was used to mark a file as a _default library_.
+You may still see this comment at the top of `lib.d.ts` and its different variants.
 
-This directive instructs the compiler to _not_ include the default library (i.e. `lib.d.ts`) in the compilation.
-The impact here is similar to passing [`noLib`](/tsconfig#noLib) on the command line.
+Use [`noLib`](/tsconfig#noLib) instead when you need to compile without the default library (i.e. `lib.d.ts`).
 
 Also note that when passing [`skipDefaultLibCheck`](/tsconfig#skipDefaultLibCheck), the compiler will only skip checking files with `/// <reference no-default-lib="true"/>`.
 
diff --git a/packages/documentation/copy/en/tutorials/Gulp.md b/packages/documentation/copy/en/tutorials/Gulp.md
index 8aa1d0df8cc5..47fe12f81d4d 100644
--- a/packages/documentation/copy/en/tutorials/Gulp.md
+++ b/packages/documentation/copy/en/tutorials/Gulp.md
@@ -86,7 +86,8 @@ In the project root, `proj`, create the file `tsconfig.json`:
   "files": ["src/main.ts"],
   "compilerOptions": {
     "noImplicitAny": true,
-    "target": "es5"
+    "module": "commonjs",
+    "target": "es2015"
   }
 }
 ```
@@ -142,7 +143,8 @@ Finally, add `src/greet.ts` to `tsconfig.json`:
   "files": ["src/main.ts", "src/greet.ts"],
   "compilerOptions": {
     "noImplicitAny": true,
-    "target": "es5"
+    "module": "commonjs",
+    "target": "es2015"
   }
 }
 ```
@@ -155,14 +157,14 @@ node dist/main.js
 ```
 
 Notice that even though we used ES2015 module syntax, TypeScript emitted CommonJS modules that Node uses.
-We'll stick with CommonJS for this tutorial, but you could set `module` in the options object to change this.
+We'll stick with CommonJS for this tutorial, but you could set `module` to another value to change this.
 
 ## Browserify
 
 Now let's move this project from Node to the browser.
 To do this, we'd like to bundle all our modules into one JavaScript file.
 Fortunately, that's exactly what Browserify does.
-Even better, it lets us use the CommonJS module system used by Node, which is the default TypeScript emit.
+Even better, it lets us use the CommonJS module system used by Node.
 That means our TypeScript and Node setup will transfer to the browser basically unchanged.
 
 First, install browserify, [tsify](https://www.npmjs.com/package/tsify), and vinyl-source-stream.
diff --git a/packages/documentation/copy/en/tutorials/Migrating from JavaScript.md b/packages/documentation/copy/en/tutorials/Migrating from JavaScript.md
index 4a8ba2ecfbca..c92600e0c42b 100644
--- a/packages/documentation/copy/en/tutorials/Migrating from JavaScript.md	
+++ b/packages/documentation/copy/en/tutorials/Migrating from JavaScript.md	
@@ -48,7 +48,7 @@ Let's create a bare-bones one for our project:
   "compilerOptions": {
     "outDir": "./built",
     "allowJs": true,
-    "target": "es5"
+    "target": "es2015"
   },
   "include": ["./src/**/*"]
 }
@@ -59,7 +59,7 @@ Here we're specifying a few things to TypeScript:
 1. Read in any files it understands in the `src` directory (with [`include`](/tsconfig#include)).
 2. Accept JavaScript files as inputs (with [`allowJs`](/tsconfig#allowJs)).
 3. Emit all of the output files in `built` (with [`outDir`](/tsconfig#outDir)).
-4. Translate newer JavaScript constructs down to an older version like ECMAScript 5 (using [`target`](/tsconfig#target)).
+4. Translate newer JavaScript constructs down to a specific ECMAScript version (using [`target`](/tsconfig#target)).
 
 At this point, if you try running `tsc` at the root of your project, you should see output files in the `built` directory.
 The layout of files in `built` should look identical to the layout of `src`.
@@ -219,7 +219,7 @@ If TypeScript complains about a package like `lodash`, you can just write
 npm install -S @types/lodash
 ```
 
-If you're using a module option other than `commonjs`, you'll need to set your [`moduleResolution`](/tsconfig#moduleResolution) option to `node`.
+If you're using a modern module option, set your [`moduleResolution`](/tsconfig#moduleResolution) option to match your runtime or bundler.
 
 After that, you'll be able to import lodash with no issues, and get accurate completions.
 
diff --git a/packages/tsconfig-reference/copy/en/options/allowSyntheticDefaultImports.md b/packages/tsconfig-reference/copy/en/options/allowSyntheticDefaultImports.md
index d0304f02d4d8..e988cf19f5f7 100644
--- a/packages/tsconfig-reference/copy/en/options/allowSyntheticDefaultImports.md
+++ b/packages/tsconfig-reference/copy/en/options/allowSyntheticDefaultImports.md
@@ -3,7 +3,7 @@ display: "Allow Synthetic Default Imports"
 oneline: "Allow 'import x from y' when a module doesn't have a default export."
 ---
 
-When set to true, `allowSyntheticDefaultImports` allows you to write an import like:
+`allowSyntheticDefaultImports` allows you to write an import like:
 
 ```ts
 import React from "react";
@@ -17,13 +17,11 @@ import * as React from "react";
 
 When the module **does not** explicitly specify a default export.
 
-For example, without `allowSyntheticDefaultImports` as true:
+For example, this import is allowed even though `./utilFunctions` does not explicitly declare a default export:
 
 ```ts twoslash
-// @errors: 1259 1192
 // @checkJs
 // @allowJs
-// @esModuleInterop: false
 // @filename: utilFunctions.js
 // @noImplicitAny: false
 const getStringLength = (str) => str.length;
@@ -38,7 +36,6 @@ import utils from "./utilFunctions";
 const count = utils.getStringLength("Check JS");
 ```
 
-This code raises an error because there isn't a `default` object which you can import. Even though it feels like it should.
 For convenience, transpilers like Babel will automatically create a default if one isn't created. Making the module look a bit more like:
 
 ```js
diff --git a/packages/tsconfig-reference/copy/en/options/alwaysStrict.md b/packages/tsconfig-reference/copy/en/options/alwaysStrict.md
index 694eb9616a97..30cd863c0591 100644
--- a/packages/tsconfig-reference/copy/en/options/alwaysStrict.md
+++ b/packages/tsconfig-reference/copy/en/options/alwaysStrict.md
@@ -3,6 +3,8 @@ display: "Always Strict"
 oneline: "Ensure 'use strict' is always emitted."
 ---
 
-Ensures that your files are parsed in the ECMAScript strict mode, and emit "use strict" for each source file.
+**Default**: `true`
+
+Ensures that your files are parsed in the ECMAScript strict mode, and emit `"use strict"` for each source file.
 
 [ECMAScript strict](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Strict_mode) mode was introduced in ES5 and provides behavior tweaks to the runtime of the JavaScript engine to improve performance, and makes a set of errors throw instead of silently ignoring them.
diff --git a/packages/tsconfig-reference/copy/en/options/baseUrl.md b/packages/tsconfig-reference/copy/en/options/baseUrl.md
index b3317157652f..3faafe2e8d58 100644
--- a/packages/tsconfig-reference/copy/en/options/baseUrl.md
+++ b/packages/tsconfig-reference/copy/en/options/baseUrl.md
@@ -3,24 +3,18 @@ display: "Base URL"
 oneline: "Specify the base directory to resolve bare specifier module names."
 ---
 
-Sets a base directory from which to resolve bare specifier module names. For example, in the directory structure:
+This option is deprecated in TypeScript 6.0 and later.
+It was designed for use in conjunction with AMD module loaders in the browser, and is not recommended in any other context.
+As of TypeScript 4.1, `baseUrl` is no longer required to be set when using [`paths`](#paths).
 
-```
-project
-├── ex.ts
-├── hello
-│   └── world.ts
-└── tsconfig.json
-```
-
-With `"baseUrl": "./"`, TypeScript will look for files starting at the same folder as the `tsconfig.json`:
+If you previously used `baseUrl` as a common prefix for paths, move the prefix into the `paths` entries instead:
 
-```ts
-import { helloWorld } from "hello/world";
-
-console.log(helloWorld);
+```json tsconfig
+{
+  "compilerOptions": {
+    "paths": {
+      "hello/*": ["./hello/*"]
+    }
+  }
+}
 ```
-
-This resolution has higher priority than lookups from `node_modules`.
-
-This feature was designed for use in conjunction with AMD module loaders in the browser, and is not recommended in any other context. As of TypeScript 4.1, `baseUrl` is no longer required to be set when using [`paths`](#paths).
\ No newline at end of file
diff --git a/packages/tsconfig-reference/copy/en/options/downlevelIteration.md b/packages/tsconfig-reference/copy/en/options/downlevelIteration.md
index 9f2812fc7d0f..5f6890415ac1 100644
--- a/packages/tsconfig-reference/copy/en/options/downlevelIteration.md
+++ b/packages/tsconfig-reference/copy/en/options/downlevelIteration.md
@@ -3,6 +3,9 @@ display: "Downlevel Iteration"
 oneline: "Emit more compliant, but verbose and less performant JavaScript for iteration."
 ---
 
+This option is deprecated in TypeScript 6.0 and later.
+It only affects ES5 emit, and `target: "es5"` is also deprecated.
+
 Downleveling is TypeScript's term for transpiling to an older version of JavaScript.
 This flag is to enable support for a more accurate implementation of how modern JavaScript iterates through new concepts in older JavaScript runtimes.
 
diff --git a/packages/tsconfig-reference/copy/en/options/esModuleInterop.md b/packages/tsconfig-reference/copy/en/options/esModuleInterop.md
index 44f0aafd1dc2..f717b14079fb 100644
--- a/packages/tsconfig-reference/copy/en/options/esModuleInterop.md
+++ b/packages/tsconfig-reference/copy/en/options/esModuleInterop.md
@@ -3,7 +3,7 @@ display: "ES Module Interop"
 oneline: "Emit additional JavaScript to ease support for importing CommonJS modules. This enables [`allowSyntheticDefaultImports`](#allowSyntheticDefaultImports) for type compatibility."
 ---
 
-By default (with `esModuleInterop` false or not set) TypeScript treats CommonJS/AMD/UMD modules similar to ES6 modules. In doing this, there are two parts in particular which turned out to be flawed assumptions:
+TypeScript uses compatibility helpers for CommonJS interop. Before `esModuleInterop` was enabled by default, TypeScript treated CommonJS modules similar to ES modules in ways that turned out to be flawed assumptions:
 
 - a namespace import like `import * as moment from "moment"` acts the same as `const moment = require("moment")`
 
@@ -16,7 +16,7 @@ This mis-match causes these two issues:
 
 - while accurate to the ES6 modules spec, most libraries with CommonJS/AMD/UMD modules didn't conform as strictly as TypeScript's implementation.
 
-Turning on `esModuleInterop` will fix both of these problems in the code transpiled by TypeScript. The first changes the behavior in the compiler, the second is fixed by two new helper functions which provide a shim to ensure compatibility in the emitted JavaScript:
+`esModuleInterop` fixes both of these problems in the code transpiled by TypeScript. The first changes the behavior in the compiler, the second is fixed by two helper functions which provide a shim to ensure compatibility in the emitted JavaScript:
 
 ```ts
 import * as fs from "fs";
@@ -26,20 +26,6 @@ fs.readFileSync("file.txt", "utf8");
 _.chunk(["a", "b", "c", "d"], 2);
 ```
 
-With `esModuleInterop` disabled:
-
-```ts twoslash
-// @noErrors
-// @showEmit
-// @esModuleInterop: false
-// @module: commonjs
-import * as fs from "fs";
-import _ from "lodash";
-
-fs.readFileSync("file.txt", "utf8");
-_.chunk(["a", "b", "c", "d"], 2);
-```
-
 With `esModuleInterop` set to `true`:
 
 ```ts twoslash
@@ -54,7 +40,7 @@ fs.readFileSync("file.txt", "utf8");
 _.chunk(["a", "b", "c", "d"], 2);
 ```
 
-_Note_: The namespace import `import * as fs from "fs"` only accounts for properties which [are owned](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/hasOwnProperty) (basically properties set on the object and not via the prototype chain) on the imported object. If the module you're importing defines its API using inherited properties, you need to use the default import form (`import fs from "fs"`), or disable `esModuleInterop`.
+_Note_: The namespace import `import * as fs from "fs"` only accounts for properties which [are owned](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/hasOwnProperty) (basically properties set on the object and not via the prototype chain) on the imported object. If the module you're importing defines its API using inherited properties, you need to use the default import form (`import fs from "fs"`).
 
 _Note_: You can make JS emit terser by enabling [`importHelpers`](#importHelpers):
 
diff --git a/packages/tsconfig-reference/copy/en/options/explainFiles.md b/packages/tsconfig-reference/copy/en/options/explainFiles.md
index d907a3c702da..f198c238285b 100644
--- a/packages/tsconfig-reference/copy/en/options/explainFiles.md
+++ b/packages/tsconfig-reference/copy/en/options/explainFiles.md
@@ -19,7 +19,7 @@ Using a `tsconfig.json` which has `explainFiles` set to true:
 ```json
 {
   "compilerOptions": {
-    "target": "es5",
+    "target": "es2015",
     "module": "commonjs",
     "explainFiles": true
   }
@@ -31,9 +31,9 @@ Running TypeScript against this folder would have output like this:
 ```
 ❯ tsc
 node_modules/typescript/lib/lib.d.ts
-  Default library for target 'es5'
-node_modules/typescript/lib/lib.es5.d.ts
-  Library referenced via 'es5' from file 'node_modules/typescript/lib/lib.d.ts'
+  Default library for target 'es2015'
+node_modules/typescript/lib/lib.es2015.d.ts
+  Library referenced via 'es2015' from file 'node_modules/typescript/lib/lib.d.ts'
 node_modules/typescript/lib/lib.dom.d.ts
   Library referenced via 'dom' from file 'node_modules/typescript/lib/lib.d.ts'
 node_modules/typescript/lib/lib.webworker.importscripts.d.ts
diff --git a/packages/tsconfig-reference/copy/en/options/lib.md b/packages/tsconfig-reference/copy/en/options/lib.md
index fb0311a7aa7e..6082dbe115d7 100644
--- a/packages/tsconfig-reference/copy/en/options/lib.md
+++ b/packages/tsconfig-reference/copy/en/options/lib.md
@@ -30,16 +30,19 @@ In TypeScript 4.5, lib files can be overridden by npm modules, find out more [in
 | `ES2021`     | Additional APIs available in ES2021 - `promise.any`, `string.replaceAll` etc.                                                                     |
 | `ES2022`     | Additional APIs available in ES2022 - `array.at`, `RegExp.hasIndices`, etc.                                                                       |
 | `ES2023`     | Additional APIs available in ES2023 - `array.with`, `array.findLast`, `array.findLastIndex`, `array.toSorted`, `array.toReversed`, etc.           |
+| `ES2024`     | Additional APIs available in ES2024 - `Object.groupBy`, `Map.groupBy`, `Promise.withResolvers`, `ArrayBuffer`, `SharedArrayBuffer`, etc.          |
+| `ES2025`     | Additional APIs available in ES2025 - `RegExp.escape`, `Map` and `WeakMap` upsert methods, etc.                                                   |
 | `ESNext`     | Additional APIs available in ESNext - This changes as the JavaScript specification evolves                                                        |
 | `DOM`        | [DOM](https://developer.mozilla.org/docs/Glossary/DOM) definitions - `window`, `document`, etc.                                                   |
 | `WebWorker`  | APIs available in [WebWorker](https://developer.mozilla.org/docs/Web/API/Web_Workers_API/Using_web_workers) contexts                              |
 | `ScriptHost` | APIs for the [Windows Script Hosting System](https://wikipedia.org/wiki/Windows_Script_Host)                                                      |
 
+In TypeScript 6.0 and later, `DOM` includes the contents that were previously split into `DOM.Iterable` and `DOM.AsyncIterable`.
+
 ### Individual library components
 
 | Name                      |
 | ------------------------- |
-| `DOM.Iterable`            |
 | `ES2015.Core`             |
 | `ES2015.Collection`       |
 | `ES2015.Generator`        |
diff --git a/packages/tsconfig-reference/copy/en/options/libReplacement.md b/packages/tsconfig-reference/copy/en/options/libReplacement.md
index 2b8069825609..14bd9a433fc1 100644
--- a/packages/tsconfig-reference/copy/en/options/libReplacement.md
+++ b/packages/tsconfig-reference/copy/en/options/libReplacement.md
@@ -18,5 +18,4 @@ For example, you could lock your `dom` libraries onto a specific version of [the
 When installed, a package called `@typescript/lib-dom` should exist, and TypeScript would always look there when searching for `lib.dom.d.ts`.
 
 The `--libReplacement` flag allows you to disable this behavior.
-If you're not using any `@typescript/lib-*` packages, you can now disable those package lookups with `--libReplacement false`.
-In the future, `--libReplacement false` may become the default, so if you currently rely on the behavior you should consider explicitly enabling it with `--libReplacement true`.
\ No newline at end of file
+If you are using `@typescript/lib-*` packages, explicitly enable those package lookups with `--libReplacement true`.
diff --git a/packages/tsconfig-reference/copy/en/options/module.md b/packages/tsconfig-reference/copy/en/options/module.md
index fef555737b1f..9ba6d03c5e1d 100644
--- a/packages/tsconfig-reference/copy/en/options/module.md
+++ b/packages/tsconfig-reference/copy/en/options/module.md
@@ -3,6 +3,8 @@ display: "Module"
 oneline: "Specify what module code is generated."
 ---
 
+**Default**: `esnext`
+
 Sets the module system for the program. See the [theory behind TypeScript’s `module` option](/docs/handbook/modules/theory.html#the-module-output-format) and [its reference page](/docs/handbook/modules/reference.html#the-module-compiler-option) for more information. You very likely want `"nodenext"` for modern Node.js projects and `preserve` or `esnext` for code that will be bundled.
 
 Changing `module` affects [`moduleResolution`](#moduleResolution) which [also has a reference page](/docs/handbook/modules/reference.html#the-moduleresolution-compiler-option).
@@ -32,6 +34,8 @@ export const twoPi = valueOfPi * 2;
 
 #### `UMD`
 
+This module kind is deprecated in TypeScript 6.0 and later.
+
 ```ts twoslash
 // @showEmit
 // @module: umd
@@ -43,6 +47,8 @@ export const twoPi = valueOfPi * 2;
 
 #### `AMD`
 
+This module kind is deprecated in TypeScript 6.0 and later.
+
 ```ts twoslash
 // @showEmit
 // @module: amd
@@ -54,6 +60,8 @@ export const twoPi = valueOfPi * 2;
 
 #### `System`
 
+This module kind is deprecated in TypeScript 6.0 and later.
+
 ```ts twoslash
 // @showEmit
 // @module: system
@@ -116,6 +124,8 @@ While it’s rare to need to mix imports and require calls in the same file, thi
 
 #### `None`
 
+This module kind is deprecated in TypeScript 6.0 and later.
+
 ```ts twoslash
 // @showEmit
 // @module: none
diff --git a/packages/tsconfig-reference/copy/en/options/moduleResolution.md b/packages/tsconfig-reference/copy/en/options/moduleResolution.md
index 81a58e345e95..ef1dbb031f20 100644
--- a/packages/tsconfig-reference/copy/en/options/moduleResolution.md
+++ b/packages/tsconfig-reference/copy/en/options/moduleResolution.md
@@ -6,8 +6,8 @@ oneline: "Specify how TypeScript looks up a file from a given module specifier."
 Specify the module resolution strategy:
 
 - `'node16'` or `'nodenext'` for modern versions of Node.js. Node.js v12 and later supports both ECMAScript imports and CommonJS `require`, which resolve using different algorithms. These `moduleResolution` values, when combined with the corresponding [`module`](#module) values, picks the right algorithm for each resolution based on whether Node.js will see an `import` or `require` in the output JavaScript code.
-- `'node10'` (previously called `'node'`) for Node.js versions older than v10, which only support CommonJS `require`. You probably won't need to use `node10` in modern code.
+- `'node10'` (previously called `'node'`) for Node.js versions older than v10, which only support CommonJS `require`. This is deprecated in TypeScript 6.0.
 - `'bundler'` for use with bundlers. Like `node16` and `nodenext`, this mode supports package.json `"imports"` and `"exports"`, but unlike the Node.js resolution modes, `bundler` never requires file extensions on relative paths in imports.
-- `'classic'` was used in TypeScript before the release of 1.6. `classic` should not be used.
+- `'classic'` was used in TypeScript before the release of 1.6. This is deprecated in TypeScript 6.0 and should not be used.
 
 There are reference pages explaining the [theory behind TypeScript’s module resolution](https://www.typescriptlang.org/docs/handbook/modules/theory.html#module-resolution) and the [details of each option](/docs/handbook/modules/reference.html#the-moduleresolution-compiler-option).
diff --git a/packages/tsconfig-reference/copy/en/options/noUncheckedSideEffectImports.md b/packages/tsconfig-reference/copy/en/options/noUncheckedSideEffectImports.md
index e6d862efc733..33ae7b08d1cd 100644
--- a/packages/tsconfig-reference/copy/en/options/noUncheckedSideEffectImports.md
+++ b/packages/tsconfig-reference/copy/en/options/noUncheckedSideEffectImports.md
@@ -11,10 +11,11 @@ import "some-module";
 
 These imports are often called *side effect imports* because the only useful behavior they can provide is by executing some side effect (like registering a global variable, or adding a polyfill to a prototype).
 
-By default, TypeScript will not check these imports for validity. If the import resolves to a valid source file, TypeScript will load and check the file.
-If no source file is found, TypeScript will silently ignore the import.
+By default, TypeScript checks these imports for validity. If the import resolves to a valid source file, TypeScript will load and check the file.
+If no source file is found, TypeScript will issue an error.
 
-This is surprising behavior, but it partially stems from modeling patterns in the JavaScript ecosystem.
+Older versions of TypeScript silently ignored unresolved side effect imports, but that behavior could hide typos.
+It partially stemmed from modeling patterns in the JavaScript ecosystem.
 For example, this syntax has also been used with special loaders in bundlers to load CSS or other assets.
 Your bundler might be configured in such a way where you can include specific `.css` files by writing something like the following:
 
diff --git a/packages/tsconfig-reference/copy/en/options/out.md b/packages/tsconfig-reference/copy/en/options/out.md
index be05ae019436..145ae400e954 100644
--- a/packages/tsconfig-reference/copy/en/options/out.md
+++ b/packages/tsconfig-reference/copy/en/options/out.md
@@ -1,9 +1,9 @@
 ---
 display: "Out"
-oneline: "Deprecated setting. Use [`outFile`](#outFile) instead."
+oneline: "Deprecated setting. Use an external bundler instead."
 ---
 
-Use [`outFile`](#outFile) instead.
+Use an external bundler instead.
 
 The `out` option computes the final file location in a way that is not predictable or consistent.
 This option is retained for backward compatibility only and is deprecated.
diff --git a/packages/tsconfig-reference/copy/en/options/outDir.md b/packages/tsconfig-reference/copy/en/options/outDir.md
index a205af13ac8c..cddbb61675b4 100644
--- a/packages/tsconfig-reference/copy/en/options/outDir.md
+++ b/packages/tsconfig-reference/copy/en/options/outDir.md
@@ -4,7 +4,7 @@ oneline: "Specify an output folder for all emitted files."
 ---
 
 If specified, `.js` (as well as `.d.ts`, `.js.map`, etc.) files will be emitted into this directory.
-The directory structure of the original source files is preserved; see [`rootDir`](#rootDir) if the computed root is not what you intended.
+The directory structure of the original source files is preserved relative to [`rootDir`](#rootDir).
 
 If not specified, `.js` files will be emitted in the same directory as the `.ts` files they were generated from:
 
diff --git a/packages/tsconfig-reference/copy/en/options/outFile.md b/packages/tsconfig-reference/copy/en/options/outFile.md
index 12f60ee892f1..b81c42d5c4b3 100644
--- a/packages/tsconfig-reference/copy/en/options/outFile.md
+++ b/packages/tsconfig-reference/copy/en/options/outFile.md
@@ -1,11 +1,13 @@
 ---
 display: "Out File"
-oneline: "Specify a file that bundles all outputs into one JavaScript file. If [`declaration`](#declaration) is true, also designates a file that bundles all .d.ts output."
+oneline: "Deprecated setting. Use a bundler instead."
 ---
 
-If specified, all _global_ (non-module) files will be concatenated into the single output file specified.
+This option is removed in TypeScript 6.0 and later.
+Use a bundler like esbuild, Rollup, Vite, or webpack instead.
 
-If `module` is `system` or `amd`, all module files will also be concatenated into this file after all global content.
+In earlier TypeScript versions, specifying this option concatenated all _global_ (non-module) files into the single output file specified.
 
-Note: `outFile` cannot be used unless `module` is `None`, `System`, or `AMD`.
-This option _cannot_ be used to bundle CommonJS or ES6 modules.
+If `module` was `system` or `amd`, all module files were also concatenated into this file after all global content.
+
+This option could not be used to bundle CommonJS or ES6 modules.
diff --git a/packages/tsconfig-reference/copy/en/options/rootDir.md b/packages/tsconfig-reference/copy/en/options/rootDir.md
index ff7447a81013..71975e99220a 100644
--- a/packages/tsconfig-reference/copy/en/options/rootDir.md
+++ b/packages/tsconfig-reference/copy/en/options/rootDir.md
@@ -3,7 +3,7 @@ display: "Root Dir"
 oneline: "Specify the root folder within your source files."
 ---
 
-**Default**: The longest common path of all non-declaration input files. If [`composite`](#composite) is set, the default is instead the directory containing the `tsconfig.json` file.
+**Default**: The directory containing the `tsconfig.json` file. If compiling files from the command line without a `tsconfig.json`, the default is the longest common path of all non-declaration input files.
 
 When TypeScript compiles files, it keeps the same directory structure in the output directory as exists in the input directory.
 
@@ -20,30 +20,28 @@ MyProj
 ├── types.d.ts
 ```
 
-The inferred value for `rootDir` is the longest common path of all non-declaration input files, which in this case is `core/`.
-
 If your [`outDir`](#outDir) was `dist`, TypeScript would write this tree:
 
 ```
 MyProj
 ├── dist
-│   ├── a.js
-│   ├── b.js
-│   ├── sub
-│   │   ├── c.js
+│   ├── core
+│   │   ├── a.js
+│   │   ├── b.js
+│   │   ├── sub
+│   │   │   ├── c.js
 ```
 
-However, you may have intended for `core` to be part of the output directory structure.
-By setting `rootDir: "."` in `tsconfig.json`, TypeScript would write this tree:
+If you want `core` to be treated as the root of your source tree, set `rootDir: "core"` in `tsconfig.json`.
+TypeScript would then write this tree:
 
 ```
 MyProj
 ├── dist
-│   ├── core
-│   │   ├── a.js
-│   │   ├── b.js
-│   │   ├── sub
-│   │   │   ├── c.js
+│   ├── a.js
+│   ├── b.js
+│   ├── sub
+│   │   ├── c.js
 ```
 
 Importantly, `rootDir` **does not affect which files become part of the compilation**.
diff --git a/packages/tsconfig-reference/copy/en/options/strict.md b/packages/tsconfig-reference/copy/en/options/strict.md
index cc35ee30ec00..fdd974a0f90c 100644
--- a/packages/tsconfig-reference/copy/en/options/strict.md
+++ b/packages/tsconfig-reference/copy/en/options/strict.md
@@ -3,6 +3,8 @@ display: "Strict"
 oneline: "Enable all strict type-checking options."
 ---
 
+**Default**: `true`
+
 The `strict` flag enables a wide range of type checking behavior that results in stronger guarantees of program correctness.
 Turning this on is equivalent to enabling all of the _strict mode family_ options, which are outlined below.
 You can then turn off individual strict mode family checks as needed.
diff --git a/packages/tsconfig-reference/copy/en/options/target.md b/packages/tsconfig-reference/copy/en/options/target.md
index b31b482ebb24..b7ddb829a79a 100644
--- a/packages/tsconfig-reference/copy/en/options/target.md
+++ b/packages/tsconfig-reference/copy/en/options/target.md
@@ -3,11 +3,14 @@ display: "Target"
 oneline: "Set the JavaScript language version for emitted JavaScript and include compatible library declarations."
 ---
 
-Modern browsers support all ES6 features, so `ES6` is a good choice.
+**Default**: The most recent supported ECMAScript version.
+
+Modern runtimes support newer ECMAScript features, so a recent target is a good choice.
 You might choose to set a lower target if your code is deployed to older environments, or a higher target if your code is guaranteed to run in newer environments.
+The lowest supported target is `ES2015`.
 
 The `target` setting changes which JS features are downleveled and which are left intact.
-For example, an arrow function `() => this` will be turned into an equivalent `function` expression if `target` is ES5 or lower.
+For example, an arrow function `() => this` will be left as-is when targeting `ES2015` or higher.
 
 Changing `target` also changes the default value of [`lib`](#lib).
 You may "mix and match" `target` and `lib` settings as desired, but you could just set `target` for convenience.
diff --git a/packages/tsconfig-reference/copy/en/options/tsBuildInfoFile.md b/packages/tsconfig-reference/copy/en/options/tsBuildInfoFile.md
index 8d41ade9b4b2..46bcb6148644 100644
--- a/packages/tsconfig-reference/copy/en/options/tsBuildInfoFile.md
+++ b/packages/tsconfig-reference/copy/en/options/tsBuildInfoFile.md
@@ -8,7 +8,7 @@ building of larger TypeScript codebases. You can read more about composite proje
 
 The default depends on a combination of other settings:
 
-- If `outFile` is set, the default is `<outFile>.tsbuildinfo`.
+- In TypeScript versions before 6.0, if `outFile` is set, the default is `<outFile>.tsbuildinfo`.
 - If `rootDir` and `outDir` are set, then the file is `<outDir>/<relative path to config from rootDir>/<config name>.tsbuildinfo`
   For example, if `rootDir` is `src`, `outDir` is `dest`, and the config is
   `./tsconfig.json`, then the default is `./tsconfig.tsbuildinfo`
diff --git a/packages/tsconfig-reference/copy/en/options/typeRoots.md b/packages/tsconfig-reference/copy/en/options/typeRoots.md
index 5fdb453bfa9e..d794b16e0bb2 100644
--- a/packages/tsconfig-reference/copy/en/options/typeRoots.md
+++ b/packages/tsconfig-reference/copy/en/options/typeRoots.md
@@ -3,19 +3,33 @@ display: "Type Roots"
 oneline: "Specify multiple folders that act like `./node_modules/@types`."
 ---
 
-By default all _visible_ "`@types`" packages are included in your compilation.
-Packages in `node_modules/@types` of any enclosing folder are considered _visible_.
-For example, that means packages within `./node_modules/@types/`, `../node_modules/@types/`, `../../node_modules/@types/`, and so on.
+The `typeRoots` option specifies folders that act like `./node_modules/@types`.
+It changes where TypeScript looks when resolving type package names from [`types`](#types) and `/// <reference types="..." />` directives.
 
-If `typeRoots` is specified, _only_ packages under `typeRoots` will be included. For example:
+In TypeScript 6.0 and later, [`types`](#types) defaults to `[]`, so specifying `typeRoots` does not by itself include every package under those folders.
+List the packages you need in `types`, or specify `"types": ["*"]` to include all packages under the configured `typeRoots`.
+
+For example:
 
 ```json tsconfig
 {
   "compilerOptions": {
-    "typeRoots": ["./typings", "./vendor/types"]
+    "typeRoots": ["./typings", "./vendor/types"],
+    "types": ["node"]
   }
 }
 ```
 
-This config file will include _all_ packages under `./typings` and `./vendor/types`, and no packages from `./node_modules/@types`.
+This config file will look for the `node` type package under `./typings` and `./vendor/types`, and will not look for it under `./node_modules/@types`.
 All paths are relative to the `tsconfig.json`.
+
+To include _all_ packages under `./typings` and `./vendor/types`, use:
+
+```json tsconfig
+{
+  "compilerOptions": {
+    "typeRoots": ["./typings", "./vendor/types"],
+    "types": ["*"]
+  }
+}
+```
diff --git a/packages/tsconfig-reference/copy/en/options/types.md b/packages/tsconfig-reference/copy/en/options/types.md
index 0b0f8f93744c..799f467435d0 100644
--- a/packages/tsconfig-reference/copy/en/options/types.md
+++ b/packages/tsconfig-reference/copy/en/options/types.md
@@ -3,23 +3,33 @@ display: "Types"
 oneline: "Specify type package names to be included without being referenced in a source file."
 ---
 
-By default all _visible_ "`@types`" packages are included in your compilation.
-Packages in `node_modules/@types` of any enclosing folder are considered _visible_.
-For example, that means packages within `./node_modules/@types/`, `../node_modules/@types/`, `../../node_modules/@types/`, and so on.
+By default, no "`@types`" packages are included in the global scope unless they are referenced by your source files.
 
 If `types` is specified, only packages listed will be included in the global scope. For instance:
 
 ```json tsconfig
 {
   "compilerOptions": {
-    "types": ["node", "jest", "express"]
+    "types": ["node", "jest"]
   }
 }
 ```
 
-This `tsconfig.json` file will _only_ include `./node_modules/@types/node`, `./node_modules/@types/jest` and `./node_modules/@types/express`.
+This `tsconfig.json` file will _only_ include `./node_modules/@types/node` and `./node_modules/@types/jest`.
 Other packages under `node_modules/@types/*` will not be included.
 
+To include all _visible_ "`@types`" packages, specify `"*"`.
+Packages in `node_modules/@types` of any enclosing folder are considered _visible_.
+For example, that means packages within `./node_modules/@types/`, `../node_modules/@types/`, `../../node_modules/@types/`, and so on.
+
+```json tsconfig
+{
+  "compilerOptions": {
+    "types": ["*"]
+  }
+}
+```
+
 ### What does this affect?
 
 This option does not affect how `@types/*` are included in your application code, for example if you had the above `compilerOptions` example with code like:
@@ -32,7 +42,7 @@ moment().format("MMMM Do YYYY, h:mm:ss a");
 
 The `moment` import would be fully typed.
 
-When you have this option set, by not including a module in the `types` array it:
+When a package is not included through the `types` array, it:
 
 - Will not add globals to your project (e.g `process` in node, or `expect` in Jest)
 - Will not have exports appear as auto-import recommendations