Forem: Reza Owliaei

Simplifying Code Quality with a Unified Biome Configuration

Reza Owliaei — Tue, 05 Aug 2025 11:37:56 +0000

Tired of juggling ESLint, Prettier, and import sorters just to keep your code clean? You’re not alone.

Modern development shouldn’t be slowed down by a fragmented toolchain.

This post introduces Biome: a fast, modern alternative to the legacy combo of ESLint + Prettier + plugins. With just one tool, one config, and one command, Biome handles formatting, linting, and organizing imports—without the overhead.

This guide is for developers looking to simplify tooling, increase speed, and write consistent code with fewer tools.

What Is Biome?

Biome is a single, unified CLI tool (written in Rust) that replaces:

ESLint + plugins
Prettier
lint-staged and husky scripts
Sorting tools like eslint-plugin-import

It provides:

Formatting
Linting (both bug-catching and style)
Import sorting
Git-aware checks (--staged, --changed, --since)
Fast performance out of the box

You configure it all in one place: biome.json.

Installing Biome

Install Biome using your preferred package manager:

Using Bun

bun add -D -E @biomejs/biome
bunx @biomejs/biome init

Using npm

npm i -D -E @biomejs/biome
npx @biomejs/biome init

This will create a base biome.json config in your project.

Biome in Action

Here are the main commands you’ll use:

biome check – runs formatting, linting, and import sorting together. Use --write to apply fixes.
biome format – formats only.
biome lint – lints only.
biome ci – read-only, used in CI pipelines.
Use --staged, --changed, or --since=origin/main with any command to scope it to Git changes.

Why I Chose Biome (Configuration Philosophy)

Biome solves real-world pain points from the old ecosystem:

One tool, zero glue code. No more connecting Prettier to ESLint with plugins and linters to formatters.
Catch real bugs, not nitpicks. Biome includes useful rules like:

noUndeclaredVariables
noDoubleEquals
noAccumulatingSpread

Flexible rule levels. You can mark style rules as warnings and true problems as errors.
Context-aware overrides. Need to allow console.log in tests or default export in Next.js pages? Overrides make that easy.
Modern tooling mindset. Supports monorepos, CI-first workflows, Git-aware scanning, and blazing speed from Rust.

My Biome Config (from real projects)

You can find the complete, production-ready config I use here:

🔗 View the biome.json on GitHub Gist

Highlights include:

Tabs instead of spaces (accessibility-friendly)
100 character line width
Git-aware scanning via vcs config
Overrides for:
- test files (console.log allowed)
- Next.js layouts/pages (default export allowed)
- config files (vite.config.ts, etc.)
Global test functions like describe, it, expect, etc.

Feel free to copy and adapt it.

Suggested `package.json` Scripts

For smooth local dev experience:

{
  "scripts": {
    "check": "biome check .",
    "check:fix": "biome check --write .",
    "lint": "biome lint .",
    "lint:fix": "biome lint --write .",
    "fmt": "biome format .",
    "fmt:fix": "biome format --write .",
    "check:staged": "biome check --staged --write"
  }
}

These commands let you quickly check everything or apply fixes, locally or in CI.

Pre-commit Hook with Husky

To prevent broken code from being committed, run Biome only on staged files:

npx husky-init && npm install
echo 'biome check --staged --write' > .husky/pre-commit
chmod +x .husky/pre-commit

This ensures formatting, import order, and critical lint rules are enforced before every commit.

CI Integration (GitHub Actions)

Use this to run Biome on pull requests and pushes:

name: code-quality
on: [push, pull_request]

jobs:
  biome:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: biomejs/setup-biome@v2
      - run: biome ci --changed

This checks only files changed in the PR, keeping CI fast and focused.

Editor Integration (VS Code)

Install the Biome VS Code Extension, then add the following to .vscode/settings.json:

{
  "editor.defaultFormatter": "biomejs.biome",
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
    "source.organizeImports.biome": "explicit",
    "source.fixAll.biome": "explicit"
  }
}

This enables automatic formatting, import sorting, and rule fixes on save.

Monorepo Support (Nx / Turborepo)

Biome supports nested configuration out of the box.

Example setup:

At the root (`biome.json`)

{
  "linter": { "rules": { "recommended": true } },
  "formatter": { "lineWidth": 100 }
}

Inside a package (e.g., `packages/web/biome.json`)

{
  "extends": ["//"],
  "root": false
}

This allows per-package customizations while inheriting defaults from the root.

Final Thoughts

Biome is the next step in code quality:

No more endless plugins
No more syncing configs across tools
Just one file and one command to format, lint, and sort

For developers starting fresh, Biome offers a clean, modern, and efficient approach to code quality—and makes legacy stacks feel like a thing of the past.

Want help adopting Biome in your project? Have questions or examples to share? Let me know in the comments or reach out directly.

Seccomp in Docker: Advanced System Call Filtering for a Hardened Container Runtime

Reza Owliaei — Sat, 12 Jul 2025 09:39:57 +0000

Introduction

As modern applications increasingly run in containers, the security of the container runtime becomes paramount. One of the most powerful—but often overlooked—mechanisms for hardening Linux-based containers is seccomp (Secure Computing Mode). Seccomp enables fine-grained filtering of system calls, allowing you to limit what your applications can ask of the kernel.

In this post, we’ll go beyond surface-level explanations and dive into how seccomp works, why it matters in real-world production environments, and how to leverage it effectively using Docker. You’ll learn how to inspect, customize, and enforce syscall-level security, ensuring containers operate with the least privilege necessary.

What Is Seccomp?

Seccomp is a Linux kernel feature that allows processes to restrict the system calls (syscalls) they are permitted to make. By default, a Linux process can invoke hundreds of syscalls. However, most applications use only a small subset.

By blocking unnecessary syscalls, seccomp:

Reduces the kernel attack surface
Prevents certain classes of container breakout exploits
Enforces least privilege at the syscall level

This is especially important in containers, where applications run in shared-kernel environments. Even with other isolation mechanisms like namespaces and cgroups in place, unfiltered access to the syscall interface can lead to privilege escalation or host compromise.

Seccomp Operating Modes

Seccomp supports two modes:

1. Strict Mode

The original implementation (enabled via prctl) restricts a process to only four syscalls:

read(2)
write(2)
_exit(2)
sigreturn(2)

This mode is rarely used outside of specific academic or embedded contexts due to its extreme limitations.

2. Filter Mode (seccomp-bpf)

The modern and practical variant uses Berkeley Packet Filter (BPF) programs to evaluate syscalls at runtime. You can allow, block, log, or return errors based on syscall type, arguments, and context. This is the mode used by Docker and Kubernetes.

Why Seccomp Matters for Container Security

In containerized environments, the kernel is shared among containers and the host. A compromised container that can execute privileged syscalls becomes a potential entry point to the entire system. Seccomp provides:

Granular Syscall Control: Limit actions like creating raw sockets, mounting filesystems, or spawning new namespaces.
Exploit Mitigation: Many Linux kernel vulnerabilities rely on specific syscalls. Blocking them disrupts exploit chains.
Defense in Depth: Adds a syscall-level layer to existing security features like AppArmor, SELinux, and user namespaces.
Compliance and Auditability: You can demonstrate precise control over application behavior down to the syscall level.

How Docker Uses Seccomp

Docker applies a default seccomp profile to all containers unless overridden. This profile is maintained by the Moby project and is reasonably conservative: it blocks approximately 44 syscalls out of over 300 available on a typical x86_64 system.

Blocked syscalls include:

keyctl (used for kernel key management)
add_key, request_key
ptrace
mount (unless explicitly enabled)

The default profile allows safe defaults for most containerized workloads while blocking dangerous or rarely-used syscalls.

You can view the official profile here.

Anatomy of a `seccomp.json` Profile

A seccomp profile is a JSON document that defines syscall rules for a process. Key fields include:

defaultAction

What to do with syscalls that aren’t explicitly listed. Common options:

SCMP_ACT_ERRNO: Return a permission error
SCMP_ACT_KILL: Immediately terminate the process
SCMP_ACT_ALLOW: Allow the syscall
SCMP_ACT_TRACE, SCMP_ACT_LOG: Advanced debugging options

architectures

Specifies applicable architectures. Typical values:

["SCMP_ARCH_X86", "SCMP_ARCH_X86_64", "SCMP_ARCH_X32"]

syscalls

An array defining syscall rules, where each item includes:

name (or names): syscall name(s)
action: what to do if called
args (optional): match syscall arguments for conditional rules

Minimal example:

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "architectures": ["SCMP_ARCH_X86_64"],
  "syscalls": [
    {
      "name": "mkdir",
      "action": "SCMP_ACT_ERRNO",
      "args": []
    }
  ]
}

This will deny the mkdir syscall for all processes using the profile, regardless of arguments.

Using Custom Seccomp Profiles in Docker

You can supply your own seccomp profile when running containers:

docker run \
  --security-opt seccomp=/path/to/custom-seccomp.json \
  your-image

To disable seccomp entirely (not recommended unless debugging):

docker run --security-opt seccomp=unconfined your-image

Example: Blocking Network-Related Syscalls

Here’s a custom profile that blocks network access by denying socket, connect, and mkdir:

{
  "defaultAction": "SCMP_ACT_ERRNO",
  "architectures": ["SCMP_ARCH_X86_64"],
  "syscalls": [
    { "name": "socket", "action": "SCMP_ACT_ERRNO" },
    { "name": "connect", "action": "SCMP_ACT_ERRNO" },
    { "name": "mkdir", "action": "SCMP_ACT_ERRNO" }
  ]
}

Applying this profile to a container means:

ping, curl, or anything that uses sockets will fail
mkdir operations will also fail, even as root
All other syscalls will return permission errors unless explicitly allowed

Best Practices for Seccomp Usage

Start with the default profile and incrementally restrict based on runtime analysis.
Use syscall tracing tools like strace, sysdig, or bpftrace to identify which syscalls your app needs.
Don’t over-optimize early. Avoid blocking syscalls your app might need during boot or init.
Version and audit your profiles alongside your infrastructure code.
Combine seccomp with other controls like AppArmor, SELinux, cgroups, and capabilities for layered defense.

Advanced: Conditional Filtering with

args

You can apply fine-grained rules using the args field. For example, allow the socket syscall only for TCP connections (AF_INET, SOCK_STREAM):

{
  "name": "socket",
  "action": "SCMP_ACT_ERRNO",
  "args": [
    {
      "index": 0,
      "value": 2,
      "op": "SCMP_CMP_EQ"
    },
    {
      "index": 1,
      "value": 1,
      "op": "SCMP_CMP_EQ"
    }
  ]
}

This filters the syscall only when both arguments match the expected values for an IPv4 TCP socket.

Seccomp provides syscall-level control over application behavior, reducing attack surface and enforcing least privilege. In a containerized world where isolation boundaries are thinner than traditional virtual machines, mechanisms like seccomp are essential for building secure, production-grade systems.

Whether you’re securing microservices, isolating CI pipelines, or just building better defaults, understanding and applying seccomp is an important step in your journey toward mature container security.

The Battle of Node.js Testing: When Switching Back to Mocha Seemed Like easier

Reza Owliaei — Tue, 03 Sep 2024 16:25:42 +0000

Introduction

Testing is essential in software development, but it often feels like a battleground. I recently faced a challenging issue while working with the native Node.js test runner, specifically when testing asynchronous processes related to PostgreSQL and EventStoreDB. My frustration peaked several times, nearly pushing me to switch back to the ever-reliable Mocha. I thought my choice of using the native solution was the problem. As it turned out, the real issue wasn't the test framework itself but rather how I managed open resources.

The Setup

I had been working on a microservices project where I used Event Store to implement event sourcing, which was a core part of the system's architecture. Naturally, my test suite needed to interact with the Event Store to verify that events were correctly appended, read, and handled.

Choosing Node.js’s native test runner (node:test) seemed modern and efficient, mainly because it was lightweight and didn’t require extra dependencies. I set up my tests using the EventStoreDBClient from the @eventstore/db-client library. Here’s a simplified version of what my test setup looked like:

describe("Event Store", async () => {
  it("should connect to the eventStore and perform operations", async () => {
    const result = await client.appendToStream("TEST_STREAM", testEventJson);
    expect(result.success).to.be.true;
  });
});

The Issue

Initially, everything seemed fine when I ran the tests. However, I soon noticed that the test runner didn't exit after the tests completed. The test suite would pass, but the process kept running, causing intermittent hangs.

I tried various approaches: using .then() and .finally(), implementing try/catch blocks, working with done(), and even using await directly in the it block. Despite all these attempts, the problem persisted. The frustration tempted me to revert to Mocha—a framework that had never let me down.

The Discovery

At this point, I took a step back and considered what could be causing the test runner process to hang. My past experience with databases and file handles reminded me that open connections often cause Node.js processes to hang, waiting for those connections to close.

This realization prompted me to review my resource management. I discovered that the EventStoreDBClient instance needed to be properly disposed of after each test run. While I had an after hook to dispose of the client, I hadn’t ensured that all resources were being closed rigorously.

The Fix

To address the issue, I made sure to explicitly call the dispose() method on the Event Store client after the tests had finished. This ensured that any open connections were closed, and resources were cleaned up properly:

after(async () => {
  await client.dispose(); // Ensure all resources are properly closed
});

Lessons Learned

Resource Management is Crucial: Always check for open resources, such as database connections, file handles, or network connections. Failing to properly dispose of these can cause tests to hang or fail intermittently.
Don’t Blame the Framework Too Quickly: It’s tempting to blame the testing tool when things go wrong. However, the issue often lies within the implementation. Understanding the tools and properly managing resources can solve many problems.

Conclusion

Using the native Node.js test runner was a valuable learning experience. Although the temptation to revert to Mocha was strong, resolving the resource management issue highlighted the importance of proper setup and teardown processes in automated testing. Ultimately, it’s not about the tool you choose but how effectively you use it. Properly managing resources, understanding the framework, and thorough testing practices will lead to a more stable and reliable testing environment.

Forem: Reza Owliaei

Simplifying Code Quality with a Unified Biome Configuration

What Is Biome?

Installing Biome

Using Bun

Using npm

Biome in Action

Why I Chose Biome (Configuration Philosophy)

My Biome Config (from real projects)

Suggested package.json Scripts

Pre-commit Hook with Husky

CI Integration (GitHub Actions)

Editor Integration (VS Code)

Monorepo Support (Nx / Turborepo)

At the root (biome.json)

Inside a package (e.g., packages/web/biome.json)

Final Thoughts

Seccomp in Docker: Advanced System Call Filtering for a Hardened Container Runtime

Introduction

What Is Seccomp?

Seccomp Operating Modes

1. Strict Mode

2. Filter Mode (seccomp-bpf)

Why Seccomp Matters for Container Security

How Docker Uses Seccomp

Anatomy of a seccomp.json Profile

defaultAction

architectures

syscalls

Minimal example:

Using Custom Seccomp Profiles in Docker

Example: Blocking Network-Related Syscalls

Best Practices for Seccomp Usage

Advanced: Conditional Filtering with

args

Further Reading and Tools

The Battle of Node.js Testing: When Switching Back to Mocha Seemed Like easier

Introduction

The Setup

The Issue

The Discovery

The Fix

Lessons Learned

Conclusion

Suggested `package.json` Scripts

At the root (`biome.json`)

Inside a package (e.g., `packages/web/biome.json`)

Anatomy of a `seccomp.json` Profile