mirror of
https://github.com/zvx-echo6/meshai.git
synced 2026-09-03 03:51:34 +00:00
* feat(region-routing): P1 tagging + region_routes primitive + read/write API + preview launcher - config.py: add Coverage.region_tagging (bool=False); add RegionRouteMatrix dataclass (enabled, cells) above NotificationsConfig; add region_routes field to NotificationsConfig; add explicit hydration branch for region_routes in _dict_to_dataclass mirroring destinations pattern. - coverage_area.py: add MonitoringArea.name (str|None=None, frozen); update areas_from_config to preserve name; refactor inline geom extraction from classify_event_areas into shared _event_geom_json helper; add matching_area_names(geom_json, areas)->list[str] (additive, all named matches, config-order, deduped; gate unchanged); add event_region_names convenience wrapper. - coverage_filter.py: add region_tagging ctor kwarg; stamp event.region/ regions before the gate when region_tagging=True and areas non-empty and not event.regions (never clobbers satpass preset). - pipeline/__init__.py: wire region_tagging into CoverageFilter construction. - notification_routes.py: add GET /notifications/regions (named coverage area names, config-order, deduped); GET /notifications/region-routing (matrix as JSON); POST /notifications/region-routing (explicit RMW — only region_routes changes, toggles/rules/destinations survive). - scripts/preview_dashboard.py: mesh-free launcher — dashboard API only, no mesh connector, no broadcast loop; vite runs separately. All 87 coverage tests pass; 300 total pass; 6 pre-existing failures unchanged (adapter config count mismatch + MeshCore EventType.NEW_CONTACT). * feat(region-routing): manual region x family matrix editor page Adds RegionRoutingMatrix.tsx — a plain editor over the region_routes config primitive. Rows = families (via useFamilies()), cols = regions (from GET /api/notifications/regions). Each cell exposes MT channel (ChannelPicker single + includeDisabled), MC channel name (text input), min_severity select (routine/priority/critical/immediate), and an enabled checkbox. Only cells where MT or MC is set are included in the sparse POST payload. Master enable toggle maps to top-level enabled. MT budget guard warns when more than 7 distinct MT indices are in use. Sticky family column; horizontal scroll for wide region sets. Registers route /region-routing in App.tsx and adds "Region Routing" nav entry (Map icon) under the Meshtastic section in Layout.tsx, immediately after Routing. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> * fix(region-routing): regions endpoint reads saved (disk) coverage so routing columns are dynamic without a bot restart; preview reloads config after writes * feat(routing): unify MT/MC routing into per-family cards; region routing as an in-card expand; remove rules/destinations UI + standalone page * refactor(routing): move Meshtastic Routing from /notifications to /meshtastic/routing (mirror /meshcore/routing); redirect legacy path * feat(region-routing): dispatcher honors region_routes matrix (authoritative-on-match, per-region cooldown, per-channel dedup); non-matrix path unchanged Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(region-routing): matrix dedup key must match boot-restore 2-tuple form (prevents restart re-broadcast flood); regression test --------- Co-authored-by: Matt Johnson <mj@k7zvx.com> Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
185 lines
5.6 KiB
Markdown
185 lines
5.6 KiB
Markdown
# ts-interface-checker
|
|
|
|
[](https://travis-ci.org/gristlabs/ts-interface-checker)
|
|
[](https://badge.fury.io/js/ts-interface-checker)
|
|
|
|
|
|
> Runtime library to validate data against TypeScript interfaces.
|
|
|
|
This package is the runtime support for validators created by
|
|
[ts-interface-builder](https://github.com/gristlabs/ts-interface-builder).
|
|
It allows validating data, such as parsed JSON objects received
|
|
over the network, or parsed JSON or YAML files, to check if they satisfy a
|
|
TypeScript interface, and to produce informative error messages if they do not.
|
|
|
|
## Installation
|
|
|
|
```bash
|
|
npm install --save-dev ts-interface-builder
|
|
npm install --save ts-interface-checker
|
|
```
|
|
|
|
## Usage
|
|
|
|
Suppose you have a TypeScript file defining an interface:
|
|
```typescript
|
|
// foo.ts
|
|
interface Square {
|
|
size: number;
|
|
color?: string;
|
|
}
|
|
```
|
|
|
|
The first step is to generate some code for runtime checks:
|
|
```bash
|
|
`npm bin`/ts-interface-builder foo.ts
|
|
```
|
|
|
|
It produces a file like this:
|
|
```typescript
|
|
// foo-ti.js
|
|
import * as t from "ts-interface-checker";
|
|
|
|
export const Square = t.iface([], {
|
|
"size": "number",
|
|
"color": t.opt("string"),
|
|
});
|
|
...
|
|
```
|
|
|
|
Now at runtime, to check if a value satisfies the Square interface:
|
|
```typescript
|
|
import fooTI from "./foo-ti";
|
|
import {createCheckers} from "ts-interface-checker";
|
|
|
|
const {Square} = createCheckers(fooTI);
|
|
|
|
Square.check({size: 1}); // OK
|
|
Square.check({size: 1, color: "green"}); // OK
|
|
Square.check({color: "green"}); // Fails with "value.size is missing"
|
|
Square.check({size: 4, color: 5}); // Fails with "value.color is not a string"
|
|
```
|
|
|
|
Note that `ts-interface-builder` is only needed for the build-time step, and
|
|
`ts-interface-checker` is needed at runtime. That's why the recommendation is to npm-install the
|
|
former using `--save-dev` flag and the latter using `--save`.
|
|
|
|
## Checking method calls
|
|
|
|
If you have an interface with methods, you can validate method call arguments and return values:
|
|
```typescript
|
|
// greet.ts
|
|
interface Greeter {
|
|
greet(name: string): string;
|
|
}
|
|
```
|
|
|
|
After generating the runtime code, you can now check calls like:
|
|
```typescript
|
|
import greetTI from "./greet-ti";
|
|
import {createCheckers} from "ts-interface-checker";
|
|
|
|
const {Greeter} = createCheckers(greetTI);
|
|
|
|
Greeter.methodArgs("greet").check(["Bob"]); // OK
|
|
Greeter.methodArgs("greet").check([17]); // Fails with "value.name is not a string"
|
|
Greeter.methodArgs("greet").check([]); // Fails with "value.name is missing"
|
|
|
|
Greeter.methodResult("greet").check("hello"); // OK
|
|
Greeter.methodResult("greet").check(null); // Fails with "value is not a string"
|
|
```
|
|
|
|
## Type suites
|
|
|
|
If one type refers to a type defined in another file, you need to tell the interface checker about
|
|
all type names when you call `createCheckers()`. E.g. given
|
|
|
|
```typescript
|
|
// color.ts
|
|
export type Color = RGB | string;
|
|
export type RGB = [number, number, number];
|
|
```
|
|
|
|
```typescript
|
|
// shape.ts
|
|
import {Color} from "./color";
|
|
export interface Square {
|
|
size: number;
|
|
color?: Color;
|
|
}
|
|
```
|
|
|
|
the produced files `color-ti.ts` and `shape-ti.ts` do not automatically refer to each other, but
|
|
expect you to relate them in `createCheckers()` call:
|
|
```typescript
|
|
import color from "./color-ti";
|
|
import shape from "./shape-ti";
|
|
import {createCheckers} from "ts-interface-checker";
|
|
|
|
const {Square} = createCheckers(shape, color); // Pass in all required type suites.
|
|
|
|
Square.check({size: 1, color: [255,255,255]});
|
|
```
|
|
|
|
## Strict checking
|
|
|
|
You may check that data contains no extra properties. Note that it is not generally recommended as
|
|
it this prevents backward compatibility: if you add new properties to an interface, then older
|
|
code with strict checks will not accept them.
|
|
|
|
Following on the example above:
|
|
```typescript
|
|
Square.strictCheck({size: 1, color: [255,255,255], bg: "blue"}); // Fails with value.bg is extraneous
|
|
Square.strictCheck({size: 1, color: [255,255,255,0.5]}); // Fails with ...value.color[3] is extraneous
|
|
```
|
|
|
|
## Type guards
|
|
|
|
Standard `Checker` objects do the type checking logic, but are unable to make the TypeScript
|
|
compiler aware that an object of `unknown` type implements a certain interface.
|
|
|
|
Basic code:
|
|
```typescript
|
|
const unk: unknown = {size: 1, color: "green"};
|
|
// Type is unknown, so TypeScript will not let you access the members.
|
|
console.log(unk.size); // Error: "Object is of type 'unknown'"
|
|
```
|
|
|
|
With a `Checker` available:
|
|
```typescript
|
|
import fooTI from "./foo-ti";
|
|
import {createCheckers} from "ts-interface-checker";
|
|
|
|
const {Square} = createCheckers(fooTI);
|
|
|
|
const unk: unknown = {size: 1, color: "green"};
|
|
|
|
if (Square.test(unk)) {
|
|
// unk does implement Square, but TypeScript is not aware of it.
|
|
console.log(unk.size); // Error: "Object is of type 'unknown'"
|
|
}
|
|
```
|
|
|
|
To enable type guard functionality on the existing `test`, and `strictTest` functions, `Checker`
|
|
objects should be cast to `CheckerT<>` using the appropriate type.
|
|
|
|
Using `CheckerT<>`:
|
|
```typescript
|
|
import {Square} from "./foo";
|
|
import fooTI from "./foo-ti";
|
|
import {createCheckers, CheckerT} from "ts-interface-checker";
|
|
|
|
const {Square} = createCheckers(fooTI) as {Square: CheckerT<Square>};
|
|
|
|
const unk: unknown = {size: 1, color: "green"};
|
|
|
|
if (Square.test(unk)) {
|
|
// TypeScript is now aware that unk implements Square, and allows member access.
|
|
console.log(unk.size);
|
|
}
|
|
```
|
|
|
|
## Type assertions
|
|
|
|
`CheckerT<>` will eventually support type assertions using the `check` and `strictCheck` functions,
|
|
however, this feature is not yet fully working in TypeScript.
|