DEV Community: Sulthon Zainul Habib

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

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

Sulthon Zainul Habib — Sun, 24 May 2026 16:51:20 +0000

The Problem

npm 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 process

A 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 Solution

I 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 Works

The 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:

Registry fetching: Hit the npm registry endpoint for each package and extract the dist-tags.latest version
Semver diff: Use semver to parse coerce(current) and parse(latest), then compute major/minor/patch differences
Violation logic: A package violates if any diff exceeds its configured maxMajor/maxMinor/maxPatch
Exit codes: CI reads the exit code and fails the build when violations exist

Sample threshold calculation:

const 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 Started

Install globally or as a dev dependency:

npm install -D npm-outdated-check

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

npx npm-outdated-check

Add it to GitHub Actions:

name: Dependency Check

on: [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 Next

Roadmap items include:

Configurable notification channels (Slack, email)
Automated PR generation for outdated packages
Support for Yarn and pnpm lockfiles
Monorepo workspace awareness