* test(plugins): build test plugins in Go instead of shelling out to make The plugins suite built its .ndp test packages by running `make -C plugins/testdata`, which needs make and zip on the PATH. That is the reason the 26 WASM-dependent spec files are tagged //go:build !windows. buildTestPlugins now does the same work in Go: the same mtime check make performed, `GOOS=wasip1 GOARCH=wasm go build` per plugin, and archive/zip for the package. TinyGo was already optional and unused in CI, so nothing is lost there. The first plugin builds on its own so the shared wasip1 stdlib and PDK objects land in the build cache before the rest fan out: on a cold cache that is 2.2s against 3.4s for the sequential make and 7.3s for an unrestrained fan-out. Packaging moved into a writeNdp helper shared with createTestPackage, which was already writing the same two-entry archive. Entries are written in a fixed order, so the .ndp bytes are now reproducible; the loader hashes those bytes, and `zip` also stored file mtimes, so the previous packages differed on every rebuild. The Makefile is unchanged and still works for building the plugins by hand. Removing the !windows tags is a separate step, once CI is green here. * test(plugins): run the WASM plugin specs on Windows With the test plugins now built in Go, nothing in the suite needs a Unix toolchain, so the //go:build !windows tags come off all 25 spec files. The Windows CI job runs `go test ./...`, so it picks the suite up with no workflow change. plugins_suite_windows_test.go existed only to bootstrap the handful of specs that compiled on Windows; plugins_suite_test.go now serves both. * test(plugins): skip the planted-symlink spec where symlinks need privileges os.Symlink needs an elevated token or Developer Mode on Windows, so the unconditional Expect(...).To(Succeed()) would fail for contributors running the suite on an ordinary Windows box. The elevated GitHub runner hides this. The equivalent spec in sandbox_fs_internal_test.go already attempts the symlink and skips on error; this does the same, keeping the pin live everywhere it can run, including Windows CI. * fix(ci): stop the Windows ndpgen test failing silently The ndpgen suite builds its helper binary to %TEMP%\ndpgen-test, and Windows will not exec a file without an executable extension, so the "supports verbose mode" spec has been failing there. Nobody noticed because the Test ndpgen step ran under pwsh, which carries on after a non-zero exit and takes the step's status from the last command, so the job stayed green with a FAIL line in its log. Add the .exe suffix, and run the step under bash like the Linux job does, so a failure in any of its three commands fails the job. |
||
|---|---|---|
| .. | ||
| internal | ||
| testdata | ||
| .gitignore | ||
| go.mod | ||
| go.sum | ||
| integration_test.go | ||
| main.go | ||
| ndpgen_suite_test.go | ||
| README.md | ||
| tools.go | ||
ndpgen
Navidrome Plugin Development Kit (PDK) code generator. It reads Go interface definitions with special annotations and generates client wrappers for WASM plugins.
This tool is the unified code generator that handle both host function wrappers and capability wrappers.
Usage
ndpgen -input <dir> -output <dir> [-package <name>] [-v] [-dry-run] [-host-only] [-go] [-rust]
Flags
| Flag | Description | Default |
|---|---|---|
-input |
Directory containing Go source files with annotated interfaces | Required |
-output |
Directory where generated files will be written | Same as input |
-package |
Package name for generated files | Inferred from output |
-v |
Verbose output | false |
-dry-run |
Parse and validate without writing files | false |
-host-only |
Generate only host function wrappers (capability support TBD) | true |
-go |
Generate Go client wrappers | true* |
-rust |
Generate Rust client wrappers | false |
* -go is enabled by default when -rust is not specified. Use -go -rust to generate both languages.
Example
go run ./plugins/cmd/ndpgen \
-input ./plugins/host \
-output ./plugins/pdk
Annotations
//nd:hostservice
Marks an interface as a host service that will have wrappers generated.
//nd:hostservice name=<ServiceName> permission=<permission>
type MyService interface { ... }
| Parameter | Description | Required |
|---|---|---|
name |
Service name used in generated type names and function prefixes | Yes |
permission |
Permission required by plugins to use this service | Yes |
//nd:hostfunc
Marks a method within a host service interface for export to plugins.
//nd:hostfunc [name=<export_name>]
MethodName(ctx context.Context, ...) (result Type, err error)
| Parameter | Description | Required |
|---|---|---|
name |
Custom export name (default: <servicename>_<methodname> in lowercase) |
No |
Input Format
Host service interfaces must follow these conventions:
- First parameter must be
context.Context- Required for all methods - Last return value should be
error- For proper error handling - Annotations must be on consecutive lines - No blank comment lines between doc and annotation
Example Interface
package host
import "context"
// SubsonicAPIService provides access to Navidrome's Subsonic API.
// This documentation becomes part of the generated code.
//nd:hostservice name=SubsonicAPI permission=subsonicapi
type SubsonicAPIService interface {
// Call executes a Subsonic API request and returns the response.
//nd:hostfunc
Call(ctx context.Context, uri string) (response string, err error)
}
Generated Output
Go Client Library (Go/TinyGo WASM)
Generated files are named nd_host_<servicename>.go (lowercase) and placed in $output/go/host/. The $output/go/ directory becomes a complete Go module (github.com/navidrome/navidrome/plugins/pdk/go) with package name host, intended for import by Navidrome plugins built with TinyGo.
The generator creates:
nd_host_<servicename>.go- Client wrapper code (WASM build)nd_host_<servicename>_stub.go- Mock implementations for non-WASM platforms (testing)doc.go- Package documentation listing all available servicesgo.mod- Go module file with required dependencies
Each service file includes:
// Code generated by ndpgen. DO NOT EDIT.header- Required imports (
encoding/json,errors,github.com/extism/go-pdk) //go:wasmimportdeclarations for each host function- Response struct types and any struct definitions from the service
- Wrapper functions that handle memory allocation and JSON parsing
Testing Plugins with Mocks
The stub files (*_stub.go) contain testify/mock implementations that allow plugin authors to unit test their code on non-WASM platforms.
Each host service has:
- A private mock struct embedding
mock.Mock - An exported auto-instantiated mock instance (e.g.,
host.CacheMock,host.ArtworkMock) - Wrapper functions that delegate to the mock
Example: Testing a plugin that uses the Cache service
package myplugin
import (
"testing"
"github.com/navidrome/navidrome/plugins/pdk/go/host"
)
func TestMyPluginFunction(t *testing.T) {
// Set expectations on the mock
host.CacheMock.On("GetString", "my-key").Return("cached-value", true, nil)
host.CacheMock.On("SetString", "new-key", "new-value", int64(3600)).Return(nil)
// Call your plugin code that uses host.CacheGetString and host.CacheSetString
result := myPluginFunction()
// Assert the result
if result != "expected" {
t.Errorf("unexpected result: %s", result)
}
// Verify all expected calls were made
host.CacheMock.AssertExpectations(t)
}
Resetting mocks between tests:
If you need to reset mock state between tests, testify's mock doesn't have a built-in reset. Either use separate test functions (testify automatically resets between test runs), or create a helper to set up fresh expectations.
Rust Client Library
When using -rust, Rust client files are generated in a rust/ subdirectory.
Supported Types
ndpgen supports these Go types in method signatures:
| Type | JSON Representation |
|---|---|
string, int, bool, etc. |
Native JSON types |
[]T (slices) |
JSON arrays |
map[K]V (maps) |
JSON objects |
*T (pointers) |
Nullable fields |
interface{} / any |
Converts to any |
| Custom structs | JSON objects (must be JSON-serializable) |
Multiple Return Values
Methods can return multiple values (plus error):
//nd:hostfunc
Search(ctx context.Context, query string) (results []string, total int, hasMore bool, err error)
Generates:
type ServiceSearchResponse struct {
Results []string `json:"results,omitempty"`
Total int `json:"total,omitempty"`
HasMore bool `json:"hasMore,omitempty"`
Error string `json:"error,omitempty"`
}
Running Tests
go test ./plugins/cmd/ndpgen/...