Forem: MD Ehsanul Haque Rizvy

# Enforcing Code Quality on Every Commit: Husky + Biome in a Node.js/TypeScript Project

MD Ehsanul Haque Rizvy — Fri, 20 Mar 2026 20:16:12 +0000

Overview

This article documents the exact setup used in <project's>_api* — a Node.js REST API built with Express 5, Prisma, TypeScript, and Bun — to enforce linting and formatting on every Git commit using Husky and Biome.

What this covers:

How Git hooks work and why raw hooks are insufficient for team projects
How Husky solves the version-control problem for hooks
How Biome replaces ESLint + Prettier in a single tool
The complete configuration for a TypeScript/Prisma project
Extending the hook with tests once test files exist

How Git Hooks Work

Git hooks are shell scripts that Git executes automatically at specific lifecycle points. The relevant hooks for enforcing code quality are:

Hook	Trigger
`pre-commit`	Before the commit is recorded
`commit-msg`	After the commit message is written
`pre-push`	Before pushing to a remote

The pre-commit hook fires before Git writes anything. If the script exits with code 1, Git aborts the commit entirely and nothing is recorded. If it exits with code 0, Git proceeds normally.

git commit
    ↓
pre-commit script runs
    ↓
Exit 0 → commit recorded
Exit 1 → commit aborted, working tree unchanged

The Problem With Raw Git Hooks

Raw hooks live in .git/hooks/. This directory is explicitly excluded from version control — it does not exist in the remote repository and is never cloned. This means:

Every developer must manually create and configure hooks after cloning
Hook scripts cannot be peer-reviewed through PRs
Hook updates must be communicated and applied manually by every team member
CI pipelines cannot validate that hooks are properly configured

This makes raw hooks unreliable in any multi-developer context.

How Husky Solves This

Husky uses the Git configuration key core.hooksPath to redirect Git's hook resolution to a custom directory — .husky/ — which lives in the project root and is tracked by version control.

# What Husky sets under the hood
git config core.hooksPath .husky

This means the .husky/ directory is committed to the repository, versioned, code-reviewed, and cloned alongside the rest of the project.

Husky also adds a prepare lifecycle script to package.json:

{
  "scripts": {
    "prepare": "husky"
  }
}

The prepare script runs automatically when any developer runs bun install (or npm install). This means hooks are configured silently on every fresh clone — no manual steps required.

Husky characteristics:

2kb gzipped, zero runtime dependencies
Supports all 13 client-side Git hooks
Works with any package manager: npm, pnpm, yarn, bun
Compatible with monorepos and nested projects

Why Biome Instead of ESLint + Prettier

The traditional approach uses two separate tools:

ESLint for lint rules (detecting code problems)
Prettier for formatting (enforcing consistent style)

This means two config files, two separate passes, two tools to keep in sync, and occasional conflicts when ESLint formatting rules clash with Prettier's output.

Biome is a single Rust-based tool that handles both. One config file (biome.json), one command, one pass. It is significantly faster than the JavaScript-based alternatives and produces no conflicts between lint and format rules because they are handled by the same engine.

For a TypeScript project using Bun, Biome is a natural fit — it is invoked via bunx --bun @biomejs/biome which runs the native binary directly without spawning a Node.js process.

Project Setup

Installation

# Install Husky
bun add --dev husky

# Initialise — creates .husky/ and adds prepare script to package.json
bunx husky init

After initialisation, the project structure gains:

project-root/
├── .husky/
│   └── pre-commit        ← created by husky init (edit this)
├── biome.json
├── package.json          ← "prepare": "husky" added automatically
└── bun.lock

The Pre-Commit Hook

Edit .husky/pre-commit:

#!/bin/sh
bunx --bun @biomejs/biome check --write .

Flags explained:

Flag	Behaviour
`check`	Run both linter and formatter in a single pass
`--write`	Auto-apply safe fixes (formatting, trivial lint fixes)
`.`	Apply to the entire project (respects `files.includes` in biome.json)

If Biome encounters lint errors it cannot auto-fix — a real code problem — it exits with code 1 and the commit is aborted. If all checks pass (or only auto-fixable issues were found), it exits with code 0 and the commit proceeds.

Biome Configuration

The biome.json for JoseOcando_api:

{
  "$schema": "https://biomejs.dev/schemas/2.4.6/schema.json",
  "vcs": {
    "enabled": true,
    "clientKind": "git",
    "useIgnoreFile": true
  },
  "files": {
    "includes": ["**", "!!**/dist"]
  },
  "formatter": {
    "enabled": true,
    "indentStyle": "tab"
  },
  "javascript": {
    "formatter": {
      "quoteStyle": "double"
    }
  },
  "assist": {
    "actions": {
      "source": {
        "organizeImports": "off"
      }
    }
  },
  "linter": {
    "rules": {
      "suspicious": {
        "useIterableCallbackReturn": "off",
        "noExplicitAny": "off"
      },
      "style": {
        "useImportType": "off"
      },
      "correctness": {
        "noUnusedFunctionParameters": "off",
        "noUnusedImports": "off"
      }
    }
  }
}

Configuration decisions:

vcs.useIgnoreFile: true — Biome reads .gitignore and skips ignored files (e.g. node_modules, src/generated/)
files.includes: ["!!**/dist"] — explicitly excludes the compiled output directory
indentStyle: "tab" — tabs for indentation (consistent with the TypeScript config)
quoteStyle: "double" — double quotes for JavaScript/TypeScript strings
noExplicitAny: "off" — Prisma service functions use payload: any during schema iteration; this rule is disabled until the schema stabilises
noUnusedImports: "off" — disabled to avoid noise on files that are still being actively developed
organizeImports: "off" — import ordering is handled manually to avoid conflicts with Prisma-generated imports

Rules should be tightened over time. Starting with fewer rules enforced is preferable to fighting the linter constantly during early development.

What the Hook Produces

On a passing commit

❯ git commit -m "feat: add experience endpoint"
» Running pre-commit hook...
✔ Biome: no issues found (12 files checked)
[main 4f2a1c9] feat: add experience endpoint
 3 files changed, 47 insertions(+)

On a failing commit

❯ git commit -m "feat: add experience endpoint"
» Running pre-commit hook...
src/app/module/Experiance/exp.validation.ts:1:8 lint/correctness/noUnusedImports
  Imported variable 'z' is defined but never used.

✖ Found 1 error.
husky - pre-commit script failed (code 1)

The commit is aborted. The working tree is unchanged. The developer fixes the error and commits again.

The Default Hook Pitfall

When bunx husky init runs, it generates a default .husky/pre-commit that contains:

npm test

(or bun test if Bun is detected)

If your project has no test files yet, this will immediately fail:

bun test v1.3.5
No tests found!
Tests need ".test", "_test_", ".spec" or "_spec_" in the filename
husky - pre-commit script failed (code 1)

This is correct behaviour — bun test exited with code 1, so Husky blocked the commit. But the cause is a missing test suite, not a code problem.

Resolution: Replace the default hook content with a script that runs something immediately useful. Biome is the correct choice here since it is already configured and provides real value from the first commit.

Do not add bun test back to the hook until actual test files exist. An empty test suite failing the hook on every commit defeats the purpose of having a hook.

Extending the Hook With Tests

Once test files exist, extend .husky/pre-commit:

#!/bin/sh
bunx --bun @biomejs/biome check --write .
bun test

For an Express/Prisma project, start with tests for utilities that have no database dependencies. These run instantly and require no environment setup.

Recommended starting points in JoseOcando_api:

File	Why it's a good first test
`src/utils/jwtUtils.ts`	Pure functions, no DB, no HTTP
`src/shared/catchAsync.ts`	Wraps a handler, fully synchronous
`src/shared/sendResponse.ts`	Builds a response object, no side effects

Example — src/utils/jwtUtils.test.ts:

import { describe, expect, it } from "bun:test"
import { jwtUtils } from "./jwtUtils"

const SECRET = "test_secret_key_32_chars_minimum"
const PAYLOAD = { userId: 1, email: "user@example.com", role: "VISITOR" }

describe("jwtUtils.generateToken", () => {
  it("returns a string with three dot-separated segments", () => {
    const token = jwtUtils.generateToken(PAYLOAD, SECRET, "1h")
    expect(typeof token).toBe("string")
    expect(token.split(".").length).toBe(3)
  })
})

describe("jwtUtils.verifyToken", () => {
  it("returns the original payload on a valid token", () => {
    const token = jwtUtils.generateToken(PAYLOAD, SECRET, "1h")
    const result = jwtUtils.verifyToken(token, SECRET) as typeof PAYLOAD
    expect(result.userId).toBe(PAYLOAD.userId)
    expect(result.email).toBe(PAYLOAD.email)
  })

  it("throws JsonWebTokenError on a malformed token", () => {
    expect(() =>
      jwtUtils.verifyToken("not.a.valid.jwt", SECRET)
    ).toThrow()
  })

  it("throws TokenExpiredError on an expired token", async () => {
    const token = jwtUtils.generateToken(PAYLOAD, SECRET, "0s")
    await new Promise(r => setTimeout(r, 10)) // ensure expiry
    expect(() =>
      jwtUtils.verifyToken(token, SECRET)
    ).toThrow()
  })
})

Bypassing the Hook

For work-in-progress commits on feature branches:

# Environment variable method
HUSKY=0 git commit -m "wip: draft implementation"

# Git native flag
git commit --no-verify -m "wip: draft implementation"

Both methods skip all hooks entirely. HUSKY=0 is Husky-specific and more explicit about intent. --no-verify is a Git primitive that bypasses all hooks regardless of whether Husky is involved.

Policy: Never bypass hooks on main or any branch that feeds into a deployment pipeline. Bypassing should be limited to local WIP branches that will be cleaned up (rebased or squash-merged) before merging.

Summary

Component	Role
Husky	Manages Git hook lifecycle; makes hooks version-controlled
`core.hooksPath`	Git config key Husky sets to redirect hook resolution
`.husky/pre-commit`	Shell script executed before every commit
Biome	Performs lint + format check; exits 1 on unfixable errors
`prepare` script	Runs `husky` on `bun install`; installs hooks on every clone

The complete hook for a project with tests:

#!/bin/sh
bunx --bun @biomejs/biome check --write .
bun test

For a project without tests yet:

#!/bin/sh
bunx --bun @biomejs/biome check --write .

Add bun test to the hook only when test files exist. A hook that always fails provides no value and trains developers to bypass it.

Stack: Express 5 · Prisma 7 · TypeScript 5.9 · Bun 1.3 · Biome 2.4 · Husky 9

Next.js Rendering (Cooking Analogy)

MD Ehsanul Haque Rizvy — Tue, 24 Feb 2026 21:12:49 +0000

Next.js lets you control when and where rendering happens.

1. Client-Side Rendering (CSR) — browser cooks everything

This is the classic React behavior.

You visit /products, and the browser gets an empty shell first. Then JavaScript runs, makes a request, and fills the data.

"use client"
import { useEffect, useState } from "react"

export default function ProductsPage() {
  const [products, setProducts] = useState([])

  useEffect(() => {
    fetch("/api/products")
      .then(res => res.json())
      .then(setProducts)
  }, [])

  return (
    <>
      <h1>New Products</h1>
      {products.map(p => <div key={p.id}>{p.name}</div>)}
    </>
  )
}

Timeline of reality:

Browser loads page
Page is empty or loading
JS runs
JS fetches data
UI updates

User waits longer. This is slower.

When to use:

User dashboards
Interactive UI
Forms
User-specific content
When SEO is not important

When NOT to use:

Public pages
Product listings
Blogs
SEO pages

2. Server-Side Rendering (SSR) — server cooks on request

The browser requests /products.

The server immediately fetches products and sends fully prepared HTML.

export default async function ProductsPage() {
  const res = await fetch("https://api.example.com/products", {
    cache: "no-store"
  })

  const products = await res.json()

  return (
    <>
      <h1>New Products</h1>
      {products.map(p => <div key={p.id}>{p.name}</div>)}
    </>
  )
}

Timeline:

Browser requests page
Server fetches products
Server builds HTML with products already inside
Browser receives ready page instantly

Nothing loads afterward.

SSR = fresh data every request.

When to use:

Live inventory
Stock prices
User-specific pages
Data that must always be fresh

When NOT to use:

Static content
Blogs
Marketing pages
Data that rarely changes

3. Static Site Generation (SSG) — server cooks once at build time

Next.js fetches data during build and freezes it.

export default async function ProductsPage() {
  const res = await fetch("https://api.example.com/products", {
    cache: "force-cache"
  })

  const products = await res.json()

  return (
    <>
      <h1>Popular Products</h1>
      {products.map(p => <div key={p.id}>{p.name}</div>)}
    </>
  )
}

Timeline:

You run npm run build
Next.js fetches products
Next.js saves ready HTML
Every visitor gets that same HTML instantly

Fastest rendering method.

When to use:

Blogs
Landing pages
Documentation
Marketing pages
Content that rarely changes

When NOT to use:

Live dashboards
Frequently changing data
User-specific data

4. Incremental Static Regeneration (ISR) — server cooks occasionally

Next.js builds the page and updates it later automatically.

export default async function ProductsPage() {
  const res = await fetch("https://api.example.com/products", {
    next: { revalidate: 60 }
  })

  const products = await res.json()

  return (
    <>
      <h1>Products</h1>
      {products.map(p => <div key={p.id}>{p.name}</div>)}
    </>
  )
}

Timeline:

Build time:

Products fetched
Page saved

User visits within 60 seconds:

Gets cached version instantly

After 60 seconds:

First visitor still gets old version
Next.js refreshes in background
Future visitors get updated version

When to use:

Product listings
News sites
Ecommerce pages
Content that changes sometimes

When NOT to use:

Real-time data
User-specific private data

The Real Control Switch

cache: "no-store"         → SSR  
cache: "force-cache"      → SSG  
next: { revalidate: 60 }  → ISR  
"use client"              → CSR (if fetching in browser)

"use client" controls WHERE code runs.

Not WHEN data is fetched.

"use client" → browser

no directive → server

Performance Order (Fastest to Slowest)

Work done earlier is always faster than work done later.

Final Mental Model

CSR → browser fetches after load

SSR → server fetches on every request

SSG → server fetches at build time

ISR → server fetches at build time and refreshes later

"use client" → browser execution

no "use client" → server execution

Terminal, Shell, tmux: What They Really Mean (And How to Use Them as a Newbie)

MD Ehsanul Haque Rizvy — Tue, 10 Feb 2026 19:13:41 +0000

TL;DR

The command line stacks up in layers: Terminal emulator (the display window), Shell (the command interpreter), Programs (the tools you run), and optional tmux (session manager for multitasking). Beginners should start with defaults like iTerm2 and zsh on macOS, or Windows Terminal with WSL on Windows. Focus on basics before customizing to avoid confusion.

Ever stared at your screen, typing commands into a black box, and wondered why terms like iTerm2, zsh, or tmux get thrown around like they're interchangeable? Spoiler: They're not. As a developer who once rage-quit a terminal session thinking my "window" was broken (turns out, it was just a misconfigured shell), I know the frustration. This guide breaks it down into clear layers. No jargon overload, just clarity. By the end, you'll navigate the command line with confidence.

The Three Core Layers of the Command Line (Plus One Bonus)

Imagine the command line as a cake stack. Each layer builds on the last, but they serve distinct purposes. Mixing them up is like confusing the frosting with the sponge. Messy! Here's a simple visual:

+-------------------+
|   Programs        |  (e.g., git, node, vim)
|                   |
+-------------------+
|   Shell           |  (The brain: bash, zsh, etc.)
|                   |
+-------------------+
| Terminal Emulator |  (The window: iTerm2, Kitty, etc.)
+-------------------+
(Optional: tmux slots in between Shell and Programs for session magic)

This modular setup makes everything predictable. Let's dive in.

Layer 1: Terminal Emulator. The Window You See

The terminal emulator is just the app that gives you a blank window for typing. It doesn't "think". It displays text output and sends your keystrokes to the next layer. Think of it like a TV screen. It shows the show but doesn't write the script.

Common Terminal Emulators:

macOS Terminal (built-in, simple)
iTerm2 (feature-packed for Mac users)
Ghostty (modern, minimalist)
Kitty (fast, GPU-accelerated)
WezTerm (cross-platform, scriptable)
Alacritty (performance-focused)
Windows Terminal (modern Windows default)
GNOME Terminal or Konsole (Linux staples)

Pros and Cons Quick Table:

Emulator	Pros	Cons
iTerm2	Tabs, splits, macOS integration	Mac-only, can be overwhelming
Kitty	Speed, image support	Steeper learning curve
Alacritty	Blazing fast, lightweight	Fewer built-in features

When you type ls, the emulator blindly passes it along and shows the result. No smarts here.

Try It: Open your default terminal and type echo "Hello, World!". See? The window just echoes back. It's not interpreting anything.

Common Pitfall: If fonts look weird or colors are off, tweak the emulator's settings, not your shell config.

Layer 2: The Shell. The Brain That Interprets Commands

Now we're at the smarts. The shell reads your input, understands commands, and talks to the OS. It's like the director telling actors (programs) what to do.

Common Shells:

bash (Bourne Again Shell): Reliable, default on many Linux systems. Great for scripts.
zsh (Z Shell): Bash with extras like better autocompletion. macOS default.
fish (Friendly Interactive Shell): User-friendly with smart suggestions, but non-standard scripting.
sh (basic, lightweight Bourne Shell).
PowerShell: Microsoft's object-oriented powerhouse. Passes data as objects, not text.

Pros and Cons Quick Table:

Shell	Pros	Cons
bash	Ubiquitous, tutorial-friendly	Basic out-of-the-box
zsh	Plugins, themes (e.g., Oh My Zsh)	Slightly heavier than bash
fish	Intuitive, no config needed	Incompatible with bash scripts
PowerShell	Structured data handling	Less common in Unix tutorials

Personal Story: Early on, I customized my prompt in ~/.zshrc and thought my terminal was "fancy." Nope. That's shell magic! Edits here change prompts, aliases, and paths, not the window itself.

Try It: Type which ls in your shell. It tells you where the ls command lives. Proof the shell is interpreting.

Common Pitfall: Aliases or prompts not loading? Check your shell config file (e.g., ~/.bashrc for bash). Switching shells? Use chsh carefully to avoid lockouts.

Layer 3: Programs. The Tools You Actually Run

Inside the shell, you launch programs like everyday apps. Examples:

git clone repo
node server.js
python script.py
vim file.txt
docker run container

The flow: Emulator shows the window. Shell interprets. Program runs. Output displays.

Try It: Run git --version. If it's not installed, the shell will complain. Not the emulator.

Common Pitfall: Program errors (e.g., "command not found") are often path issues in your shell config, not a "broken terminal."

Bonus Layer: tmux. The Session Manager Superhero

tmux (Terminal Multiplexer) isn't an emulator or shell. It's a tool that runs inside your shell to manage sessions. Perfect for remote work or multitasking.

What it does:

Split windows into panes.
Detach/reattach sessions (e.g., keep a script running after logout).
Handle multiple tasks without closing your terminal.

Updated Stack Visual:

+-------------------+
|   Programs        |
|                   |
+-------------------+
|   tmux            |  (Optional: Panes & sessions)
|                   |
+-------------------+
|   Shell           |
|                   |
+-------------------+
| Terminal Emulator |
+-------------------+

Pros and Cons:

Pros: Persistent sessions, great for servers.
Cons: Learning curve (keybindings like Ctrl+b).

Try It (If Installed): Run tmux new -s mysession, then detach with Ctrl+b d. Reattach with tmux attach -t mysession.

Common Pitfall: Sessions vanishing? tmux isn't automatic. Start it manually.

Beginner Recommendations: Start Simple, Scale Later

Don't overcomplicate day one. Focus on basics like cd, ls, mkdir, and Git.

macOS: iTerm2 + zsh (default). Skip tmux.
Linux: Default emulator + bash. Upgrade to zsh later.
Windows: Windows Terminal + WSL (Ubuntu with bash/zsh) for Unix compatibility. Or pure PowerShell if you're in Microsoft ecosystems.

Customization comes after mastery. Avoid plugin overload.

FAQ: Quick Answers to Common Questions

How do I change my shell? Use chsh -s /bin/zsh (check paths with which zsh).
Terminal slow? Try a performant emulator like Alacritty.
Why learn this? It unlocks efficient dev workflows, automation, and server management.
Where next? Practice with freeCodeCamp's CLI module or "The Missing Semester" course.

🧙‍♂️ Stop Using Prettier and ESLint Separately | Biome Handles It Better

MD Ehsanul Haque Rizvy — Wed, 12 Nov 2025 19:16:11 +0000

I’ve been using Prettier since I first started learning programming. Back then, it was all HTML, CSS, and a few frameworks then came React, Express, and Next.js. And honestly, I’ve always liked my code clean and tidy (maybe a little too much 😆).

In the early days, I formatted everything manually with and VS Code’s default formatter. But the more I learned and the more projects I worked on, the harder it became to keep my code consistently formatted that way. So, naturally, I started using Prettier, and later added ESLint to keep my syntax sharp and consistent. I stuck with that setup for a long time it worked, but it was never seamless.

Then one day, I stumbled upon a blog post about a new tool that could format and lint at the same time. That got my attention. I gave it a try without much thought, and… guess what? Totally worth it.

Biome turned out to be way faster than Prettier and comes with a built-in linter that works just as smoothly as ESLint. It’s compact, fast, and surprisingly reliable. No extra configuration chaos. So if you’re thinking about trying Biome, here’s how you can get started it’s super simple.

Setting Up Biome :

You’ll need to install it as a dev dependency. I’m using
Bun, but you can use npm, pnpm, yarn, or even Deno Biome supports them all.
And honestly, their docs are excellent very readable and beginner-friendly. But let’s go through the basics right here.

Install Biome

bun add -D -E @biomejs/biome

Initialize Biome
This creates a biome.json file where you can configure everything.

bunx --bun biome init

That’s it! You’re ready to use Biome no need to install Prettier and ESLint separately anymore.

⚡ Basic Commands

Format all files:
bunx biome format --write

Format specific files:
bunx biome format --write <files>

Lint and apply safe fixes to all files:
bunx biome lint --write

Lint specific files:
bunx biome lint --write <files>

Format, lint, and organize imports (all files):
bunx biome check --write

Format, lint, and organize imports (specific files):
bunx biome check --write <files>

Bonus: Editor Support

Biome also has extensions for popular editors like VS Code, IntelliJ, and Zed
Plus, it supports modern frameworks like Svelte, Vue, and Astro right out of the box.

Final Thoughts

If you’re tired of juggling Prettier and ESLint configs, give Biome v2 a shot. It’s fast, clean, and takes care of formatting, linting, and import organization in one go. No more mismatched configs just a smoother, faster developer experience.

🚀 Customizing GitHub Copilot & GitLens for AI-Assisted Commit Messages 🧠💡

MD Ehsanul Haque Rizvy — Tue, 04 Mar 2025 17:05:47 +0000

Commit messages are essential for maintaining a clean, understandable project history. With GitHub Copilot 🤖 and GitLens 🔍, you can automate commit message generation with AI assistance, ensuring they are concise, meaningful, and well-structured.

🎯 Why Automate Commit Messages?

Commit messages should be clear and concise 📝. They provide context for changes and enhance team collaboration. But writing good messages every time? Tedious! 😵‍💫

This is where GitHub Copilot and GitLens step in! 🚀 These AI-powered tools help automate commit message generation while following best practices ✅.

🛠 Tools You'll Need:

🔹 GitHub Copilot – Powered by OpenAI’s GPT-4, suggests and generates commit messages based on your changes.
🔹 GitLens – A powerful Git extension for Visual Studio Code, enhancing your Git workflow with AI-generated commit messages.

⚙️ Setting Up GitHub Copilot & GitLens

1️⃣ Install GitHub Copilot 🤖
1️⃣ Open VSCode.
2️⃣ Navigate to the Extensions view(Ctrl + Shift + X or Cmd + Shift + X).
3️⃣ Search for "GitHub Copilot" and install it.
4️⃣ Sign in with your GitHub account.

2️⃣ Install GitLens 🔍
1️⃣ Open VSCode.
2️⃣ Go to the Extensions view.
3️⃣ Search for "GitLens" and install it.
4️⃣ GitLens will automatically integrate with your Git workflow in VSCode.

🛠 Configure Commit Message Generation ⚡️

3️⃣ Create .copilot-commit-message-instructions.md 📜
This file provides commit message rules for GitHub Copilot. Place it in the root of your project.

***📌 Example Instructions:*

GitHub Copilot Commit Message Instructions 🚀

General Guidelines:

✅ Use the imperative mood (e.g., "Add feature" instead of "Added feature").

✅ Be concise and clear – avoid overly detailed explanations.

✅ Follow standard commit types:

feat: 🚀 For new features
fix: 🐛 For bug fixes
refactor: 🔄 For restructuring code without behavior changes
style: 🎨 For cosmetic changes
perf: ⚡ For performance improvements
test: 🧪 For adding/updating tests

📌 Examples:

feat(auth): add two-factor authentication 🔐
fix(ui): correct button hover effect 🎨
refactor(api): optimize database queries 🚀
style(css): update button styles 💅 **

4️⃣ Configure`settings.json` ⚙️

"git.enableSmartCommit": true

🔍 Test & Verify Commit Message Generation 🎯

1️⃣ Make a change (e.g., add a feature or fix a bug).
2️⃣ Open Source Control(Ctrl + Shift + G / Cmd + Shift + G).
3️⃣ Commit your changes – Copilot will suggest a commit message based on the changes.
4️⃣ Review & refine the message if necessary.

If commit messages don’t meet expectations, tweak .copilot-commit-message-instructions.md✍️.

🛠 Troubleshooting Tips 🔧

🔹 No commit messages? – Ensure .copilot-commit-message-instructions.md is in the root of your project.
🔹 Messages too verbose? – Simplify the instructions to focus on clarity and conciseness.
🔹 VSCode doesn’t suggest commits? – Restart VSCode and check Copilot authentication.

🚀 Conclusion

By integrating GitHub Copilot 🤖 and GitLens 🔍, you can automate commit messages, making them consistent and efficient. This saves time, reduces human error, and keeps your commit history clean & structured 📜.

Now, every commit tells a story—without the extra effort! 🎯🚀

🌟 Master the Code Seas with Windsurf IDE 🌟

MD Ehsanul Haque Rizvy — Thu, 21 Nov 2024 05:33:57 +0000

If you haven’t tried Windsurf, you’re missing out on an IDE that feels like smooth sailing through your codebase! ⛵ Designed to make your dev life effortless, it’s fast, intuitive, and packed with features you’ll love:

🔥 Blazing Fast Performance: Perfect for handling even the heaviest projects.
💻 Seamless Multi-language Support: Switch between your favorite languages effortlessly.
🎨 Customizable Workspace: Tailor your setup to match your workflow.

🌊 Enhance Windsurf with Codeium!
Want to level up? I integrated Codeium with Windsurf, and it’s been a total game-changer:

Real-time AI suggestions
On-the-fly bug fixing
Multi-language AI support
🌬️ Together, Windsurf + Codeium feels like catching the perfect coding wave!

🚀 Ready to ride the Windsurf wave? Check it out and let me know your thoughts below!

Coding #WindsurfIDE #DeveloperTools #Productivity #DevLife

Forem: MD Ehsanul Haque Rizvy

# Enforcing Code Quality on Every Commit: Husky + Biome in a Node.js/TypeScript Project

Overview

How Git Hooks Work

The Problem With Raw Git Hooks

How Husky Solves This

Why Biome Instead of ESLint + Prettier

Project Setup

Installation

The Pre-Commit Hook

Biome Configuration

What the Hook Produces

On a passing commit

On a failing commit

The Default Hook Pitfall

Extending the Hook With Tests

Bypassing the Hook

Summary

Next.js Rendering (Cooking Analogy)

1. Client-Side Rendering (CSR) — browser cooks everything

2. Server-Side Rendering (SSR) — server cooks on request

3. Static Site Generation (SSG) — server cooks once at build time

4. Incremental Static Regeneration (ISR) — server cooks occasionally

Timeline:

The Real Control Switch

Performance Order (Fastest to Slowest)

Final Mental Model

Terminal, Shell, tmux: What They Really Mean (And How to Use Them as a Newbie)

TL;DR

The Three Core Layers of the Command Line (Plus One Bonus)

Layer 1: Terminal Emulator. The Window You See

Layer 2: The Shell. The Brain That Interprets Commands

Layer 3: Programs. The Tools You Actually Run

Bonus Layer: tmux. The Session Manager Superhero

Beginner Recommendations: Start Simple, Scale Later

FAQ: Quick Answers to Common Questions

🧙‍♂️ Stop Using Prettier and ESLint Separately | Biome Handles It Better

Setting Up Biome :

Bonus: Editor Support

Final Thoughts

🚀 Customizing GitHub Copilot & GitLens for AI-Assisted Commit Messages 🧠💡

🎯 Why Automate Commit Messages?

🛠 Tools You'll Need:

⚙️ Setting Up GitHub Copilot & GitLens

🛠 Configure Commit Message Generation ⚡️

GitHub Copilot Commit Message Instructions 🚀

General Guidelines:

4️⃣ Configuresettings.json ⚙️

🔍 Test & Verify Commit Message Generation 🎯

🛠 Troubleshooting Tips 🔧

🚀 Conclusion

🌟 Master the Code Seas with Windsurf IDE 🌟

Coding #WindsurfIDE #DeveloperTools #Productivity #DevLife

4️⃣ Configure`settings.json` ⚙️