Forem: Supreet Pradhan

Elevate Your Code Quality with Husky

Supreet Pradhan — Sat, 28 Feb 2026 19:01:44 +0000

In modern software development, maintaining code quality isn't just a nice to have it's a essential. As teams grow and codebases expand, ensuring consistent code standards, preventing bugs, and maintaining a clean commit history becomes increasingly challenging. Enter Husky, a powerful tool that acts as your project's quality gatekeeper by leveraging Git hooks.

Setting Up Husky

Installation

First, let's install Husky in your project:

npm install --save-dev husky
npx husky init

This creates a .husky directory in your project root with a sample pre-commit hook. Unlike the old .git/hooks directory, this folder is version-controlled and shared with your team.

Basic Configuration

After initialization, you'll have a structure like this:

your-project/
├── .husky/
│   ├── pre-commit
│   ├── pre-push
│   └── commit-msg
├── package.json
└── ...

Each file in .husky corresponds to a Git hook.

Building Your Quality Automation Stack

1. Prettier: Consistent Code Formatting

Prettier is an opinionated code formatter that enforces consistent style across your codebase. No more debates about tabs vs. spaces or where to place semicolons.

Installation:

npm install --save-dev prettier

Configuration (.prettierrc):

{
  "semi": true,
  "trailingComma": "es5",
  "singleQuote": true,
  "printWidth": 80,
  "tabWidth": 2
}

Integrate with Husky:

Create or update .husky/pre-commit:

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

npx prettier --write --ignore-unknown "**/*"

Now every commit will be automatically formatted!

2. ESLint: Catch Bugs Before They Happen

ESLint analyzes your JavaScript/TypeScript code for potential errors, bad practices, and style violations.

Installation:

npm install --save-dev eslint
npx eslint --init

Sample Configuration (.eslintrc.json):

{
  "env": {
    "browser": true,
    "es2021": true,
    "node": true
  },
  "extends": [
    "eslint:recommended",
    "plugin:@typescript-eslint/recommended",
    "plugin:react/recommended"
  ],
  "parser": "@typescript-eslint/parser",
  "parserOptions": {
    "ecmaVersion": "latest",
    "sourceType": "module"
  },
  "rules": {
    "no-console": "warn",
    "no-unused-vars": "error",
    "prefer-const": "error"
  }
}

Integrate with Husky:

Update .husky/pre-commit:

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

# Run ESLint on staged files
npx eslint . --ext .js,.jsx,.ts,.tsx --fix

# Run Prettier
npx prettier --write --ignore-unknown "**/*"

# Stage any fixes
git add -A

3. lint-staged: Optimize Your Workflow

Running linters on your entire codebase before every commit is slow and unnecessary. lint-staged runs linters only on staged files, dramatically improving performance.

Installation:

npm install --save-dev lint-staged

Configuration (in package.json):

{
  "lint-staged": {
    "*.{js,jsx,ts,tsx}": [
      "eslint --fix",
      "prettier --write"
    ],
    "*.{json,css,scss,md}": [
      "prettier --write"
    ]
  }
}

Update .husky/pre-commit:

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

npx lint-staged

This is the sweet spot: fast, efficient, and only touches relevant files.

4. TypeScript Type Checking

For TypeScript projects, add type checking to your pre-commit hook:

{
  "lint-staged": {
    "*.{ts,tsx}": [
      "tsc --noEmit",
      "eslint --fix",
      "prettier --write"
    ]
  }
}

Conclusion

Husky and automated quality checks aren't about being pedantic, they're about making your team more efficient, your code more reliable, and your releases more confident. By catching issues early, you shift quality left in your development process, reducing bugs, improving collaboration, and ultimately shipping better software.

The initial setup might seem like extra work, but the return on investment is immediate. Your team will spend less time in code review bike-shedding about formatting, less time debugging preventable issues, and more time building features that matter.

Start small, add tools incrementally, and watch your code quality and team productivity soar.

Why Custom Icon Fonts are the Ultimate Lightweight Icon Strategy

Supreet Pradhan — Fri, 27 Feb 2026 19:20:06 +0000

Modern best practice leans heavily toward SVG. They’re flexible, accessible, and powerful — and in many cases, they’re absolutely the right choice.

But here’s the thing.

Sometimes you don’t need power.

You need simplicity.

You don’t need:

A full icon library
A component abstraction
A build-time SVG loader
Dozens (or hundreds) of unused icons in your bundle

You just need:

<span class="icon-search"></span>

When Icon Fonts Are Actually the Simpler Choice

For small UI icon sets — especially in server-rendered or static projects, a single .woff2 file + one CSS file can be simpler and smaller than pulling in an SVG library. Fonts are aggressively cached, require no JavaScript, and behave like text by default.

Fonts are:

Aggressively cached by browsers
Pure CSS (no JavaScript required)
Naturally scalable
Text-like by default (inherit size and color automatically)

Instead of importing a large icon package, a minimal SVG → font pipeline can be set up using Node.js.

No frameworks.
No bundlers.
Just a small build script and a folder of SVGs.

Let’s break it down.

The Stack

Node.js (ESM, "type": "module")
svgtofont — the library that does the heavy lifting

npm install svgtofont --save-dev

Project Structure

icons/             ← drop your SVGs here
dist/              ← generated font + CSS lands here
scripts/
  build-icons.mjs  ← the build script
package.json

The Build Script

This is the entirety of scripts/build-icons.mjs:

import svgtofont from 'svgtofont';
import path from 'path';
import fs from 'fs';

const rootDir = process.cwd();

const ICONS_DIR = path.resolve(rootDir, 'icons');
const DIST_DIR = path.resolve(rootDir, 'dist');
const FONT_NAME = 'icons';

async function build() {
  await svgtofont({
    src: ICONS_DIR,
    dist: DIST_DIR,
    fontName: FONT_NAME,
    classNamePrefix: 'icon',   // ← generates .icon-search, .icon-cart, etc.
    css: true,                  // ← auto-generate the CSS file
    outSVGPath: false,
    generateInfoData: false,
    website: null,
    emptyDist: true,            // ← clear dist before each build
    startUnicode: 0xe001,       // ← start in the Private Use Area (PUA)
  });

  // svgtofont outputs some extra files we don't need — clean them up
  const allowed = ['.ttf', '.woff', '.woff2', '.css'];
  fs.readdirSync(DIST_DIR).forEach((file) => {
    if (!allowed.some((ext) => file.endsWith(ext))) {
      fs.unlinkSync(path.join(DIST_DIR, file));
    }
  });

  console.log('✅ Icons built successfully.');
}

build().catch(console.error);

Wire it up in package.json:

{
  "type": "module",
  "scripts": {
    "build:icons": "node scripts/build-icons.mjs"
  }
}

Run it:

npm run build:icons

Output in dist/:

dist/
  icons.css
  icons.ttf
  icons.woff
  icons.woff2

What Gets Generated

The icons.css looks like this:

@font-face {
  font-family: "icons";
  src: url('icons.woff2') format('woff2'),
       url('icons.woff')  format('woff'),
       url('icons.ttf')   format('truetype');
}

[class^="icon-"], [class*=" icon-"] {
  font-family: 'icons' !important;
  font-style: normal;
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;
}

.icon-cart-shopping::before { content: "\e001"; }
.icon-eye::before           { content: "\e002"; }
.icon-facebook::before      { content: "\e003"; }
.icon-house::before         { content: "\e004"; }
.icon-plus::before          { content: "\e005"; }
.icon-volume::before        { content: "\e006"; }

Each icon name maps directly to the SVG filename (without extension). The ::before pseudo-element injects the glyph via a Unicode codepoint in the Private Use Area — same technique Font Awesome uses.

Using It in HTML

<link rel="stylesheet" href="./dist/icons.css" />

<span class="icon-search"></span>
<span class="icon-cart-shopping"></span>

Sizing and coloring works exactly like text:

.icon-search {
  font-size: 24px;
  color: #6152e8;
}

Used correctly, an SVG icon and a generated font icon can look visually identical in the UI. The difference is not in appearance, but in delivery — a single cached font file can sometimes be simpler and lighter than managing multiple inline SVGs.

Wrapping Up

The whole thing is about 35 lines of JavaScript.

It’s also important to use clean SVG files with a proper viewBox, simple path elements, and no embedded images. If you’re working with outline-style icons, convert strokes into filled outlines before generating the font.

Custom icon fonts are not a replacement for SVG in every situation. But for small, controlled icon sets in static or server-rendered projects, they can be a very lightweight, cache-friendly, and dependency-free solution.

The full source code GitHub

References -
Icons sourced from Font Awesome
icon-font vs svg Blog
The Developer's Guide to Icons: Icon Fonts vs. SVGs Blog

How to Use Markdown Files to Orchestrate Multi-File Changes in GitHub Copilot

Supreet Pradhan — Mon, 16 Feb 2026 19:37:24 +0000

AI-assisted coding is everywhere. Tools are fast, accessible, and can turn a simple prompt into working code in seconds.

But anyone using AI seriously for development knows the pattern:

You ask for code
You clarify intent
You fix structure

Back and forth. Each iteration consumes time. And time is a finite resource.

If AI usage becomes more metered in the future, per prompt, per token, per request, then clarity becomes critical. Every vague instruction has a cost.

This is where structured prompting inside the codebase, especially with GitHub Copilot, becomes a serious productivity multiplier.

The Problem: Repetitive Multi-File Changes

In real-world projects, features rarely touch just one file.

Adding something small like a new filter or API integration often requires:

Updating types
Modifying API services
Updating hooks
Changing state management
Adjusting UI components
Possibly updating pages
Maybe touching tests

That is easily 6–8 files for a "minor" feature. Doing this manually is repetitive; doing it via casual chat is fragmented. The issue isn’t AI capability; it’s a lack of structure and context.

The Solution: Structured Markdown Prompting

Instead of typing ad-hoc instructions into the chat sidebar, define your requirements inside the repository using Markdown files. This creates a "blueprint" that Copilot can use to orchestrate changes across the workspace.

Step 1 — Define the Project Source of Truth

Create a Project DNA file to serve as the source of truth for your codebase. By explicitly defining your tech stack, folder hierarchy, and architectural boundaries, you eliminate 'AI guesswork' and ensure Copilot respects your specific design patterns from the very first line

Locations : docs/PROJECT_CONFIGS.md

Example:

Step 2 — Create Workflow Blueprints

For specific, repetitive tasks, create targeted instruction files.

Example: docs/workflows/API_SERVICE.md
Describe exactly how a service should be built: where it lives, how it handles errors, and what the import order should be.

Step 3 — Orchestrating with the Coding Agent

This Is Where the Magic Happens. Instead of using the standard chat, switch to the GitHub Copilot Coding Agent and select a high-reasoning model like Claude 3.5 Sonnet or Claude 4.5 (if available in your tier).

Don’t waste time with long paragraphs. Since you’ve already defined your “Blueprints” in Step 2, your interaction becomes a clean, command-style instruction.

Attach Context

Add your project-config.md and relevant source files to the chat context.
Issue the Command

Use a concise prompt that references your workflow file:

/new service LoginService - Follow rules in docs/workflows/service.md

Step 4 — Controlled, Multi-File Output

While standard chat provides snippets you have to manually copy-paste, the Agentic Workflow handles the heavy lifting by natively generating and placing files directly into your codebase.

A new types file
A new service file
Correct imports
Strict typing
Proper folder placement
No UI logic leakage
Everything aligned with the existing project conventions defined in Markdown

Conclusion

GitHub Copilot performs significantly better when:

Context is explicit
Conventions are documented
Scope is clearly defined
Architecture rules are enforced

Markdown becomes a lightweight contract between the developer and the AI.

My GitHub Repo for the Project

External Links :