Finally got linting code blocks in markdown files to work

Author: leeyi45

docs/src/buildtools/3-structure.md

@@ -22,7 +22,7 @@ determine the versions of dependencies to use:
 import _package from '../../../../package.json' with { type: 'json' };
 
 // extract typescript version
-const { dependencies: { typescript: typescriptVersion } } = _package
+const { dependencies: { typescript: typescriptVersion } } = _package;
 ```
 
 Although the resolved module path refers to a path outside of the buildtools folder, during compilation, `esbuild` actually

docs/src/buildtools/5-builders/1-modules.md

@@ -35,7 +35,7 @@ var globalName = (() => {
     draw_connected_2d,
     make_point,
     // etc...
-  }
+  };
 })();
 ```
 
@@ -59,23 +59,23 @@ By default, `esbuild`'s IIFE output doesn't return its exports:
 
 ```js
 (function() {
-  var exports = {}
+  var exports = {};
   exports.add_one = function(x) {
     return x + 1;
-  }
-})()
+  };
+})();
 ```
 
 By specifying a  `globalName`, the generated code instead becomes:
 
 ```js
 var module = (function() {
-  var exports = {}
+  var exports = {};
   exports.add_one = function(x) {
     return x + 1;
-  }
+  };
   return exports;
-})()
+})();
 ```
 
 It is then possible to extract the inner IIFE and use it to retrieve the exports.
@@ -102,26 +102,26 @@ After esbuild bundling, both bundles and tabs are parsed using [`acorn`](https:/
 
 ```js
 var module = (function() {
-  var exports = {}
+  var exports = {};
   exports.add_one = function(x) {
     return x + 1;
-  }
+  };
 
   return exports;
-})()
+})();
 ```
 
 The AST is then transformed by the `outputBundleOrTab` function, which produces output that looks like this:
 
 ```js
 export default require => {
-  var exports = {}
+  var exports = {};
   exports.add_one = function(x) {
     return x + 1;
-  }
+  };
 
   return exports;
-}
+};
 ```
 
 This is what is finally written to the output folders.

docs/src/buildtools/8-testing.md

@@ -19,7 +19,7 @@ export default defineConfig({
   test: {
     projects: ['./sub-project/vitest.config.js']
   }
-})
+});
 ```
 
 For the child configuration:
@@ -35,7 +35,7 @@ export default mergeConfig(
       name: 'Child Project'
     }
   })
-)
+);
 ```
 
 The actual configuration that's actually resolved by `vitest` actually looks like this:
@@ -46,7 +46,7 @@ const config = {
     name: 'Child Project',
     projects: ['./sub-project/vitest.config.js']
   }
-}
+};
 ```
 
 So if you ran `yarn vitest --config ./sub-project/vitest.config.js`, `vitest` would try to locate another `vitest` project
@@ -125,12 +125,12 @@ const fullViteConfig = {
   test: {
     name: 'Tests'
   }
-}
+};
 
 // Pass this to startVitest instead
 const vitestConfig = {
   name: 'Tests'
-}
+};
 ```
 
 You should also pass `config: false`. Otherwise, `vitest` will still try to load a `vitest` configuration file
@@ -140,7 +140,7 @@ using its own resolution rules:
 startVitest('test', [], {
   config: false,
   ...testOptions
-})
+});
 ```
 
 When running tests, you need to actually provide each configuration object as a project:
@@ -149,7 +149,7 @@ When running tests, you need to actually provide each configuration object as a
 startVitest('test', [], {
   config: false,
   projects: [yourTestConfig]
-})
+});
 ```
 
 ## Browser Mode

docs/src/lib/lintplugin/2-rules.md

@@ -14,7 +14,7 @@ The rule has a configuration option, which is just an object whose keys represen
 ```ts
 type RuleOptions = {
   [source: string]: string | string[]
-}
+};
 ```
 
 ### Specifying a Single Name
@@ -33,7 +33,7 @@ import * as path from 'path';
 // with the option set to { path: 'pathlib' }
 import pathlib from 'path';
 import * as pathlib from 'path';
-import fs from 'fs/promises' // This is ignored because it wasn't specified in the options
+import fs from 'fs/promises'; // This is ignored because it wasn't specified in the options
 ```
 
 ### Specifying Multiple Names
@@ -55,7 +55,7 @@ You can of course, enforce naming for more than one import source:
 // with option: { path: 'pathlib', 'fs/promises': 'fs' }
 
 import fs from 'fs/promises';
-import path from 'pathlib'
+import path from 'pathlib';
 
 // both import statements will be validated!
 ```
@@ -69,14 +69,14 @@ through the main export, but also make each function available in a separate pac
 
 ```ts
 // Imports from the root package
-import _ from 'lodash'
-_.memoize(func)
+import _ from 'lodash';
+_.memoize(func);
 
-import { memoize } from 'lodash'
-memoize(func)
+import { memoize } from 'lodash';
+memoize(func);
 // vs importing from a "sub-package"
-import memoize 'lodash/memoize'
-memoize(func)
+import memoize from 'lodash/memoize';
+memoize(func);
 ```
 
 The reason for these "per method imports" is to help bundlers more effectively tree-shake and thus more effectively reduce final bundle size.
@@ -89,45 +89,45 @@ The exception to this is Typescript "type-only" imports, since those automatical
 
 ```ts
 // Are perfectly ok
-import type _ from 'lodash'
-import type { memoize } from 'lodash'
+import type _ from 'lodash';
+import type { memoize } from 'lodash';
 ```
 
 ### Fixes
 
 The rule replaces the original import with different import statements from each of the subpackages:
 
 ```ts
-import { memoize } from 'lodash'
+import { memoize } from 'lodash';
 // gets autofixed to
-import memoize from 'lodash/memoize'
+import memoize from 'lodash/memoize';
 ```
 
 If you aliased the import, the appropriate alias name will be used:
 
 ```ts
-import { memoize as func } from 'lodash'
+import { memoize as func } from 'lodash';
 // gets autofixed to
-import func from 'lodash/memoize'
+import func from 'lodash/memoize';
 ```
 
 Multiple imports from the root package get transformed like this:
 
 ```ts
-import { memoize as func, cloneDeep } from 'lodash'
+import { memoize as func, cloneDeep } from 'lodash';
 // gets autofixed to
-import func from 'lodash/memoize'
-import cloneDeep from 'lodash/cloneDeep'
-import cloneDeep from 'lodash/cloneDeep'
+import func from 'lodash/memoize';
+import cloneDeep from 'lodash/cloneDeep';
+import cloneDeep from 'lodash/cloneDeep';
 ```
 
 Type-only imports, when mixed with default imports, also get autofixed:
 
 ```ts
-import { type memoize as func, cloneDeep } from 'lodash'
+import { type memoize as func, cloneDeep } from 'lodash';
 // gets autofixed to
-import type func from 'lodash/memoize'
-import cloneDeep from 'lodash/cloneDeep'
+import type func from 'lodash/memoize';
+import cloneDeep from 'lodash/cloneDeep';
 ```
 
 > [!WARNING]
@@ -138,10 +138,12 @@ import cloneDeep from 'lodash/cloneDeep'
 
 The rule should be configured with an array of package names to check:
 
-```ts
-rules: {
-  '@sourceacademy/no-barrel-imports': ['error', ['lodash']]
-}
+```js
+const config = {
+  rules: {
+    '@sourceacademy/no-barrel-imports': ['error', ['lodash']]
+  }
+};
 ```
 
 ### ✅ Examples of **correct** code for this rule
@@ -150,8 +152,8 @@ rules: {
 // with @sourceacademy/no-barrel-imports: ['error', ['lodash']]
 
 // Lone default or namespace imports are ok
-import _ from 'lodash'
-import * as _ from 'lodash'
+import _ from 'lodash';
+import * as _ from 'lodash';
 
 // Type-only imports are okay
 import type _ from 'lodash';
@@ -164,7 +166,7 @@ import type { memoize } from 'lodash';
 // with @sourceacademy/no-barrel-imports: ['error', ['lodash']]
 
 // Regular Import
-import { memoize } from 'lodash'
+import { memoize } from 'lodash';
 
 // Default import mixed with type imports
 import _, { type memoize } from 'lodash';
@@ -219,7 +221,7 @@ export default {
   toSpawn: () => false,
   iconName: 'icon',
   label: 'tab'
-}
+};
 ```
 
 Examples of **correct** code for this rule:
@@ -256,9 +258,8 @@ This rule accepts a configuration array with two elements:
 - The second option is the name of the imported helper. This is by default `defineTab`.
 
 ✅ Examples of **correct** code using these options:
-
+If the rule was configured with `['error', '@sourceacademy/modules-lib/tabs/utils', 'tabHelper']`:
 ```tsx
-/* eslint @sourceacademy/tab-type: ['error', '@sourceacademy/modules-lib/tabs/utils', 'tabHelper'] */
 import { tabHelper } from '@sourceacademy/modules-lib/tabs/utils';
 
 export default tabHelper({

docs/src/modules/1-getting-started/5-faq.md

@@ -33,7 +33,7 @@ A `tab` on the other hand is more formally defined as an _optional_ user interfa
 An example of an implementation of this is from the `pix_n_flix` module. The implementation can be found [here](https://github.com/source-academy/modules/blob/master/src/bundles/pix_n_flix/index.ts). In the module, a function `init()` is provided to the Source programmer. The specifications of the `pix_n_flix` module requires this `init()` function to be applied as the last statement of the Source program. As a result, the `js-slang` evaluator will return the return value of the `init()` function which is a JavaScript object with the type signature shown below.
 
 ```ts
-{
+interface InitReturnValue {
   toReplString: () => string;
   init: (video: HTMLVideoElement, canvas: HTMLCanvasElement, _errorLogger: () => void) => {};
 }

docs/src/modules/2-bundle/1-overview.md

@@ -78,8 +78,8 @@ However, only `make_point` is exported at the bundle's entry point however `crea
 
 ```js
 // User's Source program
-import { make_point } from 'curve' // No Error
-import { createDrawFunction } from 'curve' // Will throw an error
+import { make_point } from 'curve'; // No Error
+import { createDrawFunction } from 'curve'; // Will throw an error
 ```
 
 ::: details An aside about exports

docs/src/modules/2-bundle/4-conventions/1-basic.md

@@ -13,7 +13,7 @@ function configure_options(option_1: boolean, option_2: boolean = false) {
 
 // or this
 function concat_strings(...args: string[]) {
-  return args.join(',')
+  return args.join(',');
 }
 
 // But default and rest parameters are okay for internal use

docs/src/modules/2-bundle/4-conventions/2-abstractions.md

@@ -49,7 +49,7 @@ curve => {
     drawnCurves.push(curveDrawn);
   }
   return curveDrawn;
-}
+};
 ```
 
 This exposes implementation details to the cadet and "breaks" the `RenderFunction` abstraction. Thus, there is a need for such objects to be able to override the default `toString`
@@ -79,6 +79,7 @@ but if your circumstances can't support it you can refer to the second method wh
 >
 > ```ts
 > import { show } from 'rune';
+> 
 > display(show);
 > ```
 >
@@ -127,7 +128,7 @@ Referring back to the `curve` bundle's `RenderFunction`s, the type `RenderFuncti
 type RenderFunction = {
   (func: Curve): CurveDrawn
   is3D: boolean
-}
+};
 
 // Equivalent to
 // type RenderFunction = ((func: Curve) => CurveDraw) & { is3D: boolean }
@@ -183,6 +184,7 @@ We've seen the result of the default `toString` implementation. By providing `to
 
 ```js
 import { draw_connected } from 'curve';
+
 display(draw_connected(200));
 
 // Produces the output below
@@ -201,8 +203,8 @@ provide compile time validation that the property has been set correctly.
 There may be cases where you intend for your abstraction to be "decomposable" by cadets. The `Sound` type is just a wrapper around a `js-slang` pair:
 
 ```ts
-type Wave = (t: number) => number
-type Sound = Pair<Wave, number>
+type Wave = (t: number) => number;
+type Sound = Pair<Wave, number>;
 ```
 
 For both of these types, the default `toString` behaviour closely follows their definitions:
@@ -231,7 +233,7 @@ interface TextOptions {
   color: string
   size: number
 }
-export function change_text_options(options: TextOptions): void
+export function change_text_options(options: TextOptions): void;
 ```
 
 Alternatively, you could do something like this:
@@ -241,8 +243,8 @@ interface TextOptions {
   color: string
   size: number
 }
-export function create_text_options(color: string, size: number): TextOptions
-export function change_text_options(options: TextOptions): void
+export function create_text_options(color: string, size: number): TextOptions;
+export function change_text_options(options: TextOptions): void;
 
 // Used like this:
 const options = create_text_options('blue', 20);