kempo-server 1.10.3 → 1.10.4

package/{.github/copilot-instructions.md → AGENTS.md}

@@ -1,4 +1,4 @@
-# Code Contribution Guidelines
+# AGENTS
 
 ## Coding Style Guidelines
 
@@ -79,18 +79,4 @@ Create utility functions for shared logic.
 Do not prefix identifiers with underscores.
   - Never use leading underscores (`_`) for variable, property, method, or function names.
   - Use clear, descriptive names without prefixes.
-  - When true privacy is needed inside classes, prefer native JavaScript private fields (e.g., `#myField`) instead of simulated privacy via underscores.
-
-## Lit Components
-
-### Component Architecture and Communication
-
-- Use methods to cause actions; do not emit events to trigger logic. Events are for notifying that something already happened.
-  - Prefer `el.closest('ktf-test-framework')?.enqueueSuite({...})` over firing an `enqueue` event.
-
-- Wrap dependent GUI components inside a parent `ktf-test-framework` element. Children find it via `closest('ktf-test-framework')` and call its methods. The framework can query its subtree to orchestrate children.
-
-- Avoid `window` globals and global custom events for coordination. If broadcast is needed, scope events to the framework element; reserve window events for global, non-visual concerns (e.g., settings changes).
-
-- Queued status must show the `scheduled` icon. Running may apply `animation="spin"`.
-
+  - When true privacy is needed inside classes, prefer native JavaScript private fields (e.g., `#myField`) instead of simulated privacy via underscores.

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "kempo-server",
   "type": "module",
-  "version": "1.10.3",
+  "version": "1.10.4",
   "description": "A lightweight, zero-dependency, file based routing server.",
   "main": "dist/index.js",
   "exports": {
@@ -15,15 +15,15 @@
   "scripts": {
     "build": "node scripts/build.js",
     "docs": "node dist/index.js -r ./docs",
-    "tests": "npx kempo-test",
-    "tests:gui": "npx kempo-test --gui",
-    "tests:browser": "npx kempo-test -b",
-    "tests:node": "npx kempo-test -n"
+    "test": "npx kempo-test",
+    "test:gui": "npx kempo-test --gui",
+    "test:browser": "npx kempo-test -b",
+    "test:node": "npx kempo-test -n"
   },
   "author": "",
   "license": "ISC",
   "devDependencies": {
-    "kempo-testing-framework": "^1.2.3",
+    "kempo-testing-framework": "^1.4.4",
     "terser": "^5.43.1"
   },
   "repository": {

package/CONTRIBUTING.md

@@ -1,136 +0,0 @@
-# Code Contribution Guidelines
-
-## Coding Style Guidelines
-
-### Code Organization
-Use multi-line comments to separate code into logical sections. Group related functionality together.
-  - Example: In Lit components, group lifecycle callbacks, event handlers, public methods, utility functions, and rendering logic separately.
-
-```javascript
-/*
-  Lifecycle Callbacks
-*/
-```
-
-### Avoid single-use variables/functions
-Avoid defining a variable or function to only use it once; inline the logic where needed. Some exceptions include:
-  - recursion
-  - scope encapsulation (IIFE)
-  - context changes
-
-### Minimal Comments, Empty Lines, and Spacing
-
-Use minimal comments. Assume readers understand the language. Some exceptions include:
-  - complex logic
-  - anti-patterns
-  - code organization
-
-Do not put random empty lines within code; put them where they make sense for readability, for example:
-  - above and below definitions for functions and classes.
-  - to help break up large sections of logic to be more readable. If there are 100 lines of code with no breaks, it gets hard to read.
-  - above multi-line comments to indicate the comment belongs to the code below
-
-No  empty lines in css.
-
-End each file with an empty line.
-
-End each line with a `;` when possible, even if it is optional.
-
-Avoid unnecessary spacing, for example:
-  - after the word `if`
-  - within parentheses for conditional statements
-
-```javascript
-let count = 1;
-
-const incrementOdd = (n) => {
-  if(n % 2 !== 0){
-    return n++;
-  }
-  return n;
-};
-
-count = incrementOdd(count);
-```
-
-### Prefer Arrow Functions
-Prefer the use of arrow functions when possible, especially for class methods to avoid binding. Use normal functions if needed for preserving the proper context.
- - For very basic logic, use implicit returns
- - If there is a single parameter, omit the parentheses.
-```javascript
-const addOne = n => n + 1;
-```
-
-### Module Exports
-  - If a module has only one export, use the "default" export, not a named export.
-    - Do not declare the default export as a const or give it a name; just export the value.
-
-```javascript
-export default (n) => n + 1;
-```
-  - If a module has multiple exports, use named exports and do not use a "default" export.
-
-### Code Reuse
-Create utility functions for shared logic.
-  - If the shared logic is used in a single file, define a utility function in that file.
-  - If the shared logic is used in multiple files, create a utility function module file in `src/utils/`.
-
-### Naming
-Do not prefix identifiers with underscores.
-  - Never use leading underscores (`_`) for variable, property, method, or function names.
-  - Use clear, descriptive names without prefixes.
-  - When true privacy is needed inside classes, prefer native JavaScript private fields (e.g., `#myField`) instead of simulated privacy via underscores.
-
-## Lit Components
-
-### Component Architecture and Communication
-
-- Use methods to cause actions; do not emit events to trigger logic. Events are for notifying that something already happened.
-  - Prefer `el.closest('ktf-test-framework')?.enqueueSuite({...})` over firing an `enqueue` event.
-
-- Wrap dependent GUI components inside a parent `ktf-test-framework` element. Children find it via `closest('ktf-test-framework')` and call its methods. The framework can query its subtree to orchestrate children.
-
-- Avoid `window` globals and global custom events for coordination. If broadcast is needed, scope events to the framework element; reserve window events for global, non-visual concerns (e.g., settings changes).
-
-- Queued status must show the `scheduled` icon. Running may apply `animation="spin"`.
-
-## Version Management and Publishing
-
-This project uses automated workflows for version management and publishing to npm. There are three different workflows available:
-
-### Automatic Patch Publishing
-- **Workflow**: `publish-npm.yml`
-- **Trigger**: Automatically runs on every push to `main` branch
-- **Action**: Increments patch version (e.g., 1.5.1 → 1.5.2) and publishes to npm
-- **Use for**: Bug fixes, small changes, documentation updates
-
-### Manual Minor Version Publishing
-- **Workflow**: `publish-minor.yml`
-- **Trigger**: Manual workflow dispatch from GitHub Actions tab
-- **Action**: Increments minor version (e.g., 1.5.2 → 1.6.0) and publishes to npm
-- **Use for**: New features, backwards-compatible API additions
-
-### Manual Major Version Publishing
-- **Workflow**: `publish-major.yml`
-- **Trigger**: Manual workflow dispatch from GitHub Actions tab  
-- **Action**: Increments major version (e.g., 1.6.0 → 2.0.0) and publishes to npm
-- **Use for**: Breaking changes, major API overhauls
-
-### How to Publish Minor or Major Versions
-
-1. **Push your changes to main**: The automatic patch workflow will run and increment the patch version
-2. **Go to GitHub Actions tab** in the repository
-3. **Select the appropriate workflow**:
-   - "Publish Minor Version to npmjs" for minor bumps
-   - "Publish Major Version to npmjs" for major bumps
-4. **Click "Run workflow"** button
-5. **Confirm the run**: The workflow will increment the version and publish automatically
-
-**Example workflow for a minor version**:
-- Current version: 1.5.1
-- Push changes → Auto patch: 1.5.1 → 1.5.2
-- Manually run minor workflow: 1.5.2 → 1.6.0
-- Final published version: 1.6.0
-
-**Note**: You will "use up" one patch version number when doing manual minor/major bumps, but this ensures the automated system continues to work smoothly.
-