diff --git a/docs/advanced/language-extensions.md b/docs/advanced/language-extensions.md
index d6fd45ff..30ac654e 100644
--- a/docs/advanced/language-extensions.md
+++ b/docs/advanced/language-extensions.md
@@ -1,5 +1,5 @@
---
-title: Language extensions
+title: Language Extensions
---
import { SideBySide } from "@site/src/components/SideBySide";
diff --git a/docs/caveats.md b/docs/caveats.md
index 1014d3da..f0339bdc 100644
--- a/docs/caveats.md
+++ b/docs/caveats.md
@@ -43,6 +43,8 @@ JavaScript and Lua differ in what they evaluate to true/false. TypeScriptToLua a
TypeScriptToLua makes no difference between `==` and `===` when compiling to Lua, treating all comparisons as strict (`===`).
+We recommend that all TypeScriptToLua projects use the [eqeqeq](https://eslint.org/docs/rules/eqeqeq) and [@typescript-eslint/strict-boolean-expressions](https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/eslint-plugin/docs/rules/strict-boolean-expressions.md) ESLint rules. (Setting up ESLint is outside the scope of this section. It is generally a good idea to turn these rules on for _any_ TypeScript project.)
+
### Array Length
`Array.prototype.length` is translated to Lua's `#` operator. Due to the way lists are implemented in Lua there can be differences between JavaScript's `list.length` and Lua's `#list`. The transpiler does not do anything to remedy these differences, so when working with lists, the transpiled Lua will use the standard Lua conventions. Generally speaking, the situation where these differences occur happen when adding/removing items to a list in a hacky way, or when setting list items to `undefined`/`null`.
diff --git a/docs/configuration.md b/docs/configuration.md
index 9b377cd6..f31b2266 100644
--- a/docs/configuration.md
+++ b/docs/configuration.md
@@ -27,16 +27,17 @@ You can use our [VS Code extension](editor-support.md) or manually specify the J
| -------------------- | -------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `buildMode` | `"default"`, `"library"` (default: `"library"`) | Use `buildMode: "library"` to build [publishable library packages](publishing-modules.md). |
| `extension` | File extension (default: `".lua"`) | Extension of emitted lua files. |
-| `luaTarget` | `"JIT"`, `"5.3"`, `"5.2"`, `"5.1"`, `"universal"` (default: `"universal"`) | Specifies the Lua version you want to generate code for. Choosing `universal` makes TypeScriptToLua generate code compatible with all supported Lua targets. |
-| `noImplicitSelf` | `true`, `false` (default: `false`) | If true, treats all project files as if they were prefixed with
`/** @noSelfInFile **/`. |
-| `noHeader` | `true`, `false` (default: `false`) | Set this to true if you don't want to include our header in the output. |
-| `luaLibImport` | `"inline"`, `"require"`, `"none"` (default: `"require"`) | We polyfill certain JavaScript features with Lua functions, this option specifies how these functions are imported into the Lua output. `"inline"`: Inline used functions in code; `"require"`: Require full lualib bundle if used in file. `"none"`: Never require/inline any lualib features. |
-| `sourceMapTraceback` | `true`, `false` (default: `false`) | Overrides Lua's `debug.traceback` to apply sourcemaps to Lua stacktraces. This will make error messages point to your original TypeScript code instead of the generated Lua. |
| `luaBundle` | File path (relative to the `tsconfig.json`) | Will bundle all output lua files into a single bundle file. Requires **luaBundleEntry** to be set! |
| `luaBundleEntry` | File path (relative to the `tsconfig.json`) | This should be the name/path of the TS file in your project that will serve as entry point to the bundled code. |
+| `luaLibImport` | `"inline"`, `"require"`, `"none"` (default: `"require"`) | We polyfill certain JavaScript features with Lua functions, this option specifies how these functions are imported into the Lua output. `"inline"`: Inline used functions in code; `"require"`: Require full lualib bundle if used in file. `"none"`: Never require/inline any lualib features. |
| `luaPlugins` | `Array<{ name: string; import?: string }>` | List of [TypeScriptToLua plugins](api/plugins.md). |
-| `tstlVerbose` | `true`, `false` (default: `false`) | Output additional logging when performing a tstl build, to help diagnose issues. |
+| `luaTarget` | `"JIT"`, `"5.3"`, `"5.2"`, `"5.1"`, `"universal"` (default: `"universal"`) | Specifies the Lua version you want to generate code for. Choosing `universal` makes TypeScriptToLua generate code compatible with all supported Lua targets. |
+| `noHeader` | `true`, `false` (default: `false`) | Set this to true if you don't want to include our header in the output. |
+| `noImplicitGlobals` | `true`, `false` (default: `false`) | By default, if a file contains no imports or exports, then tstl will convert all variables in it to global variables. Set this to true to ensure that global variables are only ever created when you explicitly want to. It is recommended that all users set this option to true. |
+| `noImplicitSelf` | `true`, `false` (default: `false`) | If true, treats all project files as if they were prefixed with
`/** @noSelfInFile **/`. |
| `noResolvePaths` | `Array` | An array of require paths that will **NOT** be resolved. For example `["require1", "sub.require2"]` will stop tstl from trying to resolve Lua sources for `require("require1")` and `require("sub.require2")`. |
+| `sourceMapTraceback` | `true`, `false` (default: `false`) | Overrides Lua's `debug.traceback` to apply sourcemaps to Lua stacktraces. This will make error messages point to your original TypeScript code instead of the generated Lua. |
+| `tstlVerbose` | `true`, `false` (default: `false`) | Output additional logging when performing a tstl build, to help diagnose issues. (This cannot be called "verbose", since that is already taken by the TypeScript compiler.) |
## Standard options