* 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> |
||
|---|---|---|
| .. | ||
| src | ||
| LICENSE | ||
| package.json | ||
| README.md | ||
Install
npm i -D postcss-load-config
Usage
npm i -S|-D postcss-plugin
Install all required PostCSS plugins and save them to your package.json dependencies/devDependencies
Then create a PostCSS config file by choosing one of the following formats
package.json
Create a postcss section in your project's package.json
Project (Root)
|– client
|– public
|
|- package.json
{
"postcss": {
"parser": "sugarss",
"map": false,
"plugins": {
"postcss-plugin": {}
}
}
}
.postcssrc
Create a .postcssrc file in JSON or YAML format
ℹ️ It's recommended to use an extension (e.g
.postcssrc.jsonor.postcssrc.yml) instead of.postcssrc
Project (Root)
|– client
|– public
|
|- (.postcssrc|.postcssrc.json|.postcssrc.yml)
|- package.json
.postcssrc.json
{
"parser": "sugarss",
"map": false,
"plugins": {
"postcss-plugin": {}
}
}
.postcssrc.yml
parser: sugarss
map: false
plugins:
postcss-plugin: {}
Note
For YAML configs, you must have yaml installed as a peer dependency.
.postcssrc.js or postcss.config.js
You may need some logic within your config. In this case create JS/TS file named:
.postcssrc.js.postcssrc.mjs.postcssrc.cjs.postcssrc.ts.postcssrc.mts.postcssrc.ctspostcss.config.jspostcss.config.mjspostcss.config.cjspostcss.config.tspostcss.config.mtspostcss.config.cts
Note
For TypeScript configs, you must have tsx or jiti installed as a peer dependency.
Project (Root)
|– client
|– public
|- (.postcssrc|postcss.config).(js|mjs|cjs|ts|mts|cts)
|- package.json
You can export the config as an {Object}
.postcssrc.js
module.exports = {
parser: 'sugarss',
map: false,
plugins: {
'postcss-plugin': {}
}
}
Or export a {Function} that returns the config (more about the ctx param below)
.postcssrc.js
module.exports = (ctx) => ({
parser: ctx.parser ? 'sugarss' : false,
map: ctx.env === 'development' ? ctx.map : false,
plugins: {
'postcss-plugin': ctx.options.plugin
}
})
Plugins can be loaded either using an {Object} or an {Array}
{Object}
.postcssrc.js
module.exports = ({ env }) => ({
...options,
plugins: {
'postcss-plugin': env === 'production' ? {} : false
}
})
ℹ️ When using an
{Object}, the key can be a Node.js module name, a path to a JavaScript file that is relative to the directory of the PostCSS config file, or an absolute path to a JavaScript file.
{Array}
.postcssrc.js
module.exports = ({ env }) => ({
...options,
plugins: [
env === 'production' ? require('postcss-plugin')() : false
]
})
⚠️ When using an
{Array}, make sure torequire()each plugin
Options
| Name | Type | Default | Description |
|---|---|---|---|
to |
{String} |
undefined |
Destination File Path |
map |
{String|Object} |
false |
Enable/Disable Source Maps |
from |
{String} |
undefined |
Source File Path |
parser |
{String|Function} |
false |
Custom PostCSS Parser |
syntax |
{String|Function} |
false |
Custom PostCSS Syntax |
stringifier |
{String|Function} |
false |
Custom PostCSS Stringifier |
parser
.postcssrc.js
module.exports = {
parser: 'sugarss'
}
syntax
.postcssrc.js
module.exports = {
syntax: 'postcss-scss'
}
stringifier
.postcssrc.js
module.exports = {
stringifier: 'midas'
}
map
.postcssrc.js
module.exports = {
map: 'inline'
}
⚠️ In most cases
options.from&&options.toare set by the third-party which integrates this package (CLI, gulp, webpack). It's unlikely one needs to set/useoptions.from&&options.towithin a config file. Unless you're a third-party plugin author using this module and its Node API directly dont't setoptions.from&&options.toyourself
to
module.exports = {
to: 'path/to/dest.css'
}
from
module.exports = {
from: 'path/to/src.css'
}
Plugins
{} || null
The plugin will be loaded with defaults
'postcss-plugin': {} || null
.postcssrc.js
module.exports = {
plugins: {
'postcss-plugin': {} || null
}
}
⚠️
{}must be an empty{Object}literal
{Object}
The plugin will be loaded with given options
'postcss-plugin': { option: '', option: '' }
.postcssrc.js
module.exports = {
plugins: {
'postcss-plugin': { option: '', option: '' }
}
}
false
The plugin will not be loaded
'postcss-plugin': false
.postcssrc.js
module.exports = {
plugins: {
'postcss-plugin': false
}
}
Ordering
Plugin execution order is determined by declaration in the plugins section (top-down)
{
plugins: {
'postcss-plugin': {}, // [0]
'postcss-plugin': {}, // [1]
'postcss-plugin': {} // [2]
}
}
Context
When using a {Function} (postcss.config.js or .postcssrc.js), it's possible to pass context to postcss-load-config, which will be evaluated while loading your config. By default ctx.env (process.env.NODE_ENV) and ctx.cwd (process.cwd()) are available on the ctx {Object}
ℹ️ Most third-party integrations add additional properties to the
ctx(e.gpostcss-loader). Check the specific module's README for more information about what is available on the respectivectx
Examples
postcss.config.js
module.exports = (ctx) => ({
parser: ctx.parser ? 'sugarss' : false,
map: ctx.env === 'development' ? ctx.map : false,
plugins: {
'postcss-import': {},
'postcss-nested': {},
cssnano: ctx.env === 'production' ? {} : false
}
})
"scripts": {
"build": "NODE_ENV=production node postcss",
"start": "NODE_ENV=development node postcss"
}
const { readFileSync } = require('fs')
const postcss = require('postcss')
const postcssrc = require('postcss-load-config')
const css = readFileSync('index.css', 'utf8')
const ctx = { parser: true, map: 'inline' }
postcssrc(ctx).then(({ plugins, options }) => {
postcss(plugins)
.process(css, options)
.then((result) => console.log(result.css))
})
"scripts": {
"build": "NODE_ENV=production gulp",
"start": "NODE_ENV=development gulp"
}
const { task, src, dest, series, watch } = require('gulp')
const postcss = require('gulp-postcssrc')
const css = () => {
src('src/*.css')
.pipe(postcss())
.pipe(dest('dest'))
})
task('watch', () => {
watch(['src/*.css', 'postcss.config.js'], css)
})
task('default', series(css, 'watch'))
"scripts": {
"build": "NODE_ENV=production webpack",
"start": "NODE_ENV=development webpack-dev-server"
}
webpack.config.js
module.exports = (env) => ({
module: {
rules: [
{
test: /\.css$/,
use: [
'style-loader',
'css-loader',
'postcss-loader'
]
}
]
}
})
Maintainers
Michael Ciniawsky |
Mateusz Derks |
Contributors
Ryan Dunckel |
Patrick Gilday |
Dalton Santos |
François Wouts |
To report a security vulnerability, please use the Tidelift security contact. Tidelift will coordinate the fix and disclosure.