SnmpLensContributing
Working on SnmpLens
Bug reports, patches and MIB compatibility problems are all welcome. This page is the
short version; the repository's CLAUDE.md carries the architectural
reasoning in far more detail.
Setting up
| Requirement | Version |
|---|---|
| Go | as pinned by the toolchain directive in go.mod |
| Node.js | 18 or newer |
| Wails CLI | v2 |
On Debian or Ubuntu you also need the GTK and WebKit development headers:
sudo apt-get install -y libgtk-3-dev libwebkit2gtk-4.1-devBuilding and running
wails dev # hot-reload development server
wails build # production binary into build/bin/
Linux needs the build tag:
wails build -platform linux/amd64 -tags webkit2_41. The same tag belongs on
every go command you run against this repository.
The bridge between Go and the interface
The frontend calls Go through bindings generated into frontend/wailsjs/.
That directory is not in the repository — it is regenerated by
wails dev and wails build, and a fresh clone has none until the
first build.
After changing any exported method on the App struct, or any Go type that
crosses the bridge, you must regenerate before the frontend can use it. Request
parameters are structs in pkg/snmp/params.go mirrored by plain objects in
frontend/src/utils/snmpParams.js; the JSON field names are the contract and
the two are kept in step by hand.
Before you open a pull request
These are what CI runs, from the repository root:
go vet -tags webkit2_41 ./...
go test -race -tags webkit2_41 ./...
staticcheck ./...
go mod tidy && git diff --exit-code go.mod go.sum
govulncheck ./...
cd frontend && npm test
-race is not optional: the MIB library keeps global state and Wails
dispatches every bound method on its own goroutine, so this is the class of bug the
detector exists for.
About the tests
There are deliberately not many, and they are not there for coverage. Each one targets logic that is subtle and can break silently — storage pragmas and migrations, threshold semantics, the poll clock, counter-wrap arithmetic, index encoding round-trips, the delivery outbox.
The frontend suite exists for the same reason. It compiles every Svelte component and fails on a reference to something that does not exist — a name nothing declares compiles to a read of nothing, and the branch throws the first time it is evaluated. Svelte used to warn about that and no longer does, so the suite now looks for the free identifier in the generated code itself. It also checks that the five locale files carry the same keys and the same placeholders, since the translation library falls back silently and a locale can drift for months before anyone who reads that language notices.
If you add a test, please make it fail first. A test that has never been seen to fail is a test that may not be testing anything.
Testing without hardware
SnmpLens simulates its own devices (pkg/simulator), and those are what to try
a change against by hand: the Simulator in the header runs SNMP agents on
loopback addresses, answering v1, v2c and full v3 from fourteen models, with counters that
move and notifications on demand. The documentation
shows how to have one answering in two clicks.
The tests use the same agents, in-process: pkg/simulator/simtest starts a
simulated device inside any Go test, so the integration tests — a server polled, a
counter wrapping, every operation and a discovery scan, a notification followed from the
device to a webhook — run on every build and every platform, with nothing to install and
nothing to point them at.
go test ./pkg/simulator/... ./pkg/monitor/ ./pkg/snmp/Reporting a bug
What makes a report actionable, roughly in order of usefulness:
- What you did, what happened, and what you expected instead.
- The version, from Settings → About, and your operating system.
- For an SNMP problem: the version in use, and whether the same request works from
snmpwalk. - For a MIB problem: the MIB file, if you are able to share it, and what the diagnostics said.
Anonymous Mode (Ctrl Shift A) exists partly for this: it replaces addresses and credentials with stable aliases so a screenshot is safe to attach.
Style
Match the code around you. The one convention worth naming: comments here explain why, not what — usually by recording the failure that made the code look the way it does. A comment that restates the line above it will be asked about; one that says “this used to be X, and here is what broke” is the point.
People
Everyone who has contributed to the repository.
Found a security problem instead? Please read the security policy first — do not open a public issue.