Imropve copilot and AI prompts

Author: binarykitchen

.github/copilot-instructions.md

@@ -1,6 +1,6 @@
 # Project Overview
 
-This public project, called videomail-client, is a web-based npm package for reuse in any other web applications and also in a separate WordPress plugin, see [videomail-for-ninja-forms](https://github.com/binarykitchen/videomail-for-ninja-forms).
+This public project, called videomail-client, is a web-based npm package for reuse in any other web applications and also in a separate WordPress plugin, see (videomail-for-ninja-forms)[https://github.com/binarykitchen/videomail-for-ninja-forms].
 
 The most important consumer of this package is (Videomail)[https://www.videomail.io] itself which heavily relies on this package and resides in another, but private repository. Videomail's goal is to enable Sign Language in emails. Deaf users are our main audience.
 
@@ -22,7 +22,7 @@ The root `/README.md` file has further general information for you, the GitHub C
 
 - All runs on Node.js, the used version is defined in the `.nvmrc` file. Presently it's v22
 - We do not use React nor any frameworks. All is raw, in Vanilla JavaScript.
-- For video recording, we grab images with the deprecated getUserMedia API, send them through WebSocket streams, using the [websocket-stream package](https://www.npmjs.com/package/websocket-stream) and once the user presses the stop button, the server side which is [Videomail](https://www.videomail.io) itself, compiles these image frames into a video and sends them out within an email. That's the big idea.
+- For video recording, we grab images with the deprecated getUserMedia API, send them through WebSocket streams, using the (websocket-stream package)[https://www.npmjs.com/package/websocket-stream] and once the user presses the stop button, the server side which is (Videomail)[https://www.videomail.io] itself, compiles these image frames into a video and sends them out within an email. That's the big idea.
 - We are aware that the getUserMedia API is deprecated, but we have no time to migrate this to the new MediaDevices API. All still works well, so we can ignore this for now.
 - Most source code is written in TypeScript.
 - Security checks using the audit-ci package are included and configured. Security is important.
@@ -31,7 +31,7 @@ The root `/README.md` file has further general information for you, the GitHub C
 
 ## Browsers and mobile devices
 
-The bare minimum is to support those browsers who support the getUserMedia API. Not the older ones. To check if a browser supports this API, you can use the [caniuse.com](https://caniuse.com/?search=getUserMedia) website.
+The bare minimum is to support those browsers who support the getUserMedia API. Not the older ones. To check if a browser supports this API, you can use the (caniuse.com)[https://caniuse.com/?search=getUserMedia] website.
 
 Regarding network issues, we already have mechanisms in place to lower the FPS before encoding these videos on the Videomail server side.
 
@@ -69,15 +69,15 @@ But here are the default specs for the main Videomail website itself:
 
 ### Unit Tests
 
-- For unit tests we use the next generation [Vitest](https://vitest.dev/) framework.
+- For unit tests we use the next generation (Vitest)[https://vitest.dev] framework.
 - Vitest was chosen because it is fast, has a great API and is compatible with other testing frameworks like Jest.
 - The unit tests are located in the `__tests__` subdirectory of each source code
 
 ### Visual Tests
 
-For visual tests, we use [Storybook](https://storybook.js.org/). It is configured in the `.storybook` folder. The Storybook is used to visually test components and their states.
+For visual tests, we use (Storybook)[https://storybook.js.org]. It is configured in the `.storybook` folder. The Storybook is used to visually test components and their states.
 
-In addition, we also use [Chromatic](https://www.chromatic.com/) to catch any visual differences between git commits.
+In addition, we also use (Chromatic)[https://www.chromatic.com] to catch any visual differences between git commits.
 
 ## Accessibility
 

.github/prompts/generate-unit-tests-for-selected-file.prompt.md

@@ -10,12 +10,19 @@ When generating unit tests, please follow these guidelines:
 
 1. For the selected file, generate a corresponding test file in the `__tests__` directory using the same name as the source file but ending with `.test.ts`.
 2. If the __tests__ directory does not exist, create it. Or else just generate the test file in the same directory as the source file.
-3. Ensure the test file imports the necessary functions or classes from the source file.
-4. Use the Vitest framework for writing tests.
-5. Write tests that cover the functionality of the source file, including edge cases and error handling.
-6. Honour the global Vitest configuration found in the root folder at `vitest.config.ts`.
-7. There is no need to import Vitest's `expect` or `describe` as they are globally available.
-8. Whenever you generate the unit test code, ensure it produces no TypeError or ESLint errors.
+3. If there are already unit tests presents, please do not override these but amend those you are suggesting in the same describe block.
+4. Ensure the test file imports the necessary functions or classes from the source file.
+5. Use the Vitest framework for writing tests.
+6. Make sure to use the latest features of the Vitest package defined in the package.json
+7. Write tests that cover the functionality of the source file, including edge cases and error handling.
+8. When generating imports, ensure their paths are correct and not broken and that the imports are sorted.
+9. Do not mock any functions or modules. Accept anything the file to be tested imports.
+10. Any values to be tested should be types constants defined in the top parent describe block and reused.
+11. Group unit test cases in subsequent describe blocks based on the subject to be tested.
+  - For example, if the function to be tested, returns only false or true, group these in two describe blocks.
+12. Honour the global Vitest configuration found in the root folder at `vitest.config.ts`.
+13. There is no need to import Vitest's `expect` or `describe` as they are globally available.
+14. Whenever you generate the unit test code, ensure it produces no TypeError or ESLint errors.
 
 ## Preferred Test Structure
 

rslib.config.ts

@@ -1,8 +1,9 @@
+import path from "node:path";
+
 import { pluginNodePolyfill } from "@rsbuild/plugin-node-polyfill";
 import { pluginStylus } from "@rsbuild/plugin-stylus";
 import { RsdoctorRspackPlugin } from "@rsdoctor/rspack-plugin";
 import { defineConfig } from "@rslib/core";
-import path from "path";
 
 import { NodeEnvType } from "./src/types/env";
 import isProductionMode from "./src/util/isProductionMode";