chore: sync project template changes

Signed-off-by: Lexus Drumgold <unicornware@flexdevelopment.llc>

Author: unicornware

.github/PULL_REQUEST_TEMPLATE.md

@@ -35,5 +35,4 @@ A list of linked issues and/or pull requests.
 - [ ] new, **tolerable** vulnerabilities and/or warnings documented, if any
 - [ ] [pr naming conventions][1]
 
-[1]:
-    https://github.com/flex-development/aggregate-error-ponyfill/blob/main/CONTRIBUTING.md#pull-request-titles
+[1]: https://github.com/flex-development/aggregate-error-ponyfill/blob/main/CONTRIBUTING.md#pull-request-titles

.vscode/settings.json

@@ -116,7 +116,8 @@
     "json",
     "jsonc",
     "markdown",
-    "typescript"
+    "typescript",
+    "yaml"
   ],
   "files.associations": {
     "*.snap": "jest-snapshot",
@@ -136,12 +137,7 @@
   "markdown.extension.toc.slugifyMode": "github",
   "markdown.extension.toc.updateOnSave": false,
   "npm-intellisense.scanDevDependencies": true,
-  "prettier.configPath": "./.prettierrc.json",
-  "prettier.enable": true,
-  "prettier.ignorePath": "./.prettierignore",
-  "prettier.prettierPath": "./node_modules/prettier",
-  "prettier.resolveGlobalModules": false,
-  "prettier.useEditorConfig": true,
+  "prettier.enable": false,
   "shellformat.flag": "-ci -fn -i=2 -sr",
   "typescript.suggest.completeFunctionCalls": true,
   "typescript.suggest.completeJSDocs": true,
@@ -158,6 +154,11 @@
       "format": "svg",
       "icon": "graphql"
     },
+    {
+      "extensions": ["build.json"],
+      "format": "svg",
+      "icon": "tsconfig"
+    },
     {
       "extensions": ["snap"],
       "format": "svg",
@@ -180,6 +181,11 @@
       "format": "svg",
       "icon": "temp"
     },
+    {
+      "extensions": ["patches"],
+      "format": "svg",
+      "icon": "include"
+    },
     {
       "extensions": ["setup"],
       "format": "svg",

CONTRIBUTING.md

@@ -1,7 +1,8 @@
 # Contributing Guide
 
-This document aims to describe the workflows and rules used for developing this
-project. This includes, but is not limited to:
+This document aims to describe the workflows and rules used for developing this project.
+
+This includes, but is not limited to:
 
 - how to contribute code (coding standards, testing, documenting source code)
 - how pull requests are handled
@@ -47,12 +48,10 @@ Follow the steps below to setup your local development environment:
    yarn
    ```
 
-   **Note**: This project uses [Yarn 2][3]. Consult [`.yarnrc.yml`](.yarnrc.yml)
-   for an overview of configuration options and required environment variables.
-   Furthermore, if you already have a global Yarn configuration, or any `YARN_*`
-   environment variables set, an error will be thrown if any settings conflict
-   with the project's Yarn configuration, or the Yarn 2 API. Missing environment
-   variables will also yield an error.
+   **Note**: This project uses [Yarn 2][3]. Consult [`.yarnrc.yml`](.yarnrc.yml) for an overview of configuration
+   options and required environment variables. Furthermore, if you already have a global Yarn configuration, or any
+   `YARN_*` environment variables set, an error will be thrown if any settings conflict with the project's Yarn
+   configuration, or the Yarn 2 API. Missing environment variables will also yield an error.
 
 7. [ZSH][4] setup
 
@@ -115,11 +114,9 @@ See [`.github/.gitconfig`](.github/.gitconfig) for an exhaustive list.
 
 ## Contributing Code
 
-[Husky][5] is used to locally enforce coding and commit message standards, as
-well as run tests pre-push.
+[Husky][5] is used to locally enforce coding and commit message standards, as well as run tests pre-push.
 
-Any code merged into the [trunk](#branching-model) must confront the following
-criteria:
+Any code merged into the [trunk](#branching-model) must confront the following criteria:
 
 - changes should be discussed prior to implementation
 - changes have been tested properly
@@ -128,8 +125,7 @@ criteria:
 
 ### Branching Model
 
-This project follows a [Trunk Based Development][6] workflow, specifically the
-[short-lived branch style][7].
+This project follows a [Trunk Based Development][6] workflow, specifically the [short-lived branch style][7].
 
 - Trunk Branch: `main`
 - Short-Lived Branches: `feat/*`, `hotfix/*`, `release/*`
@@ -152,8 +148,7 @@ When creating a new branch, the name should match the following format:
 
 ### Commit Messages
 
-This project follows [Conventional Commit][8] standards and uses [commitlint][9]
-to enforce those standards.
+This project follows [Conventional Commit][8] standards and uses [commitlint][9] to enforce those standards.
 
 This means every commit must conform to the following format:
 
@@ -221,8 +216,7 @@ Source code is located in [`src`](src) directory.
 
 - JavaScript & TypeScript: [JSDoc][12]; linted with [`eslint-plugin-jsdoc`][13]
 
-Before making a pull request, be sure your code is well documented, as it will
-be part of your code review.
+Before making a pull request, be sure your code is well documented, as it will be part of your code review.
 
 ### Testing
 
@@ -240,15 +234,14 @@ Be sure to use [`it.skip`][15] or [`it.todo`][16] where appropriate.
 
 ### Getting Help
 
-If you need help, make note of any issues in their respective files in the form
-of a [JSDoc comment][12]. If you need help with a test, don't forget to use
-[`it.skip`][15] and/or [`it.todo`][16]. Afterwards, [start a discussion in the
+If you need help, make note of any issues in their respective files in the form of a [JSDoc comment][12]. If you need
+help with a test, don't forget to use [`it.skip`][15] and/or [`it.todo`][16]. Afterwards, [start a discussion in the
 Q&A category][17].
 
 ## Labels
 
-This project uses a well-defined list of labels to organize issues and pull
-requests. Most labels are scoped (i.e: `status:`).
+This project uses a well-defined list of labels to organize issues and pull requests. Most labels are scoped (i.e:
+`status:`).
 
 A list of labels can be found in [`.github/labels.yml`](.github/labels.yml).
 
@@ -260,8 +253,7 @@ Before opening an issue, make sure you have:
 - checked that the issue hasn't already been filed by searching open issues
 - searched closed issues for solution(s) or feedback
 
-If you haven't found a related open issue, or feel that a closed issue should be
-re-visited, open a new issue.
+If you haven't found a related open issue, or feel that a closed issue should be re-visited, open a new issue.
 
 A well-written issue
 
@@ -272,8 +264,7 @@ A well-written issue
 
 ## Pull Requests
 
-When you're ready to submit your changes, open a pull request (PR) against
-`main`:
+When you're ready to submit your changes, open a pull request (PR) against `main`:
 
 ```sh
 https://github.com/flex-development/aggregate-error-ponyfill/compare/main...$branch
@@ -296,13 +287,12 @@ Every PR you open should:
 
 ### Pull Request Titles
 
-To keep in line with [commit message standards](#commit-messages) after PRs are
-merged, PR titles are expected to adhere to the same rules.
+To keep in line with [commit message standards](#commit-messages) after PRs are merged, PR titles are expected to adhere
+to the same rules.
 
 ## Merge Strategies
 
-In every repository, the `rebase and merge` and `squash and merge` options are
-enabled.
+In every repository, the `rebase and merge` and `squash and merge` options are enabled.
 
 - **rebase and merge**: PR has one commit or commits that are not grouped
 - **squash and merge**: PR has one commit or a group of commits
@@ -333,8 +323,7 @@ e.g:
 ## Deployment
 
 > Note: Package and release publication is executed via GitHub workflow.\
-> This is so invalid or malicious versions cannot be published without merging those
-> changes into `main` first.
+> This is so invalid or malicious versions cannot be published without merging those changes into `main` first.
 
 Before deploying, the following steps must be completed:
 
@@ -366,8 +355,7 @@ Before deploying, the following steps must be completed:
        - create and publish github release
        - make sure all prereleased or released issues are closed
        - delete the release branch
-     - on release publish, [publish workflow](.github/workflows/publish.yml)
-       will fire
+     - on release publish, [publish workflow](.github/workflows/publish.yml) will fire
        - if successful, the workflow will:
          - publish package to [github package registry][19]
          - publish package to [npm][20]

__tests__/interfaces/vi-assertion-result.ts

@@ -3,7 +3,7 @@
  * @module tests/interfaces/AssertionResult
  */
 
-import type { OrNull } from '@flex-development/tutils'
+import type { Nullable } from '@flex-development/tutils'
 
 /**
  * Test assertion summary object produced by the `vitest` [`JsonReporter`][1].
@@ -12,7 +12,7 @@ import type { OrNull } from '@flex-development/tutils'
  */
 interface AssertionResult {
   ancestorTitles: string[]
-  duration?: OrNull<number>
+  duration?: Nullable<number>
   failureMessages: string[]
   fullName: string
   status: 'disabled' | 'failed' | 'passed' | 'pending' | 'skipped' | 'todo'

build.config.ts

@@ -1,7 +1,7 @@
 /**
  * @file Build Config
  * @module config/build
- * @see https://github.com/flex-development/mkbuild#configuration
+ * @see https://github.com/flex-development/mkbuild
  */
 
 import { defineBuildConfig, type Config } from '@flex-development/mkbuild'

tsconfig.build.json

@@ -1,6 +1,5 @@
 {
   "compilerOptions": {
-    "isolatedModules": true,
     "noEmitOnError": true,
     "skipLibCheck": false,
     "target": "es2020"

tsconfig.json

@@ -13,7 +13,7 @@
     "experimentalDecorators": true,
     "forceConsistentCasingInFileNames": true,
     "importsNotUsedAsValues": "error",
-    "isolatedModules": false,
+    "isolatedModules": true,
     "lib": ["es2020"],
     "module": "esnext",
     "moduleDetection": "force",