Linter fixes

Author: MajorLift

docs/typescript.md

@@ -120,6 +120,7 @@ Type assertions make the code brittle against changes. While TypeScript will thr
 ##### To prevent or fix `any` usage
 
 Unsafe as type assertions may be, they are still categorically preferable to using `any`.
+
 - With type assertions, we still get working intellisense, autocomplete, and other IDE features.
 - Type assertions also provide an indication of the expected type as intended by the author.
 - For type assertions to an incompatible shape, use `as unknown as` as a last resort rather than `any` or `as any`.
@@ -131,6 +132,7 @@ Unsafe as type assertions may be, they are still categorically preferable to usi
 ##### To type data objects whose shape and contents are determined at runtime
 
 Preferably, this typing should be accompanied by schema validation performed with type guards and unit tests.
+
 - e.g. The output of `JSON.parse()` or `await response.json()` for a known JSON input.
 - e.g. The type of a JSON file.
 
@@ -139,6 +141,7 @@ Preferably, this typing should be accompanied by schema validation performed wit
 ##### In tests, for mocking or to exclude irrelevant but required properties from an input object
 
 <!-- TODO: Add examples -->
+
 It's recommended to provide accurate typing if there's any chance that omitting properties affects the accuracy of the test.
 
 Otherwise, only mocking the properties needed in the test improves readability by making the intention and scope of the mocking clear, not to mention being convenient to write.