chore(build/compiler): Enable a bunch of strict TS compiler options. (#6138)

GEMINI.md

@@ -97,17 +97,17 @@ TypeScript's power lies in its ability to provide static type checking, catching
 
 - **Preferring `unknown` over `any`**: When you absolutely cannot determine the type of a value at compile time, and you're tempted to reach for any, consider using unknown instead. unknown is a type-safe counterpart to any. While a variable of type unknown can hold any value, you must perform type narrowing (e.g., using typeof or instanceof checks, or a type assertion) before you can perform any operations on it. This forces you to handle the unknown type explicitly, preventing accidental runtime errors.
 
-  ```
+  ```ts
   function processValue(value: unknown) {
-     if (typeof value === 'string') {
-        // value is now safely a string
-        console.log(value.toUpperCase());
-     } else if (typeof value === 'number') {
-        // value is now safely a number
-        console.log(value * 2);
-     }
-     // Without narrowing, you cannot access properties or methods on 'value'
-     // console.log(value.someProperty); // Error: Object is of type 'unknown'.
+    if (typeof value === 'string') {
+      // value is now safely a string
+      console.log(value.toUpperCase());
+    } else if (typeof value === 'number') {
+      // value is now safely a number
+      console.log(value * 2);
+    }
+    // Without narrowing, you cannot access properties or methods on 'value'
+    // console.log(value.someProperty); // Error: Object is of type 'unknown'.
   }
   ```
 
@@ -115,6 +115,27 @@ TypeScript's power lies in its ability to provide static type checking, catching
   - **Bypassing Type Checking**: Like `any`, type assertions bypass TypeScript's safety checks. If your assertion is incorrect, you introduce a runtime error that TypeScript would not have warned you about.
   - **Code Smell in Testing**: A common scenario where `any` or type assertions might be tempting is when trying to test "private" implementation details (e.g., spying on or stubbing an unexported function within a module). This is a strong indication of a "code smell" in your testing strategy and potentially your code structure. Instead of trying to force access to private internals, consider whether those internal details should be refactored into a separate module with a well-defined public API. This makes them inherently testable without compromising encapsulation.
 
+### Type narrowing `switch` clauses
+
+When authoring a switch clause over an enumeration or fixed list of items,
+always prefer to use the `checkExhaustive` helper method within the default
+clause of the switch. This will ensure that all of the possible options within
+the value or enumeration are used.
+
+This helper method can be found in `packages/cli/src/utils/checks.ts`
+
+Here's an example of using the helper method properly:
+
+```
+switch (someValue) {
+  case 1:
+  case 2:
+    // ...
+  default:
+    return checkExhaustive(someValue);
+}
+```
+
 ### Embracing JavaScript's Array Operators
 
 To further enhance code cleanliness and promote safe functional programming practices, leverage JavaScript's rich set of array operators as much as possible. Methods like `.map()`, `.filter()`, `.reduce()`, `.slice()`, `.sort()`, and others are incredibly powerful for transforming and manipulating data collections in an immutable and declarative way.