Corrected: this affects js/wasm only. An earlier version of this issue said linux; that was wrong — linux, windows and android all vet clean. Measured, one platform at a time:
linux/arm64 ok
linux/amd64 ok
windows/amd64 ok
android/arm64 ok
js/wasm ./collabtext_test.go:38:31: srv.ServeWebSocket undefined
(type *collab.Server has no field or method ServeWebSocket)
So GOOS=js GOARCH=wasm go vet ./... (or go test) cannot build the test package. It passes on darwin, so nobody meets it locally, and the cross lane builds rather than vets:
GOOS=js GOARCH=wasm go build ./...
go build is blind to test files by design, so the tick is green over something nobody checked. That matters more for wasm than for most platforms here, since the toolkit has real wasm consumers.
Two things worth doing:
- Fix the call.
collab.Server has no ServeWebSocket in the version go.mod selects, and whatever the wasm build swaps in exposes it under another name — the test is written against something older.
- Make the cross lane
go vet ./... for at least js/wasm, so a test file that stops compiling is a red tick and not a silence.
Corrected: this affects js/wasm only. An earlier version of this issue said linux; that was wrong — linux, windows and android all vet clean. Measured, one platform at a time:
So
GOOS=js GOARCH=wasm go vet ./...(orgo test) cannot build the test package. It passes on darwin, so nobody meets it locally, and the cross lane builds rather than vets:go buildis blind to test files by design, so the tick is green over something nobody checked. That matters more for wasm than for most platforms here, since the toolkit has real wasm consumers.Two things worth doing:
collab.Serverhas noServeWebSocketin the versiongo.modselects, and whatever the wasm build swaps in exposes it under another name — the test is written against something older.go vet ./...for at least js/wasm, so a test file that stops compiling is a red tick and not a silence.