DEV Community: Chintan Shah

logfx v1.0.0: One Logger for Development and Production (TS, Zero deps, 13 integrations)

Chintan Shah — Thu, 05 Mar 2026 00:35:18 +0000

Today I'm shipping logfx v1.0.0. It's the first release I consider production-ready: 13 official integrations, PII redaction, retry and circuit breaker in the webhook transport, and zero dependencies. Same API in Node and browser.

Every logger forces a choice: readable output for development, or structured JSON for production. You either configure both manually or pick one and live with it. logfx v1.0.0 removes that choice. Same logger, auto-detected format based on NODE_ENV.

I've been maintaining logfx since v0.3.0.

The Problem

In development, you want logs you can read. Colors, emojis, clear structure. When something breaks at 2am, you need to scan output quickly.

In production, you need structured JSON. Datadog, Elasticsearch, Splunk, and every log aggregator expect JSON. Timestamps, levels, correlation IDs. Machine-readable.

Most loggers make you configure two setups or accept one format everywhere. logfx switches automatically.

The other pain point: logging user data. Emails, tokens, passwords. One slip and you're leaking PII. logfx handles that with built-in redaction and custom patterns.

The third: sending logs to a remote endpoint. Networks fail. Retries, circuit breakers, dead letter queues. You either build it or hope your logs get through. logfx ships it.

import { createLogger } from 'logfx'

const log = createLogger()

log.info('Server started', { port: 3000 })

Development output:

💡 INFO  Server started { port: 3000 }

Production output (NODE_ENV=production):

{"timestamp":"2026-01-14T12:00:00.000Z","level":"info","message":"Server started","data":{"port":3000}}

No format flag. No environment checks in your code. It just works.

What logfx Actually Does

Core Logging

Five levels (debug, info, success, warn, error), namespaced loggers, context metadata. Errors serialize with stack traces. Lazy evaluation so you can defer expensive operations until they're actually logged. Same API whether you're in Node, Bun, Deno, or the browser.

const authLog = createLogger({ namespace: 'auth' })
authLog.info('Login attempt', { userId: 123 })
// 💡 INFO [auth] Login attempt { userId: 123 }

Attach metadata to every log from a logger:

const log = createLogger({
  context: { service: 'api', version: '1.0.0' }
})
log.info('Request received', { path: '/users' })
// Every entry includes service and version

W3C TraceParent format is supported for correlating logs across services.

PII Redaction

Logging user data is risky. Emails, SSNs, credit cards, JWTs can leak. logfx has built-in patterns and key-based redaction:

const log = createLogger({
  redact: {
    keys: ['password', 'token', 'apiKey'],
    patterns: ['email', 'ssn', 'creditCard', 'phone', 'ip', 'jwt'],
    customPatterns: [
      { name: 'apiKey', regex: /sk_(live|test)_[a-zA-Z0-9]+/g }
    ]
  },
  transports: [transports.console({ format: 'json' })]
})

log.info('User signup', { email: 'user@example.com', password: 'secret' })
// {"email":"[REDACTED]","password":"[REDACTED]",...}

You can add custom patterns or masking functions. Useful when you need partial redaction for debugging (e.g. last 4 digits of a card).

Production Reliability (Webhook Transport)

When you send logs to a remote endpoint, networks fail. Timeouts, 5xxs, rate limits. logfx's webhook transport handles that:

Retry - Exponential backoff with jitter. Configurable max retries and delay.
Circuit breaker - Stops sending after N failures, reopens after a timeout.
Dead letter queue - Failed logs go to an in-memory queue. Optionally persist to disk.
Multi-region failover - Multiple URLs with round-robin or priority. Optional health checks.

You get this without writing retry logic or circuit breaker code. It's built in.

Framework Middleware

Express, Fastify, and Next.js integrations give you req.log and request IDs:

import express from 'express'
import { expressLogger } from 'logfx/middleware'

const app = express()
app.use(expressLogger())

app.get('/users', (req, res) => {
  req.log.info('Fetching users', { userId: req.query.id })
  res.json({ users: [] })
})

Output:

💡 INFO [http] Incoming request { method: 'GET', path: '/users', requestId: 'abc123' }
💡 INFO [http] Fetching users { userId: '42' }
💡 INFO [http] Request completed { method: 'GET', path: '/users', status: 200, durationMs: 45 }

Each request gets a unique ID. Status codes set log level (5xx = error, 4xx = warn). Skip health checks or customize ID extraction. The middleware works with Express, Fastify, and Next.js API routes.

13 Integrations

Separate packages for each platform. Install only what you need:

npm install logfx logfx-datadog
# or logfx-elasticsearch, logfx-sentry, logfx-cloudwatch, etc.

import { createLogger } from 'logfx'
import { datadogTransport } from 'logfx-datadog'

const log = createLogger({
  transports: [
    datadogTransport({
      apiKey: process.env.DD_API_KEY,
      service: 'my-api',
      batchSize: 100,
      flushInterval: 5000
    })
  ]
})

Integrations by category:

Category	Package	Use case
APM / Observability	logfx-datadog, logfx-elasticsearch, logfx-sentry, logfx-otel	Datadog, Elasticsearch, Sentry, OpenTelemetry
Cloud	logfx-cloudwatch, logfx-google-cloud, logfx-azure	AWS, GCP, Azure logs
Alerts / SIEM	logfx-slack, logfx-loki, logfx-papertrail, logfx-splunk	Slack alerts, Grafana Loki, Papertrail, Splunk
Analytics	logfx-honeycomb, logfx-logtail	Honeycomb, Logtail (Better Stack)

Each uses the same Transport interface. Add console, file, or webhook in the same array. No monolith. Install only what you need.

File Transport with Rotation

Write to disk with size-based rotation and compression:

transports.file({
  path: './logs/app.log',
  rotation: {
    maxSize: '10mb',
    maxFiles: 5,
    compress: true
  }
})

Creates app.log.1, app.log.2, etc. Old files are gzipped. Prevents disk from filling up.

Browser Support

Same API in Node and browser. For SPAs, the Beacon transport sends logs reliably even when the user closes the tab:

transports.beacon({
  url: '/api/logs',
  events: { beforeunload: true, visibilitychange: true }
})

Uses the Beacon API. Falls back to fetch if unavailable. Non-blocking so it doesn't delay page unload. Useful for analytics, error reporting, or session replay when the user navigates away.

Log Sampling

For high traffic, reduce volume while keeping visibility:

const log = createLogger({
  sampling: {
    debug: 0.1,
    info: 0.5,
    warn: 1.0,
    error: 1.0
  }
})

Sample 10% of debug, 50% of info. Always log warnings and errors.

When It Helps

Node.js APIs - Express/Fastify/Next.js middleware, structured JSON to Datadog/Elasticsearch, request tracing
SPAs - Beacon transport for analytics or error reporting on page close
Microservices - Context and request IDs for correlating logs across services
Sensitive data - PII redaction before logs hit aggregation
High volume - Async buffering, sampling, circuit breaker when the log sink is down

What's in the Box

Zero dependencies on the core package
~3KB gzipped
ESM and CJS
Full TypeScript support
CI: tests, typecheck, build on Node 18, 20, 22, 24
Stress tested: 10k logs in under 1s, 1k with redaction in under 500ms

What It Doesn't Do

It's a logger, not a full observability platform. No distributed tracing (though OpenTelemetry integration injects trace IDs). No metrics. No APM. It logs. That's the scope.

Try It

npm install logfx

import { log } from 'logfx'

log.info('Hello', { version: '1.0.0' })
log.error('Something failed', new Error('oops'))

Links:

If you're on logfx 0.5.x, v1.0.0 adds integrations, PII redaction improvements, and production hardening. The core API is compatible. Upgrade and add what you need.

Wrapping Up

One logger for dev and prod. No format switching. No config. 13 integrations when you need them. PII redaction and production reliability built in.

I also maintain handlejson (GitHub) for safe JSON parsing, envconfig-kit (GitHub) for env validation, and upstatus (GitHub) for uptime monitoring. All focused Node/TS packages.

What logging setup are you using? Would love to hear what works (or doesn't) for you.

Stop Writing Try-Catch Blocks for JSON.parse - handlejson v1.0.0 is Production Ready

Chintan Shah — Fri, 30 Jan 2026 06:11:04 +0000

A few weeks ago, I introduced handlejson with v0.2.0 - a simple library to eliminate try-catch spam when parsing JSON. After development from December 2025 to January 2026 and 244 tests, v1.0.0 is production-ready.

The Journey to v1.0.0

When I first released handlejson, it solved a real problem - eliminating try-catch boilerplate. Fast forward to today, and it's production-ready with comprehensive tests, performance improvements, and enterprise-grade features.

What Changed Since v0.2.0

The core idea remains the same - a focused solution that returns null on error instead of throwing. Here's what's been added:

v0.3.0 (January 10)

Better validation errors: tryValidate() now returns detailed error info (path, expected, actual)
Optional fields: Prefix types with ? to mark fields as optional (age: '?number')
Array validation: Validate array item types, not just array presence
CI/CD: GitHub Actions workflows for automated testing

v1.0.0 (January 30) - Production Ready

244 comprehensive tests covering all edge cases
- Security features (maxSize, maxDepth, safeKeys)
- Date handling (ISO strings, timestamps)
- Circular reference handling
- Stream parsing for large files
- Schema validation with detailed errors
Performance improvements: 2-3x faster parsing (5.2M ops/s vs ~2M ops/s)
- Date regex compiled once instead of per call
- Smart object copying (only when dangerous keys found) - optimized key sanitization
Enhanced security: Improved sanitizeKeys performance for prototype pollution protection
Enhanced error messages: Better formatting with position and context
Memory efficiency: Improved garbage collection behavior
CI/CD: Automated testing across Node 18, 20, 22
Documentation: Performance benchmarks and enhanced docs

How many times have you written this?

let data
try {
  data = JSON.parse(str)
} catch {
  data = null
}

If you're like me, probably dozens of times. Every API response, every localStorage read, every user input - same pattern, same boilerplate.

After writing this pattern one too many times, I built handlejson.

What is handlejson?

It's a focused wrapper around JSON.parse that returns null on error instead of throwing. This simple change eliminates the try-catch boilerplate you write everywhere.

import { parse } from 'handlejson'

const data = parse(str) // null if invalid
const data = parse(str, { default: {} }) // {} if invalid

Simple, but genuinely useful.

Why I built it

The breaking point was a project parsing JSON from APIs, localStorage, user input, and config files. Every single parse needed a try-catch. My code was cluttered with error handling boilerplate.

I checked existing solutions, but they were either too heavy, missing security features, or had dependencies I didn't want. So I built my own.

What makes it useful

1. Security options built-in

When handling untrusted input, you need protection. Most JSON libraries don't include this:

const safe = parse(userInput, {
  maxSize: 10 * 1024 * 1024,  // Prevent memory exhaustion attacks
  maxDepth: 100,                // Prevent stack overflow from deeply nested JSON
  safeKeys: true                // Block prototype pollution (__proto__, constructor, prototype)
})

These aren't theoretical - they're real attack vectors:

maxSize: Prevents attackers from sending huge JSON payloads that exhaust memory
maxDepth: Prevents deeply nested JSON that causes stack overflow
safeKeys: Blocks prototype pollution attacks that can lead to code execution

Having them built-in saves you from implementing them yourself. In v1.0.0, the sanitizeKeys function was optimized to only copy objects when dangerous keys are actually found, improving performance.

2. Better error messages

When debugging JSON errors, knowing where the error is helps:

import { parseWithDetails } from 'handlejson'

const result = parseWithDetails('{"name":"John", invalid}')
if (!result.success) {
  console.log(result.position)  // 18
  console.log(result.context)   // Shows surrounding context
  console.log(result.error)     // Detailed error message
}

Much better than "Unexpected token" with no context.

3. Schema validation

Basic type checking without extra dependencies:

const schema = { name: 'string', age: 'number' }
const user = parse('{"name":"John","age":30}', { schema })
// Returns null if validation fails

What's new in v0.3.0+: Optional fields and better error messages:

const schema = {
  name: 'string',
  age: '?number',      // Optional field
  email: '?string'     // Optional field
}

const [valid, error] = tryValidate(data, schema)
if (!valid) {
  console.log(error.path)      // 'age'
  console.log(error.expected)  // 'number'
  console.log(error.actual)    // 'string'
}

Perfect for validating API responses, configuration files, and user input without adding heavy dependencies. Handles optional fields, nested objects, and arrays with detailed error messages.

4. Stream parsing

For large files, parse in chunks:

import { parseStream } from 'handlejson'

const result = await parseStream(largeFileStream, {
  onProgress: (parsed) => console.log('Progress:', parsed)
})

Handles files without loading everything into memory.

Performance

Benchmarks against native JSON:

Small JSON (<1KB): 5.2M ops/s (vs ~6M for native)
With security options: 3.4M ops/s
Overhead exists, but minimal

For most applications, the convenience and security features are worth the minimal performance overhead. The 5.2M ops/s performance handles high-throughput scenarios while providing better error handling and built-in security.

Real-world use cases

API responses:

const response = await fetch('/api/user')
const user = parse(await response.text(), { default: {} })
// Always get an object, never crashes

LocalStorage:

const saved = parse(localStorage.getItem('data'), { default: null })
// Safe, no try-catch needed

User input with security:

const userData = parse(userInput, {
  maxSize: 10 * 1024 * 1024,
  maxDepth: 100,
  safeKeys: true
})

When to use it

✅ Parsing API responses

✅ Handling user input

✅ Processing configuration files

✅ Debugging JSON errors

✅ Handling untrusted input (security options)

Why it matters

handlejson solves a problem every developer faces daily - repetitive try-catch boilerplate. Beyond convenience, it adds production-ready features like built-in security, detailed error messages, and comprehensive test coverage. The security options protect against real attack vectors, making it ideal for production applications handling untrusted input.

Production ready

After development from December 2025 to January 2026, v1.0.0 is ready:

244 tests covering edge cases (security, dates, circular refs, streams, validation)
Zero dependencies
1.5KB gzipped
TypeScript-first
CI/CD with GitHub Actions (tests on Node 18, 20, 22)
Performance: 5.2M ops/s for small JSON (vs ~6M for native)

The main difference from v0.2.0 is production-ready quality - comprehensive tests, performance optimizations, and better documentation. The API hasn't changed, so existing code works without modifications.

Try it out

npm install handlejson

import { parse, stringify } from 'handlejson'

const data = parse('{"name":"John"}')  // { name: 'John' }
const json = stringify({ name: 'John' })  // '{"name":"John"}'

Links:

npm: https://www.npmjs.com/package/handlejson
GitHub: https://github.com/chintanshah35/handlejson
Documentation: https://github.com/chintanshah35/handlejson#readme

If you're new to handlejson, check out my original introduction article where I covered the basics and v0.2.0 features.

Stop Writing Database Configs From Scratch: envconfig-kit v0.2.0

Chintan Shah — Mon, 26 Jan 2026 05:24:20 +0000

I wrote about making your app crash at startup instead of in production. That post was about envconfig-kit v0.1.0.

Here's what's new in envconfig-kit v0.2.0.

What's New

Framework Presets

Pre-configured schemas for common patterns. Stop writing the same database, Redis, and auth configs over and over:

import { env, presets } from 'envconfig-kit'

const config = env({
  ...presets.server(),      // PORT, HOST, NODE_ENV
  ...presets.database(),   // DATABASE_URL, DATABASE_HOST, etc.
  ...presets.redis(),      // REDIS_URL, REDIS_HOST, etc.
  ...presets.auth(),       // AUTH_JWT_SECRET, etc.
  ...presets.aws(),        // AWS_ACCESS_KEY_ID, etc.
  ...presets.smtp(),       // SMTP_HOST, SMTP_PORT, etc.
  ...presets.cors(),       // CORS_ORIGINS, CORS_METHODS, etc.
})

Custom prefixes work too:

...presets.database('DB_')  // DB_URL, DB_HOST, etc.
...presets.redis('CACHE_')  // CACHE_URL, CACHE_HOST, etc.

New Validators

Enum Type - Type-safe environment values:

const config = env({
  NODE_ENV: { 
    type: 'enum', 
    values: ['development', 'staging', 'production'] as const,
    default: 'development'
  },
})
// config.NODE_ENV is typed as 'development' | 'staging' | 'production'

Array Type - Parse comma-separated values:

const config = env({
  ALLOWED_HOSTS: { type: 'array' },  // "a,b,c" → ["a", "b", "c"]
  TAGS: { type: 'array', separator: '|' },  // custom separator
})

JSON Type - Parse JSON strings:

const config = env({
  FEATURE_FLAGS: { type: 'json' },
})
// FEATURE_FLAGS='{"darkMode":true}' → { darkMode: true }

Regex Type - Custom pattern validation:

const config = env({
  API_VERSION: { 
    type: 'regex', 
    pattern: /^v\d+\.\d+$/ 
  },
})
// Only accepts "v1.0", "v2.1", etc.

Integer Type - Whole numbers only:

const config = env({
  PORT: { type: 'integer' },  // Stricter than 'number'
})

Secret Masking

Mark secrets and they'll be masked automatically in error messages:

const config = env({
  API_KEY: { type: 'string', secret: true },
  DATABASE_PASSWORD: { type: 'string', secret: true },
})

When validation fails, error messages show API_KEY=**** instead of the actual value. No more accidentally logging secrets.

Custom Validation

Add your own validation logic:

const config = env({
  PORT: { 
    type: 'number',
    validate: (value) => value >= 1024 && value <= 65535
  },
  MAX_CONNECTIONS: {
    type: 'integer',
    validate: (value) => value > 0 && value <= 1000,
    default: 100
  },
})

Real-World Example

Here's how you'd configure a typical API with v0.2.0:

import { env, presets } from 'envconfig-kit'

export const config = env({
  // Server (preset)
  ...presets.server(),

  // Database (preset)
  ...presets.database(),

  // Redis (preset)
  ...presets.redis(),

  // Auth (preset)
  ...presets.auth(),

  // External services
  STRIPE_KEY: { type: 'string', secret: true },
  SENDGRID_KEY: { type: 'string', secret: true },

  // CORS (preset)
  ...presets.cors(),

  // Feature flags with enum
  FEATURE_MODE: {
    type: 'enum',
    values: ['basic', 'premium', 'enterprise'] as const,
    default: 'basic'
  },

  // Custom validation
  MAX_CONNECTIONS: {
    type: 'integer',
    validate: (value) => value > 0 && value <= 1000,
    default: 100
  },
})

That's it. Everything is typed, validated, and your app crashes at startup if anything is wrong.

Breaking Changes

None. All new features are additive and backward compatible.

Install

npm install envconfig-kit@0.2.0

Or update existing:

npm install envconfig-kit@latest

What's Next

Still zero dependencies. Still ~3KB. Still works with CommonJS and ESM.

GitHub | npm

Dead-Simple CLI Uptime Monitor – No SaaS, POST Support, CI/CD Ready (Open Source)

Chintan Shah — Fri, 23 Jan 2026 18:19:12 +0000

I kept spinning up heavy monitoring dashboards or paying monthly for SaaS tools just to check if a few personal APIs were still breathing. Most tools were massive overkill for what I actually needed.

So I built upstatus — a tiny CLI uptime monitor that lives in your terminal. It checks URLs (including POST health endpoints), tracks response times and uptime percentages, and exports results. No accounts, no dashboards, pure local power.

Why I Built This

I monitor a handful of personal APIs and side-project backends. I needed a "terminal-first" tool more capable than a curl script:

POST/PUT support with bodies for auth/health checks
"Degraded" status to catch slow responses before they fail completely
Easy JSON/CSV export for reports or sharing
Script-friendly output to fail CI builds on uptime drops
Lightweight with zero external service dependencies

Existing tools were either bloated (dashboards I never used) or subscription-based. upstatus is TypeScript-native, solves the repetitive pains I kept hitting, and stays small.

Features at a Glance

HTTP methods: GET, POST, PUT, PATCH, DELETE
Request bodies (CLI via -b) and headers (programmatic API)
Response time + uptime % tracking
Statuses: up / degraded / down
Retry with exponential backoff (configurable)
Degraded threshold (default 2000ms, customizable)
Clean, colorful terminal output (powered by logfx)
JSON/CSV export on exit (Ctrl+C)
--json mode for scripts/CI
Programmatic API for Node.js/TS apps

Quick Start

Try it instantly without installing:

npx upstatus https://api.github.com

Or install globally:

npm install -g upstatus

# Basic check
upstatus https://api.example.com

# Multiple + custom interval (default 30s)
upstatus https://api1.com https://api2.com -i 15

# POST with body
upstatus https://api.example.com/health -m POST -b '{"probe":"full"}'

# Degraded >800ms + export
upstatus https://slow-api.com -d 800 --export json -o uptime-log.json

Example Output

✅ https://api.example.com ........ 187ms (99.8% uptime)
⚠️ https://slow-api.com ......... 1450ms (98.7% uptime) [degraded]
🔴 https://down.example.com ..... DOWN (last check failed)

CI/CD & Scripting

Use JSON mode in pipelines:

upstatus https://prod-api.com --json > status.json

# Fail build if uptime < 99%
if jq -e '.uptime < 99' status.json; then 
  echo "Uptime requirement not met!" && exit 1 
fi

Or use it as a library (full config including headers, timeouts, retries):

import { MonitorManager } from 'upstatus';

const manager = new MonitorManager();

manager.add({
  url: 'https://api.example.com',
  interval: 30,
  method: 'POST',
  body: JSON.stringify({ check: 'deep' }),
  headers: { 'Authorization': 'Bearer token' },
  degradedThreshold: 1500,
  expectedStatus: [200, 201],
  timeout: 10000,
  maxRetries: 2,
  retryDelay: 1000,
});

manager.startAll();

console.log(manager.getMonitor('api.example.com')?.getStats());

Under the Hood

Built with TypeScript + Node.js:

Built-in Node HTTP for requests (no heavy deps)
Custom interval + Ctrl+C handling for clean exports
Colorful output via logfx
Zero deps beyond basics, MIT licensed, small core

Status Meanings

Status	Meaning
✅ up	Expected status, under threshold
⚠️ degraded	Expected status, but too slow
🔴 down	Timeout, error, wrong status, etc.

Try It Out

Repo: github.com/chintanshah35/upstatus
npm: npmjs.com/package/upstatus

If you're tired of heavy monitoring for simple needs — especially POST endpoints or quick CI checks — give it a spin. Star it if it helps, open issues/PRs for features, or just let me know what you think.

What simple monitoring hacks do you use in your terminal or CI? Or are you also fed up with bloated uptime tools? Drop your thoughts below 👇

logfx v0.5.0: From Dev Tool to Production Logger

Chintan Shah — Tue, 20 Jan 2026 02:52:46 +0000

Last month, I shared logfx. Since then, I've been using it in my projects and kept adding features I needed. v0.5.0 is the result - 15+ new features that make it production-ready.

Express Middleware

This was the most requested feature. Automatic request logging with timing and request IDs:

import express from 'express'
import { expressLogger } from 'logfx'

const app = express()
app.use(expressLogger())

app.get('/users', (req, res) => {
  req.log.info('Fetching users', { userId: req.query.id })
  res.json({ users: [] })
})

Output:

💡 INFO [http] Incoming request { method: 'GET', path: '/users', requestId: 'abc123' }
💡 INFO [http] Fetching users { userId: '42' }
💡 INFO [http] Request completed { method: 'GET', path: '/users', status: 200, durationMs: 45 }

You get req.log scoped to each request, automatic timing, and request IDs for tracing. Status codes automatically set the log level (5xx = error, 4xx = warn).

Options:

Skip routes (health checks)
Custom request ID extraction
Configurable headers

Fastify and Next.js Too

// Fastify
import Fastify from 'fastify'
import { fastifyLogger } from 'logfx'

const app = Fastify()
app.register(fastifyLogger())

app.get('/api/data', async (request, reply) => {
  request.log.info('Processing')
  return { ok: true }
})

// Next.js
import { withLogging } from 'logfx'

export default withLogging(async (req, res) => {
  req.log.info('API called', { path: req.url })
  res.json({ ok: true })
})

Color Themes

Added dracula and monokai themes because the default colors weren't great on every terminal:

import { createLogger } from 'logfx'

const log = createLogger({ theme: 'dracula' })
// or 'monokai', 'default'

log.info('Themed output')
log.success('Looks great')
log.error('Easy to spot')

Makes logs easier to scan when you're debugging at 2am.

File Rotation

Logs now rotate automatically when they hit a size limit:

import { createLogger, transports } from 'logfx'

const log = createLogger({
  transports: [
    transports.file({
      path: './logs/app.log',
      rotation: {
        maxSize: '10mb',
        maxFiles: 5,
        compress: true  // gzip old files
      }
    })
  ]
})

Creates app.log.1, app.log.2, etc. Old files get gzipped. No more disk space issues.

Issue Detection

This catches mistakes I kept making:

const log = createLogger({ detectIssues: true })

log.info('User data', { data: undefined })
// ⚠️ Warning: undefined value in log data

log.info('Auth', { password: 'secret123' })
// ⚠️ Warning: potential password in log data

Only runs in development. Saved me from logging passwords to production a few times already.

Format Auto-Detection

Pretty output in dev, JSON in production. No config needed:

// Development (NODE_ENV=development)
log.info('Server started')
// 💡 INFO Server started (pretty, colored)

// Production (NODE_ENV=production)
log.info('Server started')
// {"timestamp":"2026-01-19T...","level":"info","message":"Server started"}

Request ID Tracking

Built-in for tracing requests across your logs:

const log = createLogger({ requestId: 'req-123' })
log.info('Processing payment')
// Includes requestId in output for correlation

Great for debugging issues across microservices.

Better Error Serialization

Stack traces are readable in dev, structured in prod:

try {
  await connectDatabase()
} catch (error) {
  log.error('Connection failed', error)
}

Development output:

🔴 ERROR Connection failed
Error: Timeout
    at Database.connect (/app/db.js:45:11)
    at Server.start (/app/server.js:12:5)

Production output:

{
  "timestamp": "2026-01-19T13:45:00.000Z",
  "level": "error",
  "message": "Connection failed",
  "error": {
    "message": "Timeout",
    "stack": "Error: Timeout\n    at Database.connect...",
    "code": "ETIMEDOUT"
  }
}

Service Context

Automatically reads service metadata from environment:

// Reads SERVICE_NAME, SERVICE_VERSION, NODE_ENV
const log = createLogger()
log.info('Started')

// Output includes:
// {"service":"my-api","version":"1.0.0","environment":"production",...}

Structured JSON Output

Production-ready JSON format for log aggregation tools:

const log = createLogger({ format: 'json' })
log.info('User login', { userId: 123 })
// {"timestamp":"2026-01-19T...","level":"info","message":"User login","data":{"userId":123}}

Works with Datadog, Splunk, ELK stack, and other log aggregation tools.

Field Redaction

Hide sensitive data automatically:

const log = createLogger({
  redact: {
    fields: ['password', 'token', 'apiKey'],
    replacement: '***REDACTED***'
  }
})

log.info('User login', { 
  username: 'john', 
  password: 'secret123' 
})
// Output: { username: 'john', password: '***REDACTED***' }

Log Sampling

Reduce log volume in high-traffic scenarios:

const log = createLogger({
  sampling: {
    debug: 0.1,  // 10% of debug logs
    info: 0.5,   // 50% of info logs
    error: 1.0   // 100% of errors (always log)
  }
})

Useful when you're getting millions of requests.

Async Logging

Buffer and batch logs for better performance:

const log = createLogger({
  async: true,
  buffer: {
    size: 100,        // flush after 100 logs
    flushInterval: 1000  // or every 1 second
  }
})

Prevents logging from blocking your event loop.

Multiple Transports

Send logs to different destinations simultaneously:

import { createLogger, transports } from 'logfx'

const log = createLogger({
  transports: [
    transports.console({ format: 'pretty' }),
    transports.file({ 
      path: './logs/app.log',
      format: 'json'
    }),
    transports.webhook({ 
      url: 'https://logs.example.com/ingest',
      batchSize: 10
    })
  ]
})

Webhook Transport

Send logs to remote endpoints:

transports.webhook({
  url: 'https://logs.example.com',
  method: 'POST',
  headers: { 'Authorization': 'Bearer token' },
  batchSize: 10,
  flushInterval: 5000
})

Great for custom log aggregation services or alerting systems.

Environment Detection

Automatically adapts to your environment:

CI/CD: Auto-disables colors
TTY Detection: Only shows colors in terminals
NO_COLOR/FORCE_COLOR: Respects standard env vars
NODE_ENV: Auto-switches format (pretty in dev, JSON in prod)

Complete Feature List

Core Logging:

5 log levels (debug, info, success, warn, error)
Namespaced loggers
Colorful output with emojis
Timestamps
Context metadata

Production Features:

Format auto-detection (pretty/JSON)
Structured JSON output
Request ID tracking
Service context
Error serialization with stack traces
Field redaction
Log sampling
Async buffered logging

Transports:

Console transport
File transport with rotation
Webhook transport
Multiple transports simultaneously

Framework Integration:

Express middleware
Fastify plugin
Next.js API middleware

Developer Experience:

Color themes (default, dracula, monokai)
Issue detection (undefined values, passwords)
Environment detection (CI/CD, TTY)
TypeScript support
Zero dependencies

Why I Built This

I got tired of choosing between pretty logs in dev and structured logs in prod. Most loggers force you to pick one. logfx does both automatically.

Also wanted something that works in browsers and Node without extra config. Zero dependencies means no supply chain issues.

The middleware was the big one though. Every project needs request logging and I was copy-pasting the same code everywhere.

What Makes logfx Different

Works everywhere

One logger for your entire stack:

Node.js, Bun, Deno
Browsers (Chrome, Firefox, Safari)
Express, Fastify, Next.js
Edge runtimes (coming in v0.6.0)

Zero dependencies

No supply chain risk. No version conflicts. No security audits for logging dependencies.

Lightweight but feature-complete

~11KB gzipped (46KB uncompressed)
Full TypeScript support
117 passing tests
All the features you need, none you don't

Installation

npm install logfx

Quick Start

import { log } from 'logfx'

log.debug('Debugging info', { detailed: true })
log.info('Server started', { port: 3000 })
log.success('User created')
log.warn('Memory usage high', { usage: '85%' })
log.error('Connection failed', new Error('Timeout'))

Output:

🔍 DEBUG   Debugging info { detailed: true }
💡 INFO    Server started { port: 3000 }
✅ SUCCESS User created
⚠️ WARN    Memory usage high { usage: '85%' }
🔴 ERROR   Connection failed Error: Timeout
    at ...

Try It

npm install logfx@0.5.0

Links:

GitHub: github.com/chintanshah35/logfx
npm: npmjs.com/package/logfx
Release Notes: v0.5.0 Release
Original Post: Your console.log deserves better

Make your app crash at startup, not in production

Chintan Shah — Thu, 15 Jan 2026 06:13:30 +0000

2am. Slack notification. Production app is down.

The error? Cannot read property 'split' of undefined

Turns out ALLOWED_ORIGINS wasn't set in production. The app started fine. Health checks passed. Then the first CORS request came in and crashed the server.

Or that time STRIPE_SECRET_KEY had a trailing space from copy-paste. App started. First payment request? Failed. Took 30 minutes to figure out.

Or when someone set ENABLE_CACHING=false as a string, but the code checked if (config.ENABLE_CACHING) - string "false" is truthy, so caching stayed on.

This stuff happens constantly.

The real problem isn't missing env vars

It's that your app doesn't know they're wrong until it tries to use them.

const port = process.env.PORT || 3000
const apiKey = process.env.API_KEY
const enableCache = process.env.ENABLE_CACHING
const origins = process.env.ALLOWED_ORIGINS?.split(',')

// App starts fine
// apiKey is undefined
// enableCache is the string "false" (truthy!)
// origins will crash when undefined
// Everything looks good... until it's not

Your app starts. Health checks pass. Then 5 minutes later, it tries to call the API and crashes because apiKey is undefined.

Or your boolean flag is the string "false" but your code checks if (enableCache) - string "false" is truthy, so the logic is backwards.

Or someone has a trailing space in STRIPE_KEY=" sk_live_123 " and all payment requests fail with cryptic auth errors.

Fail fast, not later

What if your app refused to start unless everything was valid?

import { env } from 'envconfig-kit'

const config = env({
  PORT: { type: 'number', default: 3000 },
  API_KEY: { type: 'string' },
  DATABASE_URL: { type: 'url' },
})

Now if API_KEY is missing or DATABASE_URL isn't a valid URL, your app won't start at all.

❌ Environment validation failed:

  API_KEY: Missing required environment variable
  ➜ Fix: Add to .env file
    Example: API_KEY=your-value-here

  STRIPE_SECRET_KEY: Value contains leading/trailing whitespace
  ➜ Fix: Remove extra spaces
    Current: " sk_live_123 "
    Expected: "sk_live_123"

Crash at startup, not during runtime. Get useful error messages, not undefined is not a function.

What you get

Type safety

config.PORT       // number
config.API_KEY    // string
config.DEBUG      // boolean
config.REDIS_URL  // string | undefined (if optional)

TypeScript knows the exact types. No more process.env.PORT as number.

Built-in .env loading

No need for dotenv. Automatically loads from .env, .env.local, .env.production, etc.

const config = env({ 
  PORT: { type: 'number' } 
})
// Just works. No extra setup.

Transform values

Parse arrays, trim whitespace, normalize URLs:

const config = env({
  ALLOWED_ORIGINS: {
    type: 'string',
    transform: (value) => value.split(',').map(s => s.trim())
  },
  API_URL: {
    type: 'url',
    transform: (value) => value.replace(/\/$/, '') // remove trailing slash
  }
})

config.ALLOWED_ORIGINS // ['http://localhost:3000', 'https://app.com']

Validation types that matter

string, number, boolean - the basics
url - validates protocol, catches localhost and http:/missing-slash
email - actual email validation
port - number between 0-65535

Real example

Here's what a typical API config looks like:

import { env } from 'envconfig-kit'

export const config = env({
  // Server
  PORT: { type: 'port', default: 3000 },
  HOST: { type: 'string', default: '0.0.0.0' },
  NODE_ENV: { type: 'string', default: 'development' },

  // Database
  DATABASE_URL: { type: 'url' },

  // Redis (optional)
  REDIS_URL: { type: 'url', optional: true },

  // API Keys
  API_KEY: { type: 'string' },
  JWT_SECRET: { type: 'string' },

  // External services
  STRIPE_KEY: { type: 'string' },
  SENDGRID_KEY: { type: 'string' },

  // CORS
  ALLOWED_ORIGINS: {
    type: 'string',
    default: 'http://localhost:3000',
    transform: (value) => value.split(',')
  },

  // Feature flags
  ENABLE_ANALYTICS: { type: 'boolean', default: false },
})

// Now everything is typed and validated
// App won't start if anything is wrong

CLI tools

Generate .env.example for your team:

npx envconfig-kit generate

Validate before deployment:

npx envconfig-kit check

Health check:

npx envconfig-kit doctor

Install

npm install envconfig-kit

Zero dependencies. 3KB minified. Works with CommonJS and ESM.

Stop debugging undefined errors at 2am. Make your app fail fast with clear error messages.

GitHub | npm

Introducing handlejson - Safe JSON Parsing Without the try-catch Spam

Chintan Shah — Tue, 06 Jan 2026 06:46:33 +0000

I built a tiny library called handlejson because I got tired of writing try-catch blocks for JSON.parse everywhere. Just shipped v0.2.0 today with some features I actually needed in real projects.

The Problem

How many times have you written this?

let data
try {
  data = JSON.parse(str)
} catch {
  data = null
}

I wrote it hundreds of times. localStorage.getItem? try-catch. API response? try-catch. User input? try-catch. Every single time.

It works, but it's verbose. And there are other annoyances too - JSON.stringify throws on circular references, Date objects serialize to empty objects (useless), and there's no easy way to validate structure.

What handlejson Does

It's basically a wrapper around native JSON functions, but with all the annoying edge cases handled:

import { parse, stringify } from 'handlejson'

// Safe parsing - returns null on error, no try-catch needed
const user = parse(localStorage.getItem('user'))
const config = parse(invalidJson, { default: {} })

// Handles circular refs automatically
const obj = { a: 1 }
obj.self = obj
stringify(obj)  // '{"a":1,"self":"[Circular]"}'

// BigInt support
stringify({ value: BigInt(123) })  // '{"value":"123n"}'

That's the basics. Small, simple, just makes JSON parsing less annoying.

New in v0.2.0

I released v0.1.0 a while back with the core functionality. Today I'm shipping v0.2.0 with three features I kept needing:

Date Handling

This was the most annoying one. Every API response with dates means writing custom revivers to convert ISO strings back to Date objects:

// The old way
const user = parse(jsonString, {
  reviver: (key, value) => {
    if (key.endsWith('At') && typeof value === 'string') {
      const date = new Date(value)
      return isNaN(date.getTime()) ? value : date
    }
    return value
  }
})

Now it's just:

const user = parse(jsonString, { dates: true })
// Dates are automatically converted

Same for stringifying - Date objects serialize to ISO strings instead of empty objects:

stringify({ createdAt: new Date() }, { dates: true })
// → '{"createdAt":"2023-01-01T10:00:00.000Z"}'

Saves a lot of boilerplate. I was writing that reviver logic constantly.

Schema Validation

I kept hitting bugs where API responses had wrong types. A number field coming through as a string, that sort of thing. Instead of writing custom validation each time, you can pass a schema:

const schema = {
  name: 'string',
  age: 'number',
  active: 'boolean',
  address: {
    street: 'string',
    zip: 'number'
  }
}

const user = parse(apiResponse, { schema })
// Returns null if validation fails

It's not full JSON Schema (that'd be overkill), just simple type checking. The validation happens after parsing, so you get useful errors like "Field 'age': expected number, got string" instead of cryptic parse failures.

Useful for catching bugs early, especially when working with APIs you don't control.

Stream Parsing

This one's for processing large JSON files. Most projects won't need it, but if you're dealing with big datasets:

import { parseStream } from 'handlejson'

const result = await parseStream(response.body, {
  onProgress: (parsed) => console.log('Loading...'),
  onError: (err) => console.error('Error:', err)
})

if (result.complete) {
  console.log('Data:', result.data)
}

I added this because I was working on a feature that needed to process multi-MB JSON files. Loading everything into memory first wasn't ideal.

Real Example

Here's a common pattern I see (and wrote myself many times):

// Before
function loadUser() {
  const stored = localStorage.getItem('user')
  if (!stored) return null

  try {
    const parsed = JSON.parse(stored)
    if (parsed.createdAt) {
      parsed.createdAt = new Date(parsed.createdAt)
    }
    return parsed
  } catch {
    return null
  }
}

// After
function loadUser() {
  return parse(localStorage.getItem('user'), {
    default: null,
    dates: true
  })
}

Way cleaner. The new features make this even better - you can add schema validation if you want to be extra safe.

Why Build This?

There are other libraries that do similar things, but they're usually heavier or have more features than I need. I wanted something tiny that just handles the common edge cases.

It's ~2.8KB gzipped, zero dependencies, TypeScript native. Small enough that you can use it without thinking about bundle size.

Works in browser and Node.js. Same API everywhere.

Should You Use It?

If you're doing a lot of JSON parsing and tired of try-catch blocks everywhere, maybe. It's not revolutionary - just a quality-of-life improvement.

If you're happy with native JSON and don't mind the try-catch boilerplate, stick with that. No need to add dependencies for no reason.

But if you do a lot of JSON parsing (localStorage, API responses, user input), it cleans up your code quite a bit.

Try It

npm install handlejson

The v0.2.0 release is on npm now. If you want to try it, that's the latest version with all the new features.

All the new stuff is opt-in, so existing code using handlejson (if anyone is) won't break. The new features are optional options.

What do you think? Do you write try-catch blocks for JSON.parse a lot, or am I the only one bothered by this? Always curious what other developers think about this stuff.

Your console.log deserves better

Chintan Shah — Thu, 18 Dec 2025 22:11:14 +0000

I kept copy-pasting the same logging code into every new project. Eventually I just packaged it up. It's called logfx — a tiny library that makes your console output a bit easier to read.

The problem I kept running into

console.log('DEBUG: starting process')
console.log('INFO: connected')
console.log('ERROR: something broke')

It works, but it's hard to scan. Everything looks the same.

A small improvement

import { log } from 'logfx'

log.debug('Starting process')
log.info('Connected')
log.error('Something broke')

Output:

🔍 DEBUG   Starting process
💡 INFO    Connected
🔴 ERROR   Something broke

Just a bit of color and structure — but it makes a difference when you're debugging.

When logfx might help

logfx is a lightweight option for when you want:

Something simple — no config, just import and go
Readable dev logs — easier to scan in your terminal
A small footprint — ~2KB gzipped, zero dependencies
Quick projects — prototypes, scripts, side projects
Universal support — Node.js, browsers, Bun, Deno

What's inside

Lightweight

~2KB gzipped with zero dependencies. Tried to keep it minimal.

Nice defaults

Colors and structure out of the box — no setup needed.

TypeScript support

Built in TypeScript with full type inference.

Smart log levels

Debug logs auto-hide in production.

Transports

Console, file, webhook — in case you need to send logs somewhere.

A few examples

Namespaced loggers:

import { logger } from 'logfx'

const auth = logger('auth')
const db = logger('db')

auth.success('User logged in')  
// ✅ SUCCESS [auth] User logged in

db.info('Query executed')
// 💡 INFO [db] Query executed

Timers:

import { time, timeEnd } from 'logfx'

time('api-call')
await fetch('/data')
timeEnd('api-call')  
// ⏱️ api-call: 245.32ms

Pretty boxes:

import { box } from 'logfx'

box('Server running on port 3000', { title: 'Ready' })

╭─ Ready ─────────────────────────╮
│  Server running on port 3000    │
╰─────────────────────────────────╯

Tables:

import { table } from 'logfx'

table([
  { name: 'John', role: 'Admin' },
  { name: 'Jane', role: 'User' },
])

┌─────────┬─────────┐
│ name    │ role    │
├─────────┼─────────┤
│ John    │ Admin   │
│ Jane    │ User    │
└─────────┴─────────┘

JSON output:

import { createLogger, transports } from 'logfx'

const log = createLogger({
  transports: [transports.console({ format: 'json' })]
})

log.info('Request', { method: 'GET', path: '/api' })
// {"timestamp":"2025-12-18T...","level":"info","message":"Request","method":"GET","path":"/api"}

Try it out

npm install logfx

Hello, dev.to! I'm Chintan Shah 👋

Chintan Shah — Thu, 18 Dec 2025 05:27:19 +0000

Excited to finally join the dev.to community! Here's a bit about me.

Who am I?

I'm Chintan — a Senior Software Engineer based in Virginia. I've been building web applications for about 9 years now, and somehow I still get excited when a tricky bug finally clicks.

I have a Master's in Computer Science, but honestly, most of what I know came from breaking things in production and frantically Googling at 2am (kidding... mostly).

The journey so far

I've been lucky to work across some really different industries — healthcare, insurance, digital marketing, and travel. Each one taught me something different.

Healthcare taught me that your code actually matters — when clinicians rely on your software, you think twice before shipping. Insurance showed me what high-volume really means — millions of transactions, peak hours that can make or break systems. Marketing was all about speed and iteration. Travel? Resilience. Nothing prepares you for traffic spikes like holiday booking season.

These days, I'm leading projects and doing the full-stack thing — React and TypeScript on the frontend, Scala and Node.js on the backend, with a healthy dose of AWS thrown in.

What gets me excited

I genuinely enjoy the craft of building software. Whether it's architecting a micro frontend, setting up a clean CI pipeline, or making an app actually work with a screen reader — I'm into it.

Web accessibility is a big one for me. It's not a checkbox, it's the baseline. I've spent a lot of time with WCAG, screen readers, and making sure the things I build work for everyone.

Also, I have a soft spot for developer tooling. There's something satisfying about building tools that make other engineers' lives easier.

Outside of work

I tinker with open source and recently published a couple of npm packages. logfx is a tiny, colorful logging library with emojis, namespaces, and transports — because console.log deserves better. And upstatus is a simple CLI for uptime monitoring when you just need something quick and lightweight.

Building small, focused utilities is my kind of side project.

Why I'm here

I want to write more. Document what I learn. Share the random things I figure out. Maybe help someone avoid the same mistakes I made.

Topics I'll probably write about:

React patterns and frontend architecture
Full-stack development stories
Accessibility in practice
The occasional rant about something that took way too long to debug

Say hi!

Find me on GitHub or LinkedIn.

Always down to chat about code, career stuff, or swap stories about that one bug that haunted you for days.

See you around! 🙌