meshai/work/dashboard-frontend/node_modules/ts-interface-checker
malice 2c46c9104d
feat(region-routing): unified per-family routing cards + region-scoped family→channel routing (#87)
* 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>
2026-07-07 16:52:03 -06:00
..
LICENSE feat(region-routing): unified per-family routing cards + region-scoped family→channel routing (#87) 2026-07-07 16:52:03 -06:00
package.json feat(region-routing): unified per-family routing cards + region-scoped family→channel routing (#87) 2026-07-07 16:52:03 -06:00
README.md feat(region-routing): unified per-family routing cards + region-scoped family→channel routing (#87) 2026-07-07 16:52:03 -06:00

ts-interface-checker

Build Status npm version

Runtime library to validate data against TypeScript interfaces.

This package is the runtime support for validators created by 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

npm install --save-dev ts-interface-builder
npm install --save ts-interface-checker

Usage

Suppose you have a TypeScript file defining an interface:

// foo.ts
interface Square {
  size: number;
  color?: string;
}

The first step is to generate some code for runtime checks:

`npm bin`/ts-interface-builder foo.ts

It produces a file like this:

// 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:

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:

// greet.ts
interface Greeter {
  greet(name: string): string;
}

After generating the runtime code, you can now check calls like:

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

// color.ts
export type Color = RGB | string;
export type RGB = [number, number, number];
// 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:

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:

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:

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:

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<>:

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.