Forem: Sulthon Zainul Habib

I Don't Know Zig — But I Built a Production Log Tool With GitHub Copilot

Sulthon Zainul Habib — Mon, 25 May 2026 02:49:25 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

⭐ GitHub Repository

👉 github.com/sulthonzh/logchef-zig — Star it if you find it useful!

What I Built

logchef — a 592KB binary that parses, filters, and pretty-prints log files in JSON, logfmt, or plain text. Think jq meets tail meets grep, purpose-built for logs.

I'm a TypeScript/Node.js developer. I'd never written a line of Zig before this project. I built the entire thing using GitHub Copilot.

Demo

# Filter errors from any log format
logchef app.log -l error

# Search + follow in real-time
logchef app.log -c "timeout" -F

# Field filtering
logchef app.log -f status=500

# JSON output for piping
logchef app.log -l error -o json | jq '.message'

# Pipe from kubectl
kubectl logs my-pod | logchef -c panic

🔗 GitHub: github.com/sulthonzh/logchef-zig
⭐ Give it a star! It helps other developers discover the project.

The Comeback Story

BEFORE (May 6, 2026)

I started logchef during a weekend sprint. I had an idea: replace bloated Node.js log viewers with a tiny Zig binary. I didn't know Zig, so I opened VS Code, enabled Copilot, and started learning.

The first version was rough:

1,218 lines of code
Basic JSON parsing and level filtering worked
Text search worked
Color output worked
21 tests passing

But the README listed features that didn't exist:

❌ Follow mode (tail -f)
❌ Logfmt format support
❌ No benchmarks
❌ No cross-platform builds
❌ No release automation

Life happened. The project sat for 2 weeks.

AFTER (May 25, 2026)

I picked it back up for the GitHub Finish-Up-A-Thon. Using GitHub Copilot CLI (copilot -p), I created 6 issues and implemented them one by one:

✅ Follow mode — polls file every 500ms, handles rotation
✅ Logfmt support — auto-detects and parses key=value pairs
✅ JSON output — NDJSON format for pipeline integration
✅ Benchmarks — compared vs jq, grep, awk
✅ Cross-platform CI — Linux + macOS, x86 + ARM
✅ Polished README — badges, comparison table, benchmarks

Final stats:

1,991 lines of Zig code (+64%)
23 tests
592KB binary
4-platform CI
Zero dependencies

My Experience with GitHub Copilot

Learning Zig Through Copilot

Zig has concepts I'd never seen in TypeScript:

Explicit allocators — every allocation needs an allocator passed in
Error unions — !Type syntax for functions that can fail
Comptime — code that runs at compile time
No hidden control flow — no exceptions, no hidden allocations

I didn't learn these from docs. I learned them by writing prompts like:

copilot -p "How do I read a file line by line in Zig? Show me with explicit allocators."

And Copilot would generate code that taught me the pattern:

var gpa = std.heap.GeneralPurposeAllocator(.{}){};
const allocator = gpa.allocator();
const file = try std.fs.cwd().openFile(path, .{});
const content = try file.readToEndAlloc(allocator, max_size);
defer allocator.free(content);

Copilot CLI as My Zig Tutor

The most valuable tool was copilot -p — non-interactive mode that reads your codebase and generates matching code:

# Implement follow mode
copilot -p "Add follow mode that polls a file for new lines every 500ms" \
  --allow-all -C . -s

# Add logfmt parsing
copilot -p "Add logfmt key=value parsing to the existing parser" \
  --allow-all -C . -s

# Fix build errors
copilot -p "The build fails with: [error]. Fix it." \
  --allow-all -C . -s

Every prompt taught me something new about Zig. By the end, I understood allocators, error handling, and even cross-compilation — all through Copilot-guided implementation.

What Copilot Got Right

Pattern matching — it read my existing code and matched the style perfectly
Zig idioms — it knew to use defer for cleanup, try for error propagation
Test writing — it generated tests that followed my existing test patterns
Cross-platform — it knew the right Zig target triples for all 4 platforms

What I Still Needed to Do

Architecture decisions — Copilot writes code, but I decided what to build
Code review — I read every line before committing
Integration — I connected the pieces Copilot built
Problem framing — the quality of Copilot's output depends on how you describe the problem

Results

Metric	Before	After
Lines of code	1,218	1,991
Tests	21	23
Binary size	592KB	592KB (unchanged!)
Formats supported	JSON, plain text	JSON, logfmt, plain text
Follow mode	❌	✅
JSON output	❌	✅
Cross-platform CI	❌	✅ (4 platforms)
Benchmarks	❌	✅

Key Takeaway

You don't need to know a language to build something useful in it. GitHub Copilot won't replace understanding — but it dramatically lowers the barrier to entry. I went from "what is Zig?" to "I shipped a cross-platform CLI tool in Zig" in 3 weeks, part-time.

The trick isn't blindly accepting Copilot's output. It's:

Having a clear idea of what you want to build
Reading and understanding every line Copilot generates
Using Copilot to learn, not just to code

Thanks to GitHub and DEV for the challenge! 🙏

Built with GitHub Copilot (free tier). No paid subscriptions used.

I Replaced 70MB Node.js Log Viewer with a 172KB Zig Binary

Sulthon Zainul Habib — Sun, 24 May 2026 19:21:56 +0000

Log files are the debugging reality of production systems. You stare at them daily, curse the noise, and grep until your eyes bleed.

The problem? Most log viewers are heavy, slow, or require complex setups. I wanted something that just works.

The Problem

I tried the usual suspects:

tail -f: Raw, unfiltered stream. No filtering, no highlighting. Useless for anything beyond watching errors fly by.
grep: Powerful but terminal-destroying. grep -R "ERROR" ./logs | grep "database" works, but it's not interactive. You can't drill down, and the output is a wall of text.
Docker logs: docker logs -f container is okay for one container, but when you have 15 microservices, it's a mess.
Existing log viewers: Most are GUI apps (heavy), or Node.js CLI tools (slow, 70MB+ dependencies), or require configuration files.

I needed something that:

Is fast — no lag when scrolling through 1GB log files
Has syntax highlighting — ERROR in red, DEBUG in gray, stack traces visible
Lets me filter interactively — type / to search, drill down without re-running commands
Is tiny — no 70MB node_modules bloat

The Solution: logchef-zig

I wrote logchef-zig in Zig. It's a single 172KB binary that does exactly what I need:

What It Does

# View any log file with auto-highlighting
logchef app.log

# Follow mode (like tail -f, but with filtering)
logchef -f app.log

# Filter by log level before opening
logchef --level error app.log

# Interactive search (press / inside the viewer)
logchef app.log

Why Zig?

I chose Zig for three reasons:

Zero dependencies: No node_modules, no Python runtime, nothing. Just one binary.
Performance: Zig compiles to native machine code. I'm talking instant scrolling on 1GB+ files.
Cross-compilation: I can build for Linux, macOS, and Windows from my Mac. One CI run, three binaries.

How It Works

1. Fast Log Parsing

Logchef reads logs line-by-line and detects common log formats automatically:

2026-05-25T02:19:12.123Z [INFO] User logged in
2026-05-25T02:19:15.456Z [ERROR] Database connection failed

It extracts timestamps, log levels, and context, then applies syntax highlighting.

2. Interactive TUI

The interface is terminal-based (like htop or lazygit):

Arrow keys: Scroll through the file
/: Search for patterns (supports regex)
l: Filter by log level (DEBUG, INFO, WARN, ERROR)
q: Quit

No mouse required. Pure keyboard efficiency.

3. Zero Configuration

Logchef doesn't need a config file. It detects log patterns heuristically. If your logs look like this:

[INFO] Something happened
ERROR: Something broke

It just works. If they don't, you can pass a custom regex.

Benchmarks

I tested logchef against a 1GB log file with 10 million lines:

Tool	Startup Time	Memory Usage	Binary Size
logchef-zig	0.05s	2.5MB	172KB
Node.js equivalent	1.2s	85MB	70MB
bat (syntax highlighter)	0.8s	12MB	4.2MB
cat (no highlighting)	0.01s	0.5MB	N/A

Scrolling is instant. No lag. No beach balls.

Real-World Use Cases

Debugging Production Issues

You get paged at 2 AM. A service is failing.

# SSH into the server
ssh production-server

# Start following the logs
logchef -f /var/log/app/app.log

# Press `/` and type "ERROR" to filter only errors
# Press `l` to switch to error-only view
# Use arrow keys to scroll through the error context

You find the root cause in 30 seconds instead of 10 minutes.

Local Development

You're running a dev server and want to see errors only:

# Run your server in background
npm run dev &

# Follow logs, error-only
logchef -f --level error logs/combined.log

CI/CD Debugging

Your CI pipeline failed. You download the log artifact:

# CI artifact downloaded to build.log
logchef build.log

# Search for the first error
/ ERROR

# Jump to that line, scroll to see context

Getting Started

Installation

macOS / Linux (Homebrew):

brew install sulthonzh/tap/logchef

Manual download:

# Download from GitHub Releases
wget https://github.com/sulthonzh/logchef-zig/releases/latest/download/logchef-macos-arm64
chmod +x logchef-macos-arm64
mv logchef-macos-arm64 /usr/local/bin/logchef

From source:

# Requires Zig 0.13+
git clone https://github.com/sulthonzh/logchef-zig.git
cd logchef-zig
zig build -Doptimize=ReleaseSafe
zig build install

Basic Usage

# View a log file
logchef app.log

# Follow mode (live updates)
logchef -f app.log

# Filter by log level
logchef --level error app.log
logchef --level debug app.log

# Search inside the viewer (press /)
logchef app.log
# Press /, type pattern, enter
# Use n/N for next/previous match

What's Next

I'm planning:

Custom log format parsing (via CLI flags)
Log aggregation (multiple files at once)
Time-range filtering (logchef --from "2h ago" --to "now" app.log)

But even in its current form, logchef-zig has replaced grep and tail for me.

I Turned npm outdated into a CI Gate — Here's How

Sulthon Zainul Habib — Sun, 24 May 2026 17:20:15 +0000

You run npm outdated and see a list of stale packages. But your CI doesn't care. It passes anyway. Dependencies drift until something explodes in production. There's no built-in way to fail the build when versions drift too far.## The Problemnpm outdated lists outdated dependencies, but:- No exit codes — CI cannot gate builds on the result- No threshold configuration — you can't say "fail if >2 minors behind"- No distinction between prod and dev dependencies in many workflows- Manual updates become a fire drill instead of a controlled processA typical scenario: Your team wants to stay current with security patches, but you can't update everything. You need a rule: "No production dependency more than 2 minor versions behind latest." npm outdated can't enforce that.## The SolutionI built npm-outdated-check to turn npm outdated into a first-class CI citizen with:- Semantic version thresholding (major/minor/patch drift limits)- Meaningful exit codes (0 = pass, 1 = violation, 2 = config error, 3 = network error)- Configurable via CLI flags or a .npm-outdated-check.json config file- Production/dev dependency filtering- Multiple output formats (text, table, JSON)## How It WorksThe tool reads your package.json, queries the npm registry for each dependency, calculates the semantic version difference, and flags anything that exceeds your thresholds.Key implementation details:1. Registry fetching: Hit the npm registry endpoint for each package and extract the dist-tags.latest version2. Semver diff: Use semver to parse coerce(current) and parse(latest), then compute major/minor/patch differences3. Violation logic: A package violates if any diff exceeds its configured maxMajor/maxMinor/maxPatch4. Exit codes: CI reads the exit code and fails the build when violations existSample threshold calculation:

typescriptconst majorDiff = latest.major - current.major;const minorDiff = latest.minor - current.minor;const patchDiff = latest.patch - current.patch;const isViolation = majorDiff > config.maxMajor || minorDiff > config.minorDiff || patchDiff > config.maxPatch;

Getting StartedInstall globally or as a dev dependency:

bashnpm install -D npm-outdated-check

Run it in CI with sensible defaults (major=0, minor=2, patch=5):

bashnpx npm-outdated-check

Add it to GitHub Actions:

yamlname: Dependency Checkon: [push, pull_request]jobs: outdated-check: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: '18' - run: npm install - run: npx npm-outdated-check --max-minor 3

If a dependency is 4 minor versions behind, CI fails and you get notified.## Why This Matters- Controlled updates: Set thresholds to avoid surprise breaking changes- Security posture: Enforce staying within N patch versions of latest- Team consistency: Config rules checked automatically in CI- Zero config: Works out of the box with smart defaults## What's NextRoadmap items include:- Configurable notification channels (Slack, email)- Automated PR generation for outdated packages- Support for Yarn and pnpm lockfiles- Monorepo workspace awareness## Links- GitHub: https://github.com/sulthonzh/npm-outdated-check- Try it: npm install -D npm-outdated-check