TinyGo in Zed — oxblog

I’ve moved my embedded Go work to<br>Zed. It is super<br>fast, pleasant and increasingly secure by default. For me it beats the shit out<br>of messy VS Code: fewer layers, less interface debris and no feeling that my<br>text editor is a browser wearing a tool belt.

Zed is a native Rust application with a purpose-built, GPU-accelerated UI<br>designed to render at<br>120<br>frames per second. Unfamiliar worktrees also open in<br>Restricted Mode, so project settings cannot start language<br>or MCP servers until I explicitly trust the worktree. Speed without careless<br>defaults. Rather nice.

Zed’s native Go tooling resolving TinyGo’s machine package for a<br>Pico target.

The TinyGo-shaped hole

Zed’s native Go support uses gopls, but TinyGo targets have their<br>own GOROOT, architecture and build tags. Without those values,<br>gopls cannot properly understand packages such as<br>machine or names such as machine.LED.

So I wrote<br>tinygo-zed to turn that procedure into one<br>command. Install it alongside TinyGo, then run it from the project directory:

go install github.com/oxplot/tinygo-zed@latest

tinygo-zed init

Choose a target when prompted. The utility reads its actual metadata from<br>TinyGo, writes the corresponding gopls settings and adds useful<br>build, test, report and flash tasks. Open the directory in Zed, click<br>Restricted Mode in the title bar and trust the worktree.<br>Hover, completion, navigation and diagnostics should now understand the<br>selected board, as in the screenshot above.

If the board changes, use tinygo-zed target. After upgrading<br>TinyGo, run tinygo-zed sync. That’s the whole trick: keep Zed’s<br>native Go tooling and point it at the right reality.