llm-mock-server 1.0.0

package/.github/dependabot.yml

@@ -0,0 +1,11 @@
+version: 2
+updates:
+  - package-ecosystem: "npm"
+    directory: "/"
+    schedule:
+      interval: "weekly"
+    versioning-strategy: "increase"
+  - package-ecosystem: "github-actions"
+    directory: "/"
+    schedule:
+      interval: "weekly"

package/.github/workflows/test.yml

@@ -0,0 +1,34 @@
+name: Test
+
+on:
+  pull_request:
+    branches: [main]
+
+permissions:
+  contents: read
+
+jobs:
+  test:
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout code
+        uses: actions/checkout@v6.0.2
+
+      - name: Setup Node.js
+        uses: actions/setup-node@v6.3.0
+        with:
+          node-version-file: 'package.json'
+          cache: 'npm'
+
+      - name: Install dependencies
+        run: npm ci
+
+      - name: Type check
+        run: tsc --noEmit && tsc --noEmit -p tsconfig.test.json
+
+      - name: Lint
+        run: npm run lint
+
+      - name: Run tests
+        run: npm test

package/.markdownlint.jsonc

@@ -0,0 +1,11 @@
+{
+  "default": true,
+  // Allow longer lines in tables and code blocks
+  "MD013": false,
+  // Allow duplicate headings in different sections
+  "MD024": { "siblings_only": true },
+  // Allow inline HTML
+  "MD033": false,
+  // Allow bare URLs
+  "MD034": false
+}

package/.node-version

@@ -0,0 +1 @@
+22

package/.oxlintrc.json

@@ -0,0 +1,35 @@
+{
+  "plugins": ["typescript", "unicorn", "oxc", "import", "promise", "node"],
+  "categories": {
+    "correctness": "error",
+    "suspicious": "error",
+    "perf": "warn"
+  },
+  "rules": {
+    "no-console": "off",
+    "no-unused-vars": "off",
+    "no-magic-numbers": ["warn", { "ignore": [0, 1, -1, 2, 10] }],
+    "no-await-in-loop": "off",
+    "typescript/no-unused-vars": "off",
+    "typescript/no-non-null-assertion": "off",
+    "unicorn/filename-case": "off",
+    "unicorn/no-null": "off",
+    "unicorn/prevent-abbreviations": "off",
+    "unicorn/no-array-for-each": "off",
+    "unicorn/consistent-function-scoping": "off",
+    "import/no-default-export": "off",
+    "import/no-named-export": "off",
+    "import/prefer-default-export": "off",
+    "import/group-exports": "off",
+    "oxc/no-map-spread": "off"
+  },
+  "overrides": [
+    {
+      "files": ["test/**/*.ts"],
+      "rules": {
+        "no-magic-numbers": "off"
+      }
+    }
+  ],
+  "ignorePatterns": ["dist/", "node_modules/"]
+}

package/ARCHITECTURE.md

@@ -0,0 +1,125 @@
+# llm-mock-server architecture
+
+A mock LLM server built on Fastify. Clients send requests in OpenAI, Anthropic, or Responses API format. The server normalises them into a common shape, matches against registered rules, and sends back responses in the right format.
+
+```mermaid
+flowchart LR
+    Client["Test or SDK client"]
+    Server["llm-mock-server<br/>(Fastify)"]
+    Rules["Rule engine"]
+
+    Client <-->|"OpenAI / Anthropic / Responses"| Server
+    Server <--> Rules
+```
+
+## Table of contents
+
+- [Startup](#startup)
+- [Format system](#format-system)
+- [Request lifecycle](#request-lifecycle)
+- [Rule engine](#rule-engine)
+- [Types](#types)
+- [Streaming](#streaming)
+- [File loading](#file-loading)
+- [Logging](#logging)
+- [Security model](#security-model)
+
+## Startup
+
+[`cli.ts`](src/cli.ts) is the CLI entry point. It parses flags with Commander, validates them through [`cli-validators.ts`](src/cli-validators.ts), creates a `MockServer`, loads any rule files, and handles SIGINT/SIGTERM. With `--watch`, it sets up `fs.watch()` on the rules path and reloads on changes.
+
+[`MockServer`](src/mock-server.ts) is the main class. The constructor creates a Fastify instance and registers a route handler for each format. Consumers interact with it through `when()`, `fallback()`, `load()`, and the lifecycle methods.
+
+[`createMock()`](src/index.ts) is a convenience that creates a server and starts it in one call.
+
+## Format system
+
+A format is anything that satisfies the [`Format`](src/formats/types.ts) interface. It needs to be able to parse requests, serialise streaming and non-streaming responses, and produce error bodies.
+
+Three formats are included:
+
+| Format | Route | Directory |
+| ------ | ----- | --------- |
+| OpenAI | `POST /v1/chat/completions` | [`formats/openai/`](src/formats/openai/) |
+| Anthropic | `POST /v1/messages` | [`formats/anthropic/`](src/formats/anthropic/) |
+| OpenAI Responses | `POST /v1/responses` | [`formats/responses/`](src/formats/responses/) |
+
+Each format directory has three files:
+
+- `parse.ts` takes the incoming request body (plus HTTP headers and path) and turns it into a normalised [`MockRequest`](src/types/request.ts)
+- `serialize.ts` takes a [`ReplyObject`](src/types/reply.ts) and produces SSE chunks or a JSON response
+- `index.ts` wires parse and serialize together into a `Format` object
+
+Shared helpers live in [`parse-helpers.ts`](src/formats/parse-helpers.ts). Functions like `buildMockRequest()`, `genId()`, `splitText()`, `shouldEmitText()`, and `finishReason()` are used by all three formats. `isStreaming()` is also shared because every format checks `body.stream !== false` the same way.
+
+To add a new format (say, Gemini), you would create a new directory with those three files and add it to the `formats` array in `mock-server.ts`. Everything else (rule matching, streaming, logging, history) works automatically.
+
+## Request lifecycle
+
+```mermaid
+flowchart TD
+    A[Incoming POST] --> B[Format parses body into MockRequest]
+    B --> C[Rule engine finds first matching rule]
+    C --> D{Match found?}
+    D -->|yes| E[Resolve reply, static or function]
+    D -->|no| F[Use fallback reply]
+    E --> G{Error reply?}
+    F --> G
+    G -->|yes| H[Return HTTP error with format-specific body]
+    G -->|no| I{Streaming?}
+    I -->|yes| J[Serialise to SSE chunks and write with latency]
+    I -->|no| K[Serialise to JSON and return]
+```
+
+The route handler logic lives in [`route-handler.ts`](src/route-handler.ts). It is generic over the format and gets its dependencies (engine, history, logger, options) through a `RouteHandlerDeps` object.
+
+## Rule engine
+
+[`RuleEngine`](src/rule-engine.ts) holds rules in an array and evaluates them in order. The first match wins.
+
+Each rule has a compiled matcher function, a resolver (either a static value or a function), and an optional `remaining` counter for `.times()`. When a rule's counter hits zero it gets removed from the list.
+
+`moveToFront()` is what powers the `.first()` API. Rules that call `.first()` get moved to index 0.
+
+The matching itself goes through [`compileMatcher()`](src/rule-engine.ts), which turns a `Match` (string, regex, object, or function) into a predicate. Object matchers check each specified field with AND logic. An optional `predicate` field on `MatchObject` runs last, after all structured fields have passed, so you can combine declarative matching with custom logic.
+
+## Types
+
+Types are split across three files in [`src/types/`](src/types/):
+
+- [`request.ts`](src/types/request.ts) has `MockRequest`, `Message`, `ToolDef`, and `FormatName`
+- [`reply.ts`](src/types/reply.ts) has `Reply`, `ReplyObject`, `ErrorReply`, `ToolCall`, `Resolver`, and `ReplyOptions`
+- [`rule.ts`](src/types/rule.ts) has `Match`, `MatchObject`, `PendingRule`, `RuleHandle`, `RuleSummary`, `Handler`, and `Rule`
+
+[`src/types.ts`](src/types.ts) re-exports everything from the barrel so internal files can import from a single place.
+
+## Streaming
+
+[`writeSSE()`](src/sse-writer.ts) writes an array of `SSEChunk` objects to the raw HTTP response as server-sent events. It adds a delay between chunks if latency is configured.
+
+Each format's `serialize()` builds the chunk array. Text gets split by `chunkSize` when it's set. The Responses format also assigns incrementing `sequence_number` values to every event using a closure-based counter.
+
+## File loading
+
+[`loadRulesFromPath()`](src/loader.ts) loads rules from disk. It takes a `LoadContext` with the rule engine and an optional fallback setter. A `Map` dispatches by file extension:
+
+- `.json5` and `.json` files get parsed with Zod validation. Files can be a bare array of rules or an object with optional `templates`, `fallback`, and `rules` fields. Template references (`$name`) are resolved at load time. Rules can use `reply` for a single response or `replies` for a sequence
+- `.ts`, `.js`, and `.mjs` files get dynamically imported. The default export (a `Handler` or array) is registered. A named `fallback` export sets the server fallback
+
+Directories are read and processed in sorted order.
+
+## Logging
+
+[`Logger`](src/logger.ts) is a threshold-based logger. Each level has a numeric priority and messages below the threshold are dropped. Output is timestamped and coloured with picocolors.
+
+## Security model
+
+The threat model is simple: the server runs locally or in CI, loading files written by the developer. There is no multi-tenant isolation or sandboxing.
+
+Handler files (`.ts`, `.js`, `.mjs`) are loaded via `import()` and execute with full process permissions. The trust boundary is the file system path passed to `load()` or `--handler`. If an attacker can write to that path, they already have code execution on the machine. No path restriction is enforced because legitimate setups often load rules from outside the project directory.
+
+JSON5 files go through Zod validation and never execute code. The only dynamic construction is `new RegExp()` for regex patterns in rule files, which could hang on pathological backtracking patterns but poses no injection risk.
+
+Fastify caps request bodies at 1 MB by default. The server binds to `127.0.0.1` unless explicitly configured otherwise. Responses are serialised through JSON, so reply text cannot break out of SSE framing.
+
+CLI inputs (port, host, latency, log level) are validated through [`cli-validators.ts`](src/cli-validators.ts) before use.

package/LICENCE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Suyash Srijan
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -0,0 +1,448 @@
+# llm-mock-server
+
+A mock LLM server for testing. It handles OpenAI `/chat/completions`, Anthropic `/messages`, and OpenAI `/responses` API formats, with both streaming (SSE) and non-streaming responses. Point any client at it and get instant, deterministic replies.
+
+## Table of contents
+
+- [Quick start](#quick-start)
+- [API endpoints](#api-endpoints)
+- [Basic usage](#basic-usage)
+  - [Matching rules](#matching-rules)
+  - [Replies](#replies)
+  - [Fallback](#fallback)
+  - [Request history](#request-history)
+- [Advanced usage](#advanced-usage)
+  - [Tool matching](#tool-matching)
+  - [Error injection](#error-injection)
+  - [Rule lifecycle](#rule-lifecycle)
+  - [Rule inspection](#rule-inspection)
+  - [Streaming options](#streaming-options)
+  - [Advanced patterns](#advanced-patterns)
+- [Loading rules from files](#loading-rules-from-files)
+  - [JSON5 format](#json5-format)
+  - [Handler files](#handler-files)
+- [Logging](#logging)
+- [CLI](#cli)
+- [Security](#security)
+- [Licence](#licence)
+
+## Quick start
+
+```bash
+npm install llm-mock-server
+```
+
+```typescript
+import { createMock } from "llm-mock-server";
+
+await using server = await createMock();
+server.when("hello").reply("Hi there!");
+
+// Point your OpenAI/Anthropic/Codex client at server.url
+const response = await fetch(`${server.url}/v1/chat/completions`, {
+  method: "POST",
+  headers: { "Content-Type": "application/json" },
+  body: JSON.stringify({
+    model: "gpt-5.4",
+    messages: [{ role: "user", content: "hello" }],
+    stream: false,
+  }),
+});
+// server.stop() is called automatically when the scope exits
+```
+
+The same rule matches on all three endpoints, so you don't need to set up separate mocks per provider. By default it binds to `127.0.0.1`. Pass `host: "0.0.0.0"` if you need it reachable from other machines or containers.
+
+## API endpoints
+
+| Route | Format |
+| ----- | ------ |
+| `POST /v1/chat/completions` | OpenAI |
+| `POST /v1/messages` | Anthropic |
+| `POST /v1/responses` | OpenAI Responses |
+
+All three support streaming and non-streaming responses.
+
+## Basic usage
+
+### Matching rules
+
+Rules are evaluated in order and the first match wins. A string does case-insensitive substring matching on the last user message. You can also use regex, object matchers, or predicate functions.
+
+```typescript
+server.when("hello").reply("Hi!");
+server.when(/explain (\w+)/i).reply("Here's an explanation.");
+
+// Match on model, system prompt, format, or tool presence
+server.when({ model: /claude/, system: /pirate/ }).reply("Arrr!");
+server.when({ format: "anthropic" }).reply("Anthropic request detected.");
+
+// Predicate function for full control
+server.when((req) => req.messages.length > 5).reply("Long conversation!");
+
+// Combine structured fields with a predicate
+server.when({
+  model: /claude/,
+  predicate: (req) => req.headers["x-team"] === "alpha",
+}).reply("Alpha team on Claude!");
+```
+
+### Replies
+
+Replies can be strings, objects, or functions.
+
+```typescript
+server.when("hello").reply("Hi!");
+
+// Extended thinking (works with Anthropic and Responses formats)
+server.when("think").reply({ text: "42", reasoning: "Let me work through this..." });
+
+server.when("weather").reply({
+  tools: [{ name: "get_weather", args: { location: "London" } }],
+});
+
+// Dynamic reply based on the request
+server.when("echo").reply((req) => `You said: ${req.lastMessage}`);
+
+// Async resolvers work too
+server.when("slow").reply(async (req) => {
+  return { text: "Done thinking." };
+});
+```
+
+### Fallback
+
+When no rule matches, the server uses a fallback reply. You can change it to whatever you like.
+
+```typescript
+server.fallback("I don't understand.");
+server.fallback({ error: { status: 404, message: "No matching rule" } });
+```
+
+You can also set the fallback from a JSON5 file or handler file. See [loading rules from files](#loading-rules-from-files).
+
+### Request history
+
+Every request that hits the server gets recorded. You can query it with fluent methods in your test assertions.
+
+```typescript
+server.when("hello").reply("Hi!");
+
+await post("/v1/chat/completions", { ... });
+
+expect(server.history.count()).toBe(1);
+expect(server.history.last()?.request.lastMessage).toBe("hello");
+expect(server.history.first()?.rule).toBe('"hello"');
+
+const matched = server.history.where(r => r.rule !== undefined);
+
+for (const entry of server.history) {
+  console.log(entry.request.lastMessage);
+}
+
+const last = server.history.last();
+console.log(last?.request.headers["authorization"]);
+console.log(last?.request.path);
+```
+
+## Advanced usage
+
+### Tool matching
+
+```typescript
+server.whenTool("get_weather").reply({
+  tools: [{ name: "get_weather", args: { location: "London" } }],
+});
+
+server.whenToolResult("call_abc").reply("Got your result!");
+```
+
+### Error injection
+
+Errors are first-class replies and follow the same rule system as everything else.
+
+```typescript
+// One-shot error for the next request, then back to normal
+server.nextError(429, "Rate limited");
+
+// Pattern-matched error that fires every time
+server.when("fail").reply({ error: { status: 500, message: "Internal error" } });
+```
+
+### Rule lifecycle
+
+```typescript
+server.when("hello").reply("Hi!").times(2);
+server.when("catch-all").reply("Fallback.").first();
+server.when("hello").reply("First time only!").times(1).first();
+
+server.isDone(); // true when all .times() rules are consumed
+```
+
+### Rule inspection
+
+You can see what rules are registered and how many matches they have left.
+
+```typescript
+server.when("hello").reply("Hi!");
+server.when(/bye/i).reply("Goodbye!").times(3);
+
+server.rules;
+// [{ description: '"hello"', remaining: Infinity }, { description: '/bye/i', remaining: 3 }]
+```
+
+### Streaming options
+
+You can control how text gets chunked during SSE streaming, both per-rule and at the server level.
+
+```typescript
+server.when("hello").reply("Hello, world!", { latency: 50, chunkSize: 5 });
+
+const server = new MockServer({ defaultLatency: 30, defaultChunkSize: 10 });
+```
+
+### Advanced patterns
+
+These show how to combine the building blocks for more complex scenarios.
+
+#### Reply sequences
+
+Instead of registering multiple rules for multi-turn conversations, pass an array. Each match advances through the sequence. Once exhausted, the rule stops matching and falls through to the next rule or fallback.
+
+```typescript
+server.when("next step").replySequence([
+  "Starting the engine.",
+  "Engine is running.",
+  { reply: { text: "All done." }, options: { latency: 100 } },
+]);
+```
+
+#### Conditional replies
+
+Use a function resolver when the reply depends on the request content.
+
+```typescript
+server.when("status").reply((req) => {
+  const hasTools = req.toolNames.length > 0;
+  return hasTools ? "Tools are available." : "No tools configured.";
+});
+```
+
+#### Simulating flaky APIs
+
+Use a closure to fail every Nth request.
+
+```typescript
+let count = 0;
+server.when(() => ++count % 3 === 0)
+  .reply({ error: { status: 503, message: "Service unavailable" } })
+  .first();
+```
+
+#### Async lookups
+
+Resolvers can be async if you need to compute the reply.
+
+```typescript
+server.when("data").reply(async (req) => {
+  const result = await someAsyncOperation(req.lastMessage);
+  return { text: result };
+});
+```
+
+#### Matching on multiple conditions
+
+Structured fields and predicates combine with AND logic.
+
+```typescript
+server.when({
+  model: /gpt/,
+  format: "openai",
+  system: /you are a translator/i,
+  predicate: (req) => req.messages.length > 2,
+}).reply("Translated output here.");
+```
+
+## Loading rules from files
+
+Rules can live in JSON5 files or TypeScript handler files. You can load a single file or a whole directory.
+
+```typescript
+await server.load("./rules");
+```
+
+### JSON5 format
+
+`rules/greetings.json5`:
+
+```json5
+[
+  {
+    when: "hello",
+    reply: "Hi there!",
+  },
+  {
+    when: "/explain (\\w+)/i",
+    reply: "Here's an explanation.",
+    times: 3,
+  },
+  {
+    when: { model: "gpt-5.4", message: "hello" },
+    reply: { text: "Hi from GPT!", reasoning: "Simple greeting." },
+  },
+]
+```
+
+If you have replies that repeat across multiple rules, you can define them once as templates. Use a `$name` reference in the `reply` field to pull from the templates section.
+
+`rules/with-templates.json5`:
+
+```json5
+{
+  templates: {
+    weatherTool: { tools: [{ name: "get_weather", args: { location: "London" } }] },
+    done: "All done!",
+  },
+  rules: [
+    { when: "forecast", reply: "$weatherTool" },
+    { when: "weather", reply: "$weatherTool" },
+    { when: "finish", reply: "$done" },
+  ],
+}
+```
+
+Sequences work in JSON5 too. Use `replies` instead of `reply` to define a multi-step sequence.
+
+`rules/conversation.json5`:
+
+```json5
+[
+  {
+    when: "next step",
+    replies: [
+      "Starting the engine.",
+      { reply: "Engine is running.", latency: 50 },
+      "All done.",
+    ],
+  },
+]
+```
+
+You can also set a fallback reply in the object format.
+
+`rules/with-fallback.json5`:
+
+```json5
+{
+  fallback: "Sorry, I don't know about that.",
+  rules: [
+    { when: "hello", reply: "Hi!" },
+  ],
+}
+```
+
+Both bare arrays and the object format work. Use bare arrays for simple cases and the object format when you need templates, sequences, or fallbacks.
+
+### Handler files
+
+`rules/echo.ts`:
+
+```typescript
+import type { Handler } from "llm-mock-server";
+
+export default {
+  match: (req) => req.lastMessage.includes("echo"),
+  respond: (req) => `Echo: ${req.lastMessage}`,
+} satisfies Handler;
+```
+
+Using `satisfies Handler` catches typos and wrong field names at compile time. The server also validates the shape at load time with Zod, so you get a clear error either way.
+
+Handler files can export an array of handlers. To set a fallback, export a named `fallback` alongside the default:
+
+```typescript
+import type { Handler } from "llm-mock-server";
+
+export const fallback = "I'm not sure about that.";
+export default {
+  match: (req) => req.lastMessage.includes("echo"),
+  respond: (req) => `Echo: ${req.lastMessage}`,
+} satisfies Handler;
+```
+
+## Logging
+
+```typescript
+const server = new MockServer({ logLevel: "info" });
+```
+
+The available levels are `none`, `error`, `warning`, `info`, `debug`, and `all`. At `info` you get one line per request. At `debug` you also get the parsed request details and reply previews.
+
+## CLI
+
+```bash
+llm-mock-server [options]
+```
+
+| Option | Short | Default | Description |
+| ------ | ----- | ------- | ----------- |
+| `--port` | `-p` | `5555` | Port to listen on |
+| `--host` | `-H` | `127.0.0.1` | Host to bind to |
+| `--rules` | `-r` | | Path to rules file or directory |
+| `--handler` | | | Path to handler file |
+| `--latency` | `-l` | `0` | Ms between SSE chunks |
+| `--chunk-size` | `-c` | `0` | Characters per SSE chunk |
+| `--fallback` | `-f` | | Fallback reply text |
+| `--watch` | `-w` | | Watch rules path and reload on changes |
+| `--log-level` | | `info` | Log verbosity |
+
+```bash
+llm-mock-server -p 8080 -r ./rules --log-level debug
+
+# Auto-reload rules when files change
+llm-mock-server -r ./rules --watch
+```
+
+## Security
+
+This is a testing tool, not a production service. It's designed to run locally or in CI, loading rule files that you wrote. A few things to be aware of.
+
+### Handler files execute code
+
+When you call `server.load()` or pass `--handler` on the CLI, `.ts`/`.js` files are loaded via dynamic `import()`. They run with the same permissions as the rest of your Node.js process. Only load files you trust.
+
+### JSON5 rule files are data only
+
+They go through Zod validation at load time and never execute code. Regex patterns in rule files are compiled with `new RegExp()`, which is safe but could hang on pathological patterns if you write something like `/^(a+)+$/`. Keep patterns simple.
+
+### Network binding
+
+The server binds to `127.0.0.1` by default, so it's only reachable from your machine. If you bind to `0.0.0.0`, anything on the network can send requests to it. That's fine for container setups, just be aware of it.
+
+### Request limits
+
+Request bodies are capped at 1 MB by Fastify's default. Responses are serialised through JSON, so there's no injection risk in the SSE output.
+
+## Licence
+
+MIT License
+
+Copyright (c) 2026 Suyash Srijan
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.