DEV Community: Mehak.

Building Node.js CLI Tool.

Mehak. — Mon, 10 Nov 2025 13:59:51 +0000

Recently, while revising Node.js, I came across the project section Node.js roadmap on roadmap.sh(https://roadmap.sh).

The first project challenge there is to create a CLI (Command-Line Interface) tool using Node.js. So,I decided to build one to refresh my basics.

This post explains how CLI tools actually work under the hood and how to build one yourself from scratch.

How OS Executes Script Files

Before creating any CLI, we must understand how operating systems execute scripts.

Normally, when you run a Node.js file like this:

node index.js

it’s Node.js that runs the file — not your operating system.

The OS doesn’t automatically know how to execute JavaScript — it just knows how to run:

Compiled binaries (bash, python, node, etc.)
Or scripts that explicitly tell it which program should interpret them.

If you want your script to be run directly (e.g., by typing mycli in the terminal), then the OS must know which program to use to interpret it.

By default, if you make a file executable, the OS will assume it’s a shell script unless you specify otherwise.

To tell the OS that your script should be run by Node.js, add this line at the top of your file:

#!/usr/bin/env node

This line is called a shebang, and it tells the OS:
“Run this file using Node.js, wherever it’s installed.”

How npm Installs CLI Tools Globally

When we install any package globally using npm install -g npm do the following things:

Installs the package in your system’s global node_modules directory(the path depends on your OS).
Looks for the bin field inside the package’s package.json.
Creates a symlink (symbolic link) between the CLI command and the script file defined in bin. So, for example, if your package.json contains:

"bin": {
  "taskcli": "./bin/index.mjs"
}

npm will create a command called taskcli that points to your script.

The bin Field in package.json

The bin field defines which commands your package exposes and what files they execute.

I like to keep all CLI entry files inside a bin/ folder for clarity.

Parsing Command-Line Arguments

When we execute a script, Node exposes the arguments through process.argv.

node script.js add "Buy groceries"

process.argv will contain:

[
  '/usr/bin/node',
  '/path/to/script.js',
  'add',
  'Buy groceries'
]

we could manually parse this array, but that’s tedious.Instead, use a library like Commander.js,which gives you:

Argument parsing
Subcommands
Automatic --help and --version support

Making the Tool Work Locally — npm link

Before publishing your CLI to npm, we can test it locally using:

npm link

This creates a symlink between your local project and your global npm binaries directory,so your command (taskcli) behaves like a globally installed CLI.

Now you can run:

taskcli add "Learn Node.js"
taskcli list

No global installation needed and everything runs locally.

Final Project

Here’s my implementation:

GitHub: MehakB7/task-cli
Roadmap.sh Submission: Task Tracker Project Solution

This small project helped me understand:
How the OS executes scripts
How npm sets up CLI tools under the hood
How to design structured, maintainable command-line apps

Integrating Playwright with Next.js — The Complete Guide

Mehak. — Thu, 16 Oct 2025 16:24:13 +0000

What is Playwright?

Playwright is a modern automation and testing framework built by Microsoft. It allows you to write end-to-end (E2E) tests for your web apps that run across multiple browsers and devices — including Chromium, Firefox, and WebKit, both desktop and mobile.

At its core, Playwright is designed for speed, reliability, and real-world testing.

Unlike older tools that rely on flaky DOM polling, Playwright takes a “web-first assertions” approach — it automatically waits for elements to become visible before interacting with them.

How Playwright Works

Playwright consists of two key parts:

Node Controller (Test Runner) — This is where your test scripts live.
Browser Instance — A new instance that Playwright launches for each test run.

They communicate through a WebSocket connection, allowing real-time, bi-directional messaging.

This architecture makes Playwright faster and more efficient than many other frameworks.

When you run a test, the Node controller sends commands (like click, fill, or goto) to the browser.

The browser executes those commands and returns the results.

Let's visualize this communication:

The Node Controller instructs the browser: "Click the 'Submit' button."
The Browser responds: "Click registered. Initiating an API call to /api/login."

The Node Controller, if configured with page.route(), can intercept that request and fulfill it with a mocked response, making the test fast and independent of backend services.

Why Playwright

From my experience, it comes down to a few critical features that eliminate common testing headaches:

Parallel Execution: Run your test suites significantly faster by executing tests concurrently.
No More Flaky Tests: Playwright's built-in smart assertions wait for elements to be ready, visible, and stable. Instead of adding arbitrary setTimeout calls everywhere.

Codegen — Write Tests Without Writing Them

One of my favorite features is Playwright Codegen.
You can open your app, interact with it, and Playwright will automatically generate the corresponding test code for you. Just one command and you can start interaction with the website and genetate test code.

npx playwright codegen

Understanding Fixtures

In testing, a fixture is a predefined state or environment that ensures your tests are consistent and repeatable. Think of it as a "setup" that gives the same answer every time it's requested.

Playwright uses fixtures extensively. Here are a few powerful examples:

Image Upload Fixture: Create a reusable fixture that provides a test image file, so every test that needs to upload a file doesn't have to manage the file path separately.

API Interception Fixture: Intercept costly third-party API calls and return a predefined, reliable JSON response. This makes your tests fast, deterministic, and free from external service outages.

Integrating Playwright with Next.js

Step 1 : Installation
install Playwright in your Next.js project:

npm install -D @playwright/test
npx playwright init

The init command sets up the default configuration and creates the tests/ directory.

Step 2: Configuration

import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  testDir: './e2e',      // Folder where your tests live
  timeout: 30000,          // Test will fail if it exceeds 30 seconds
  retries: 1,              // Retry failed tests once for CI stability
  workers: 4,              // Run tests in parallel with 4 workers

  use: {
    baseURL: 'http://localhost:3000', // Your Next.js dev server URL
    viewport: { width: 1280, height: 720 },
    // Record video only when retrying a failed test
  },

  // Define your browser and device matrix
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
    { name: 'firefox', use: { ...devices['Desktop Firefox'] } },
    { name: 'webkit', use: { ...devices['Desktop Safari'] } },
    // Uncomment to add mobile testing
    // { name: 'Mobile Chrome', use: { ...devices['Pixel 5'] } },
  ],
});

Step 3: Writing Your First Test

create a test inside e2e/home.spec.ts. Playwright's page fixture provides a clean, isolated browser context for each test.

import { test, expect } from '@playwright/test';

test('homepage has correct title and welcome message', async ({ page }) => {
  // Navigate to the homepage
  await page.goto('/');

  // Assert that the page title contains "Next.js"
  await expect(page).toHaveTitle(/Next.js/);

  // Use a locator to find an element and assert its text
  const welcomeMessage = page.getByRole('heading', { name: 'Welcome to Our App' });
  await expect(welcomeMessage).toBeVisible();
});

Running Tests in Different Modes

You can run Playwright tests with different flags and modes:

Headed mode (UI): Opens the Playwright UI to visualize test runs.

npx playwright test --ui

Headless mode: Runs quietly without opening a browser window.

`npx playwright test

Specify browser:

npx playwright test --project=chromium npx playwright test --project=firefox

You can add these command in your package.json file based on your requirement.

⚠️ Note on Mocking: MSW with Playwright vs Jest

If you're coming from Jest and are used to mocking API calls with MSW (Mock Service Worker), there's a crucial architectural difference:

In Jest: Your tests run in a Node.js environment, and MSW operates at the Node level
In Playwright: API calls happen in the actual browser context, while the test runner operates in Node.js

This means your existing MSW handlers won't automatically work with Playwright.

To use MSW with Playwright, you need to:

Start MSW within the browser context (web worker)
Ensure your mock service worker is registered and active in the page

Alternative: Playwright provides built-in API mocking via page.route() which is often simpler for E2E tests.

Try It Yourself

If you want to see Playwright running in a real-world project
check out this demo repo:
AI Studio (GitHub)

Mock Service Worker (MSW) in Next.js – A Guide for API Mocking and Testing

Mehak. — Mon, 28 Jul 2025 04:53:20 +0000

What is MSW?

MSW (Mock Service Worker) is a framework-agnostic library that intercepts network requests at the network level, providing mock responses. This means it doesn’t care whether you use fetch, Axios, GraphQL, etc.—MSW works regardless.

It achieves this using:

A Service Worker in the browser
A Node-based interceptor during testing

This ensures the mock lives closer to the actual request, mimicking real-world behavior without patching individual libraries.

How Does MSW Work?

MSW intercepts API calls at the network layer. This means:
If a mock exists for an API endpoint, MSW will return the mocked response.

If no mock is defined, the request proceeds to the real API.

Environment	MSW Mode	How it Intercepts
Browser	Service Worker	Runs a real service worker that intercepts requests from the browser in network layer
Node.js	Node Interceptor	Uses `node-request-interceptor` to hook into HTTP/HTTPS in process level

Why MSW ??

True Isolation
Mocks network at lowest possible level - no need to modify application code

Framework Agnostic Tests
Works with React Testing Library, Vue Test Utils, Svelte Testing Library, etc.

Realistic Behavior
Simulates actual network conditions (latency, errors, headers) unlike jest.mock()

Cross-Library Support
Intercepts requests from ANY HTTP client automatically

MSW in the Browser

To set up MSW in the browser for development:

Install the Service Worker

Run the following command to install the service worker file:

   npx msw init public/

This will add the mockServiceWorker.js file to your public/ directory.

Create your mock handlers Create a handler file with your REST or GraphQL mocks:

import {
  http, HttpResponse,
} from "msw";

export const handlers = [
  http.get(`/api/whoami`, () => {
    return HttpResponse.json({
      status: 200,
      data: {
         user: "Jack Sparrow"
      },
    });
  }),
]

Set up broswer worker Create a browser.ts file to initialize the MSW browser worker:

import { setupWorker } from 'msw';
import { handlers } from './handlers'
export const worker = setupWorker(...handlers);

I also created a initMock file to start initiate the mock worker

Start the worker Instead of starting the worker in Rootlayout I prefer to do it by creating a Wrapper component.

'use client';

import { useEffect, useState } from 'react';

export function StartMockWorker({children}: {children: React.ReactNode}) {
  const [isMockReady, setMockReady] = useState(false);

  useEffect(() => {
    async function enableMocks() {
      if (process.env.NODE_ENV === 'development') {
        const { initMocks } = await import('@/common/mock/initmock');
        await initMocks();
      }
      setMockReady(true);
    }

    enableMocks();
  }, []);

  if (!isMockReady) {
    return <div>Loading mocks...</div>;
  }

  return <>{children}</> ;
}

MSW with Jest for Testing

Jest runs tests in a Node.js environment, not a real browser. This means:
No Browser APIs Exist
Service Workers (which power MSW in browsers) are a browser-exclusive feature - they don't exist in Node.js.

JSDOM Isn't a Real Browser
While Jest uses JSDOM to simulate a browser, it's still just a Node.js process. Critical browser features like Service Workers aren't implemented.

Setup

Create a server

import { setupServer } from 'msw/node'
import { handlers } from './handlers'
export const server = setupServer(...handlers)

In the jest setup file

// jest.setup.ts
import '@testing-library/jest-dom';
import { server } from '@/common/mock/server';
beforeAll(() => server.listen());
afterEach(() => server.resetHandlers());
afterAll(() => server.close());

It ensures that your tests run with network requests intercepted and mocked, and that the state is cleaned up between tests.

Polyfills Required for Node + JSDOM

When running in jsdom with Jest, you might run into missing globals like:
Blob. TextEncoder,BroadcastChannel (added in MSW v2+), MessagePort etc

You’ll need to manually polyfill these in your Jest setup file


/* eslint-disable @typescript-eslint/no-require-imports */
// jest.polyfills.js


const {
  TextDecoder, TextEncoder,
} = require('node:util');

const { ReadableStream, TransformStream } = require('node:stream/web');

const { BroadcastChannel, MessagePort } = require("node:worker_threads")

Object.defineProperties(globalThis, {
  TextDecoder: { value: TextDecoder },
  TextEncoder: { value: TextEncoder },
  ReadableStream: { value: ReadableStream },
  TransformStream: { value: TransformStream },
  BroadcastChannel: { value: BroadcastChannel },
  MessagePort:{value:MessagePort}
})

const {
  Blob, File,

} = require('node:buffer')
const {
  fetch, Headers, FormData, Request, Response,

} = require('undici')

Object.assign(globalThis, {
  fetch,
  Headers,
  FormData,
  Request,
  Response,
  Blob,
  File,
})

Conclusion

MSW is powerful, developer-friendly, and works seamlessly in both the browser and Node environments:

Great for mocking real-world APIs in local dev.
Essential for writing fast, reliable, and network-independent Jest tests.
Framework-agnostic and works with any HTTP client.

With proper setup and polyfills, it becomes your best friend in test and dev workflows.

Full Setup

You can find the complete setup, including all code examples and configurations, in this GitHub repo:
👉 msw-with-next

Understanding Shadow DOM by Building a Poll Plugin

Mehak. — Wed, 04 Jun 2025 17:16:49 +0000

🌐 What is Shadow DOM?

Shadow DOM is a browser feature that allows us to attach a separate DOM tree to an element, a tree that’s isolated from the rest of the page.

Think of it as a "mini web page" inside an element, with its own HTML, CSS, and JS completely encapsulated from the rest of the site.

🔑 Key Concepts

Shadow Host: The DOM element where the Shadow DOM is attached.
Shadow Root: The root of the shadow tree, created with element.attachShadow(options).
Shadow Boundary: The barrier between the shadow DOM and light DOM (regular DOM). Styles and events generally don’t cross this boundary unless configured.

🧵 Modes: `open` vs `closed`

You can attach a shadow root in two modes:

open: The shadow root is accessible via element.shadowRoot.
closed: The shadow root is not accessible from the outside.

🛑 Note: Even in open mode, accessing shadow DOM externally is discouraged as it breaks encapsulation.

🔁 Communicating with the Light DOM

Since shadow DOM is isolated, direct interaction with outside elements is limited. The recommended way to communication is using Custom Events.

const voteEvent = new CustomEvent('simplepoll-vote', {
  detail: { vote: 'React' },
  bubbles: true,
  composed: false // set true if event is dispatch within the shadow boundary.
});
host.dispatchEvent(voteEvent);

⚠️ Without composed: true, the event will not escape the shadow DOM and cannot be listened to in the main document.

📝 Important Clarification

If you dispatch the event from the shadow root, composed: true is necessary to make it cross the boundary.

However, if you dispatch the event from the host element, composed is not needed as it’s already outside the shadow tree.

🧪 Let's Build a Real Plugin: Poll Widget

To reinforce our understanding, I built a simple poll plugin using Shadow DOM. This plugin:

Creates a styled voting widget inside a Shadow DOM
Encapsulates its layout and logic
Dispatches a custom event on vote
Can be embedded into any website

🗂 Folder Structure

poll-plugin/
├── index.js          # Entry point (exports the class)
├── lib/
│   ├── dom.js        # DOM creation helpers
│   ├── template.js   # HTML content generator
│   ├── style.js      # CSS as JS string
│   └── logic.js      # Voting logic and event binding
├── index.html        # to test the plugin
├── vite.config.js    # build config
├── package.js

⚙️ How It Works

const container = createContainer('poll-container');
const shadow = container.attachShadow({ mode: 'closed' });
shadow.appendChild(style);
shadow.appendChild(wrapper);

The poll UI is created inside the shadow root.
Created the poll in closed mode so main dom cannot access it.
Styles are injected with a style tag.
The HTML is dynamically created from config.
When a user votes, we emit a custom event which will listen by main dom.

💬 Listening for Poll Votes

To listen event in the main dom:

 document.addEventListener('vote-submitted', (e) => {
        alert(`You voted: ${e.detail.vote}`);
  });

This keeps your main app clean while the logic is self-contained.

🛠 Bundling with Vite

To make this plugin usable in any website, I used Vite as it's a fast, modern frontend build tool that simplifies development and bundling.Vite allows us to:

Write modular, clean source code in separate files
Use modern JavaScript or TypeScript
Compile everything into a single minified JS file ready for production

🔗 How to Use It in Any Website

After bundling the plugin we can easily embedd to any website using script tag.

 <script src="./dist/poll.iife.js"></script>
    <script>
      Poll.init({
        question: 'What is your favorite JS framework?',
        options: ['React', 'Vue', 'Svelte', 'Solid']
      });

      document.addEventListener('vote-submitted', (e) => {
        alert(`You voted: ${e.detail.vote}`);
      });
    </script>

It works ansywhere without leaking styles or affecting the main page.

🧾 Full Source Code

https://github.com/MehakB7/poll-plugin

📬 Understanding GitHub Webhooks: Send Email Notifications on Pull Request Events Using Node.js

Mehak. — Fri, 30 May 2025 11:34:12 +0000

Recently, I became curious about how GitHub webhooks work. To deepen my understanding, I built a small Node.js project that sends an email notification every time a pull request (PR) is opened.

Yes, GitHub already has a built-in notification system, but building your own gives you full control and a deeper understanding of the ecosystem.

🔐 First, What’s HMAC?

Before we dive into code, it’s important to understand how GitHub ensures that webhook events are secure.

HMAC stands for Hash-based Message Authentication Code. It’s a cryptographic technique used to verify both:

The integrity of a message (that it hasn’t been tampered with)
The authenticity of the sender (that it’s really from GitHub)

GitHub does this by hashing the body of the request with a shared secret you provide when creating the webhook. It then sends that signature along with the request using the X-Hub-Signature-256 header.

🧩 Webhook Levels

Webhooks can be configured at three levels:

Repository level – scoped to a single repo
Organization level – applies to all repositories within an organization
GitHub App level – used in GitHub Apps for deep integration across multiple repositories or organizations

For this example, I used an organization-level webhook so it applies to all repos in my org.

🔎 Signature Verification

To verify that the incoming request is really from GitHub, we need to:

Capture the raw request body before it’s parsed by Express.
Recompute the HMAC signature using the same secret.
Use a constant-time comparison to prevent timing attacks.

Here’s how I do it:

🔸 Express Middleware

We add a raw body parser to capture the exact payload:

app.use(express.json({
  verify: (req, _, buf) => {
    req.rawBody = buf;
  }
}));

This step is critical — HMAC must be calculated over the raw payload. If you parse it first, you’ll get a mismatch.

🔸 Signature Verifier (`utils/verifier.js`)

import crypto from 'crypto';
import { config } from './config.js';

export const verifySignature = (req)=>{
    const signature = req.headers['x-hub-signature-256'];
    if(!signature){
        return false;
    }
    const hmac = crypto.createHmac("sha-256", config.GIT_WEBHOOK_SECRET );
    hmac.update(req.rawBody);
    const expectedSignature = `sha256=${hmac.digest('hex')}`;
    return signature === expectedSignature;
}

📬 Sending Email Notifications

Once the signature is verified, I check if the action is "opened" on a PR, and then send an email.

I used Nodemailer with Gmail as the SMTP service. Since my Gmail account uses 2FA, I generated an App Password to authenticate.Use the app password without spaces.

🔸 Mailer (`services/emailService.js`)

const transporter = nodemailer.createTransport({
    service:"Gmail",
    auth:{
        user: config.EMAIL,
        pass: config.PASSWORD
    }
})

export  const sendPRrequestMail = (recipents, subject, text)=>{
    const mailOption = {
         from :config.EMAIL,
         to: recipents,
         subject: subject,
         text: text
    }
    return new Promise((resolve, reject)=>{
        transporter.sendMail(mailOption, (error, result)=>{
             if(error){
                 reject(error);
             }else{
                resolve(result);
             }
        })
    })

}

🚀 Exposing the Server for GitHub to Reach

To allow GitHub to reach my local server, I had two options:

Use a tunneling service like Ngrok
Deploy to a cloud provider. I chose to deploy to Render, which has a generous free tier and makes deployment super easy. Once deployed, I used the Render URL as the webhook endpoint in GitHub. ---

✅ Summary

🔐 We used HMAC with a shared secret to verify webhook authenticity.
📦 We used Nodemailer + Gmail to send email notifications.
🌐 We deployed our app to Render to make it accessible to GitHub.
🧠 And we learned that understanding webhooks at a low level is a great way to grow as a developer.

📂 Full Source Code

You can view the complete code for this project on GitHub:

👉 https://github.com/Mehakb78/git-prrequest-mailer
Feel free to clone it, experiment!

Building Quizo: A Quiz App Using Kendo React Components and GenAI

Mehak. — Sun, 23 Mar 2025 17:17:59 +0000

This is a submission for the KendoReact Free Components Challenge.

What I Built

I built Quizo, a quiz application using Kendo React components. The app allows users to take quizzes on various subjects with a gamified experience. One of the standout features of Quizo is its GenAI-powered question generation, which enables users to generate questions dynamically on a selected topic. Initially, I also planned a PDF-to-Quiz feature, where uploading a PDF would extract text and generate questions. However, due to the cost of OpenAI’s API key, I had to put this feature on hold 😔.

Demo

Website: quizo-app
Repo: quizo-repo

KendoReact Experience

Lets walks through the different Kendo React components I used, my implementation choices, and my overall experience.

Home page

For the Home Page, I used the Card Component from Kendo’s layout system. The Card component provides a flexible design structure, making it easy to display information in a visually appealing way.

Subject page

On the Subject Page, I utilized the following Kendo React components:

Breadcrumbs: Used for easy navigation, allowing users to track their location within the app.

SVG Icon Library: Provided various SVG icons to improve the UI and enhance user experience.

Data Grid: This was one of the most impressive components. The Data Grid comes with various powerful features like resizing, filtering, and sorting. However, for my project, I used only a minimal set of these features.

Quiz page

The Quiz Page required multiple components to handle different types of questions efficiently. Here’s how I structured it:

Progress Bar: Displays the user’s progress throughout the quiz.

Radio Button: Used for single-choice questions.

Checkbox : Supports multi-choice questions.

List Box: Helps with sorting-based questions.

Notification List: Used to show real-time notifications to users.

Kendo Animation Library: Implemented animation effects for smoother transitions and interactions.

AIm to Impress

For the GenAI-powered quiz generation, I used OpenAI to create quiz questions based on user-input topics. Users can either:
Type a topic of their choice, and the AI will generate relevant questions.
Select from predefined subjects, where the app fetches relevant questions accordingly.

Final Thoughts

Building Quizo was an exciting and rewarding journey!. I truly enjoyed every step of the process—from designing the UI to integrating AI-powered features. It was a fantastic opportunity to learn new things, including working with the OpenAI API, exploring its dashboard, and integrating its library into my project.

One of the most impressive aspects was discovering the Kendo React component library. I was amazed by how it offers a component for almost every possible requirement, making development smoother and more efficient. Whether it was layout design, data presentation, or animations, Kendo React had a solution for everything, which made my experience even more enjoyable!

I plan to revisit the PDF-to-Quiz feature in the future and explore more advanced AI capabilities. If you’re working on a similar project, I highly recommend exploring Kendo React for its rich component library!

Advent of spring

Mehak. — Mon, 17 Feb 2025 11:56:15 +0000

This is a submission for Frontend Challenge - February Edition, CSS Art: February.

Inspiration

This is inspired by the early arrival of spring this February, bringing warmth and life sooner than expected. As I witnessed couples celebrating Valentine’s Week and older pairs setting beautiful relationship goals, I felt moved to capture this essence of love and renewal. The trees in bloom, the gentle falling leaves, and the serene atmosphere reflect the joy of love in all its forms—young and old, fleeting and everlasting. This piece is a tribute to the beauty of the season and the heartfelt moments it brings.

Demo

https://codepen.io/MehakB77/pen/gbObybQ

Journey

Initially, I explored different ways to represent my idea in CSS, including creating a flip-book showcasing various events happening in February. However, I lastly decided to go with this scenic artwork, as it better captured the essence of the month.

Most of the artwork is crafted using SVG, allowing for flexibility and clean visuals. A special shoutout to SVG Repo( for providing beautiful, freely available SVGs and to MediaModifier's SVG Editor, which helped me combine and modify SVGs effortlessly.

By incorporating small animations and carefully placed elements, I aimed to depict the warmth of early spring, the joy of Valentine’s celebrations, and the beauty of love in all its forms.

Pair Programming Redefined: My Journey with Copilot

Mehak. — Sun, 19 Jan 2025 19:25:37 +0000

This is a submission for the GitHub Copilot Challenge : Fresh Starts

I created the mini web version of the habit.

The application allows users to create, update, and delete habits, providing a structured way to monitor progress and achieve personal goals. The app is built using Next.js, Shadcn, Tailwind CSS, and TypeScript and use local storage to store user data.

Demo

habit tracker.

Repo

Habit tracker

Copilot Experience

After working with copilot i was able to complete task easy and learn new tricks to attend good productivity. Here is what I learn
File Creation and Test Case Generation:

Easily instruct Copilot to create new files or write comprehensive test cases for existing code.
Drag-and-Drop File Imports:
Dragging and dropping files helps Copilot understand dependencies and automatically import the necessary components into the right places.
Example: When asked to create a HabitContext, it provided files with all the required changes and imports.
Code Creation from Links:
Copilot can generate code based on shared links.
Example: It created a ThemeProvider after analyzing the link provided.
Suggestions and Error Fixing:
GitHub Copilot offers real-time suggestions and fixes errors in the code, which is extremely helpful and time-saving.
Code, Extension, and Workspace Analysis:
Analyzes the entire codebase, extensions, and workspace to provide relevant results tailored to the context.
Code Summarization:
Provides concise summaries of code functionality, making it easier to understand complex logic or unfamiliar files.

GitHub Models

As I'm using the free version, I utilized the default Copilot model, GPT-35-Turbo, for my coding tasks. This model is incredibly efficient and provides reliable suggestions, making development faster and more manageable..

Conclusion

After using GitHub Copilot, I realized how easy it has become to complete small projects. Tasks that I previously abandoned because they took too much time or felt mundane can now be completed effortlessly with Copilot. It handles the repetitive work, allowing me to focus on the core and more creative aspects of development.

P.S habit is my favourite app if you want to create a habit you should try it.

Debugging 2024

Mehak. — Sun, 12 Jan 2025 15:55:30 +0000

This is a submission for the 2025 New Year Writing challenge: Retro’ing and Debugging 2024.

As new year has started I'll refect to things happen in 2024, its high,low and everything in between.

What went well

Healthwise:
2024 marked a significant improvement in my physical health. I managed to shed 5 kg, a result of better self-control and consciously addressing my overeating habits.
Careerwise:
I began my journey as a Senior Frontend Developer at a new company. Connected with some awesome developers and learned many things.

What Didn't went well

Transition to Web3:
I had set a goal to transition into Web3, but I didn’t see it through.I didn't work hard and smart enough for this.

Doomscrolling:
I spent too much time mindlessly consuming content, which often left me unproductive and unmotivated.

Unfinished Projects:
Started side projects and abandoning them halfway.This habit of jumping between tasks diluted my focus and left me with a list of incomplete projects.

Lesson Learned

Health is a Lifestyle, Not a Goal:
Crash dieting or sporadic exercise won’t achieve lasting health. I’ve realized the importance of making fitness a lifestyle—walking 10,000 steps almost daily, eating mindfully, and staying consistent with my habits.

Specific Goals Lead to Success:
Vague ambitions are ineffective. For instance, instead of saying “I want to learn a new framework,” I need a clear, actionable plan: decide which framework to learn, set a timeline, and identify resources to practice.

Finish What I Start:
Jumping between tasks hinders progress. Before starting anything, I need to ask:
How will this improve my skills or life?
What value will it add?
By committing fully, I can avoid wasted time and see things through to completion.

Step Out of My Comfort Zone:
Growth lies in discomfort. This year, I’m challenging myself to embrace situations and tasks I’d typically avoid.

Review Goals Regularly:
Weekly and monthly reviews are essential for tracking progress and identifying what’s not working. These checkpoints will help me course-correct and stay aligned with my larger objectives.

PS: This is my first article, also something I would avoid in past. But it's time to grow.

DEV Community: Mehak.

Building Node.js CLI Tool.

How OS Executes Script Files

How npm Installs CLI Tools Globally

The bin Field in package.json

Parsing Command-Line Arguments

Making the Tool Work Locally — npm link

Final Project

Integrating Playwright with Next.js — The Complete Guide

What is Playwright?

How Playwright Works

Why Playwright

Codegen — Write Tests Without Writing Them

Understanding Fixtures

Integrating Playwright with Next.js

Running Tests in Different Modes

⚠️ Note on Mocking: MSW with Playwright vs Jest

Try It Yourself

Mock Service Worker (MSW) in Next.js – A Guide for API Mocking and Testing

What is MSW?

How Does MSW Work?

Why MSW ??

MSW in the Browser

MSW with Jest for Testing

Polyfills Required for Node + JSDOM

Conclusion

Full Setup

Understanding Shadow DOM by Building a Poll Plugin

🌐 What is Shadow DOM?

🔑 Key Concepts

🧵 Modes: open vs closed

🔁 Communicating with the Light DOM

📝 Important Clarification

🧪 Let's Build a Real Plugin: Poll Widget

🗂 Folder Structure

⚙️ How It Works

💬 Listening for Poll Votes

🛠 Bundling with Vite

🔗 How to Use It in Any Website

🧾 Full Source Code

📬 Understanding GitHub Webhooks: Send Email Notifications on Pull Request Events Using Node.js

🔐 First, What’s HMAC?

🧩 Webhook Levels

🔎 Signature Verification

Here’s how I do it:

🔸 Express Middleware

🔸 Signature Verifier (utils/verifier.js)

📬 Sending Email Notifications

🔸 Mailer (services/emailService.js)

🚀 Exposing the Server for GitHub to Reach

✅ Summary

Building Quizo: A Quiz App Using Kendo React Components and GenAI

What I Built

Demo

KendoReact Experience

Home page

Subject page

Quiz page

AIm to Impress

Final Thoughts

Advent of spring

Inspiration

Demo

Journey

Pair Programming Redefined: My Journey with Copilot

I created the mini web version of the habit.

Demo

Repo

Copilot Experience

GitHub Models

Conclusion

Debugging 2024

What went well

What Didn't went well

Lesson Learned

🧵 Modes: `open` vs `closed`

🔸 Signature Verifier (`utils/verifier.js`)

🔸 Mailer (`services/emailService.js`)