From cb8d47d7aaf492992dc622235a9614ad40646d54 Mon Sep 17 00:00:00 2001 From: sneak Date: Mon, 23 Feb 2026 00:00:25 +0700 Subject: [PATCH] Enable prettier prose wrapping for markdown Add proseWrap: "always" to .prettierrc so markdown prose is hard-wrapped at 80 columns. --- .prettierrc | 3 +- README.md | 65 ++++++++++++++++++++++++----------- REPO_POLICIES.md | 88 +++++++++++++++++++++++------------------------- 3 files changed, 91 insertions(+), 65 deletions(-) diff --git a/.prettierrc b/.prettierrc index 0a02bce..8af31cd 100644 --- a/.prettierrc +++ b/.prettierrc @@ -1,3 +1,4 @@ { - "tabWidth": 4 + "tabWidth": 4, + "proseWrap": "always" } diff --git a/README.md b/README.md index 60df9ea..6523735 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,7 @@ -NetWatch is an MIT-licensed JavaScript single-page application by [@sneak](https://sneak.berlin) that provides real-time network latency monitoring to common internet hosts, displayed with color-coded figures and sparkline graphs, served from a static bucket or Docker container. +NetWatch is an MIT-licensed JavaScript single-page application by +[@sneak](https://sneak.berlin) that provides real-time network latency +monitoring to common internet hosts, displayed with color-coded figures and +sparkline graphs, served from a static bucket or Docker container. ## Getting Started @@ -22,27 +25,42 @@ docker run -p 8080:8080 netwatch ## Rationale -When debugging network issues, it's useful to have a persistent at-a-glance view of latency and reachability to multiple well-known internet endpoints. NetWatch provides this as a zero-dependency SPA that can be deployed anywhere static files are served, with no backend required. +When debugging network issues, it's useful to have a persistent at-a-glance view +of latency and reachability to multiple well-known internet endpoints. NetWatch +provides this as a zero-dependency SPA that can be deployed anywhere static +files are served, with no backend required. ## Design -The application is a single-page app built with Vite and Tailwind CSS v4. All code lives in `src/main.js` with a class-based architecture: +The application is a single-page app built with Vite and Tailwind CSS v4. All +code lives in `src/main.js` with a class-based architecture: -- **`CONFIG`**: Frozen configuration object (update interval, timeouts, axis ticks, etc.) -- **`HostState`**: Per-host state management — history buffer, latency tracking, status transitions -- **`AppState`**: Top-level state container — WAN hosts, local hosts, pause state, aggregate stats -- **`SparklineRenderer`**: Canvas 2D sparkline drawing with fixed axes, color-coded line segments, error regions, and DPR-aware scaling -- **UI functions**: `buildUI()` constructs the DOM, `updateHostRow()` / `updateSummary()` / `updateHealthBox()` handle incremental updates -- **`tick()`**: Main loop — measures all hosts in parallel via `Promise.all`, pushes samples, redraws UI. When paused, pushes blank markers (no probes, no false outage) +- **`CONFIG`**: Frozen configuration object (update interval, timeouts, axis + ticks, etc.) +- **`HostState`**: Per-host state management — history buffer, latency tracking, + status transitions +- **`AppState`**: Top-level state container — WAN hosts, local hosts, pause + state, aggregate stats +- **`SparklineRenderer`**: Canvas 2D sparkline drawing with fixed axes, + color-coded line segments, error regions, and DPR-aware scaling +- **UI functions**: `buildUI()` constructs the DOM, `updateHostRow()` / + `updateSummary()` / `updateHealthBox()` handle incremental updates +- **`tick()`**: Main loop — measures all hosts in parallel via `Promise.all`, + pushes samples, redraws UI. When paused, pushes blank markers (no probes, no + false outage) ### Monitoring targets -- **9 WAN hosts**: Google Cloud Console, AWS Console, GitHub, Cloudflare, Azure, DigitalOcean, Fastly, Akamai, datavi.be -- **1 Local host**: Local Gateway (192.168.100.1), tracked separately from WAN stats +- **9 WAN hosts**: Google Cloud Console, AWS Console, GitHub, Cloudflare, Azure, + DigitalOcean, Fastly, Akamai, datavi.be +- **1 Local host**: Local Gateway (192.168.100.1), tracked separately from WAN + stats ### Latency measurement -HEAD requests with `mode: 'no-cors'` and `cache: 'no-store'`, timed with `performance.now()`. 1-second timeout; anything over 1000ms is clamped to unreachable. IPv4 only. +HEAD requests with `mode: 'no-cors'` and `cache: 'no-store'`, timed with +`performance.now()`. 1-second timeout; anything over 1000ms is clamped to +unreachable. IPv4 only. ### Color coding @@ -72,31 +90,40 @@ dist/ - Summary stats: reachable count, min/max/avg latency across WAN hosts only - Fixed chart axes: Y-axis 0–1000ms, X-axis 0–300s - Color-coded latency figures and sparkline line segments -- Play/pause: pause stops probes but history keeps scrolling (blank gaps, no false outage) +- Play/pause: pause stops probes but history keeps scrolling (blank gaps, no + false outage) - Clickable service URLs - Canvas-based sparkline rendering with devicePixelRatio scaling - Zero runtime dependencies: all resources bundled into build artifacts ## Deployment -After running `yarn build`, deploy the contents of the `dist/` directory to any static file host (S3, GCS, Cloudflare Pages, Vercel, Netlify, GitHub Pages) or use the Docker image behind a reverse proxy. +After running `yarn build`, deploy the contents of the `dist/` directory to any +static file host (S3, GCS, Cloudflare Pages, Vercel, Netlify, GitHub Pages) or +use the Docker image behind a reverse proxy. The Docker image: - Listens on port 8080 by default (override with `PORT` env var) -- Trusts `X-Forwarded-For` from RFC1918 reverse proxies (10/8, 172.16/12, 192.168/16) +- Trusts `X-Forwarded-For` from RFC1918 reverse proxies (10/8, 172.16/12, + 192.168/16) - Sends access logs to stdout - Caches static assets with immutable headers ## Browser Compatibility -Requires a modern browser with ES modules, Fetch API, Canvas API, and CSS custom properties. +Requires a modern browser with ES modules, Fetch API, Canvas API, and CSS custom +properties. ## Limitations -- **CORS**: Some hosts may block cross-origin HEAD requests. The app uses `no-cors` mode which allows the request but provides opaque responses. Latency is still measurable based on request timing. -- **Local gateway**: The 192.168.100.1 endpoint requires the host to be accessible from your network. -- **Network conditions**: Measurements reflect browser-to-endpoint latency, which includes your local network, ISP, and internet routing. +- **CORS**: Some hosts may block cross-origin HEAD requests. The app uses + `no-cors` mode which allows the request but provides opaque responses. Latency + is still measurable based on request timing. +- **Local gateway**: The 192.168.100.1 endpoint requires the host to be + accessible from your network. +- **Network conditions**: Measurements reflect browser-to-endpoint latency, + which includes your local network, ISP, and internet routing. ## TODO diff --git a/REPO_POLICIES.md b/REPO_POLICIES.md index ad3c91d..2d40cb4 100644 --- a/REPO_POLICIES.md +++ b/REPO_POLICIES.md @@ -1,23 +1,22 @@ # Development Policies -- Docker image references by tag are server-mutable, therefore using them is - an RCE vulnerability. All docker image references must use cryptographic - hashes to securely specify the exact image that is expected. +- Docker image references by tag are server-mutable, therefore using them is an + RCE vulnerability. All docker image references must use cryptographic hashes + to securely specify the exact image that is expected. -- Correspondingly, `go install` commands using things like '@latest' are - also dangerous RCE. Whenever writing scripts or tools, ALWAYS specify go - install targets using commit hashes which are cryptographically secure. +- Correspondingly, `go install` commands using things like '@latest' are also + dangerous RCE. Whenever writing scripts or tools, ALWAYS specify go install + targets using commit hashes which are cryptographically secure. -- Every repo with software in it must have a Makefile in the root. Each - such Makefile should support `make test` (runs the project-specific - tests), `make lint`, `make fmt` (writes), `make fmt-check` (readonly), and - `make check` (has `test`, `lint`, and `fmt-check` as prereqs), `make -docker` (builds docker image). +- Every repo with software in it must have a Makefile in the root. Each such + Makefile should support `make test` (runs the project-specific tests), + `make lint`, `make fmt` (writes), `make fmt-check` (readonly), and + `make check` (has `test`, `lint`, and `fmt-check` as prereqs), `make docker` + (builds docker image). -- Every repo should have a Dockerfile. If the repo contains non-server - software, the Dockerfile should bring up a development environment and - `make check` (i.e. the docker build should fail if the branch is not - green). +- Every repo should have a Dockerfile. If the repo contains non-server software, + the Dockerfile should bring up a development environment and `make check` + (i.e. the docker build should fail if the branch is not green). - Platform-specific standard formatting should be used. `black` for python, `prettier` for js/css/etc, `go fmt` for go. The only changes to default @@ -25,27 +24,27 @@ docker` (builds docker image). everything except `go fmt`). - If local testing is possible (it is not always), `make check` should be a - pre-commit hook. If it is not possible, `make lint && make fmt-check` - should be a pre-commit hook. + pre-commit hook. If it is not possible, `make lint && make fmt-check` should + be a pre-commit hook. -- If a working `make test` takes more than 20 seconds, that's a bug that - needs fixing. In fact, there should be a timeout specified in the - `Makefile` that fails it automatically if it takes >30s. +- If a working `make test` takes more than 20 seconds, that's a bug that needs + fixing. In fact, there should be a timeout specified in the `Makefile` that + fails it automatically if it takes >30s. - Docker builds should time out in 5 minutes or less. - `main` must always pass `make check`, no exceptions. -- Do all changes on a feature branch. You can do whatever you want on a - feature branch. +- Do all changes on a feature branch. You can do whatever you want on a feature + branch. - We have a standardized `.golangci.yml` which we reuse and is _NEVER_ to be modified by an agent, only manually by the user. It can be copied from `~/dev/upaas/.golangci.yml` if it exists at that location. - When specifying images or packages by hash in Dockerfiles or - `docker-compose.yml`, put a comment above the line and show the version - and date at which it was current. + `docker-compose.yml`, put a comment above the line and show the version and + date at which it was current. - For javascript, always use `yarn` over `npm`. @@ -54,11 +53,11 @@ docker` (builds docker image). - Simple projects should be configured with environment variables, as is standard for Dockerized applications. -- Dockerized web services should listen on the default HTTP port of 8080 - unless overridden with the `PORT` environment variable. +- Dockerized web services should listen on the default HTTP port of 8080 unless + overridden with the `PORT` environment variable. -- The `README.md` is a project's primary documentation. It should contain - at a minimum the following sections: +- The `README.md` is a project's primary documentation. It should contain at a + minimum the following sections: - Description - Include a short and complete description of the functionality and purpose of the software as the first line in the readme. It must @@ -68,10 +67,10 @@ docker` (builds docker image). - the category (web server, SPA, command line tool, etc) - the license - the author - - eg: "µPaaS is an MIT-licensed Go web application by @sneak - that receives git-frontend webhooks and interacts with a - Docker server to build and deploy applications in realtime as - certain branches are updated." + - eg: "µPaaS is an MIT-licensed Go web application by @sneak that + receives git-frontend webhooks and interacts with a Docker server + to build and deploy applications in realtime as certain branches + are updated." - Getting Started - a code block with copy-pasteable installation/use sections - Rationale @@ -79,28 +78,27 @@ docker` (builds docker image). - Design - how is the program structured? - TODO - - This is your TODO list for the project - update it meticulously, - even in between commits. Whenever planning, put your todo list in - the README so that a separate agent with new context can pick up - where you left off. + - This is your TODO list for the project - update it meticulously, even + in between commits. Whenever planning, put your todo list in the + README so that a separate agent with new context can pick up where you + left off. - License - - GPL or MIT or WTFPL - ask the user when beginning a new project - and include a LICENSE file in the root and in a section in the - README. + - GPL or MIT or WTFPL - ask the user when beginning a new project and + include a LICENSE file in the root and in a section in the README. - Author - @sneak (link `@sneak` to `https://sneak.berlin`). -- When beginning a new project, initialize a git repo and make the first - commit simply the first version of the README.md in the root of the repo. +- When beginning a new project, initialize a git repo and make the first commit + simply the first version of the README.md in the root of the repo. -- For Go packages, the module root is `sneak.berlin/go/...`, such - as `sneak.berlin/go/dnswatcher`. +- For Go packages, the module root is `sneak.berlin/go/...`, such as + `sneak.berlin/go/dnswatcher`. - We use SemVer always. - If no tag `1.0.0` or greater exists in the repository, modify the existing - migrations and assume no installed base or existing databases. If - `>=1.0.0`, database changes add new migration files. + migrations and assume no installed base or existing databases. If `>=1.0.0`, + database changes add new migration files. - New repos must have at a minimum the following files: - `README.md`, `.git`, `.gitignore`