yippee

Author: leeyi45

.github/workflows/pull-request.yml

@@ -83,6 +83,9 @@ jobs:
           if: needs.paths-filter.outputs.libraries == 'true'
           run: yarn workspaces foreach -ptW --from "./lib/*" run tsc
 
+        - name: Run build for libraries
+          run: yarn workspaces foreach -ptW --from "./lib/*" run build
+
         - name: Run test for libraries
           if: needs.paths-filter.outputs.libraries == 'true'
           run: yarn test:libs

docs/src/buildtools/3-structure.md

@@ -1,17 +1,17 @@
 # General Design of the Build Tools
 
 ## Path Resolution
-The build tools are designed to be written in Typescript, then compiled and bundled by `esbuild` into a single minified Javascript file `bin/index.js`. This means relative paths used during runtime need to be written in such a way that they account for the path of the executable file.
+The build tools are designed to be written in Typescript, then compiled and bundled by `esbuild` into a single minified Javascript file `dist/index.js`. This means relative paths used during runtime need to be written in such a way that they account for the path of the executable file.
 
-For example, the template script needs to copy the templates from the `bin/templates` folder. So the call to `fs.cp` is written relative to `import.meta.dirname` instead of
+For example, the template script needs to copy the templates from the `dist/templates` folder. So the call to `fs.cp` is written relative to `import.meta.dirname` instead of
 hardcoding a relative path:
 
 ```ts
 // lib/buildtools/src/templates/bundle.ts
 await fs.cp(`${import.meta.dirname}/templates/bundle`, bundleDestination, { recursive: true });
 ```
 
-When `bin/index.js` is executed, `import.meta.dirname` refers to `lib/buildtools/bin`, so the above path becomes `lib/buildtools/bin/templates/bundle`, which is the actual location of where the template files are located.
+When `dist/index.js` is executed, `import.meta.dirname` refers to `lib/buildtools/dist`, so the above path becomes `lib/buildtools/dist/templates/bundle`, which is the actual location of where the template files are located.
 
 On the other hand, relative module imports that are bundled during the compilation process don't need to be changed. The template script imports the root package json to
 determine the versions of dependencies to use:
@@ -25,7 +25,7 @@ const { dependencies: { typescript: typescriptVersion } } = _package
 ```
 
 Although the resolved module path refers to a path outside of the buildtools folder, during compilation, `esbuild` actually
-embeds the entire JSON file into `bin/index.js`, thus removing the import altogether:
+embeds the entire JSON file into `dist/index.js`, thus removing the import altogether:
 
 ```ts
 // ../../package.json
@@ -68,14 +68,6 @@ function rawGetGitRoot() {
 ```
 This is guaranteed to work, since the user should have Git present on their system (otherwise how did they get this git repo?)
 
-Since the path of the git repository shouldn't be changing during execution of the buildtools, we use `lodash`'s [`memoize`](https://lodash.com/docs/4.17.15#memoize) to eliminate unnecessary calls to Git:
-```ts
-/**
- * Get the path to the root of the git repository
- */
-export const getGitRoot = memoize(rawGetGitRoot);
-```
-
 By abstracting this functionality into a separate module, it is simple to change the paths at which everything is defined (such as where the directory containing bundles is found). In particular,
 by mocking this module, we can run the buildtools on mock bundles and tabs with ease.
 

docs/src/repotools/index.md

@@ -1,5 +1,8 @@
 # Repository Development Tools
 
+The `@sourceacademy/modules-repotools` package itself has a bunch of utilities for working with the repository.
+
+Below is a list of other tools:
 - [Development Server](./devserver/devserver)
 - [Docs Server](./docserver/1-overview)
 - [ESLint](./linting)