DEV Community: Nitin Kumar Yadav

I Spent 3 Days Building a CLI for an Open Source Project. Here’s What Actually Happened.

Nitin Kumar Yadav — Sun, 05 Jul 2026 15:47:49 +0000

I'm a second-year IT engineering student. What I do have is GitHub, a laptop that overheats, and a habit of picking up problems that are slightly too big for me.

This is the story of how I built the official CLI for urBackend a BaaS (Backend as a Service) platform from scratch, over three hard days, and somehow got it merged.

How I Found This

I was scrolling through GSSOC (GirlScript Summer of Code) organizations looking for something interesting to contribute to. Most projects wanted documentation fixes or UI tweaks. Then I saw urBackend:

"The developer's backend. Instantly generate secure CRUD APIs for your frontend applications using Node.js and MongoDB. Focus on the UI, let us handle the DB."

That got me. It's a real product. Real users. Real codebase. And they had an open issue for something ambitious — building an official CLI tool so developers could manage their projects from the terminal instead of clicking through a dashboard.

I claimed it.

What I Was Building

The idea was simple: a command called ub that lets developers do things like this from their terminal:

ub login
ub project list
ub collection list
ub status
ub doctor

No browser. No dashboard. Just the terminal.

The CLI needed to talk to urBackend's dashboard API using Personal Access Tokens — basically long-lived keys that prove you're a real developer without needing a browser session.

Simple enough on paper. Three days of reality had other plans.

Day 1: Building the Foundation

I scaffolded the entire CLI in TypeScript using Commander.js and tsup. The architecture I landed on had a clean separation:

core/ — HTTP client, config reader/writer, logger, error classes
services/ — pure API wrappers, no console output, no filesystem
commands/ — orchestrate service calls and print results
types/ — TypeScript interfaces for every API response

The rule I enforced on myself: commands never touch JSON directly. Config persistence goes through config.ts. Network calls go through services/. Commands only orchestrate and print.

One thing I'm proud of from day one is atomic config writes. When you run ub login, your token gets saved to ~/.ub/config.json. If the process crashes mid-write, you don't end up with a corrupted file. The trick is simple:

const tmp = CONFIG_PATH + ".tmp";
fs.writeFileSync(tmp, JSON.stringify(config, null, 2));
fs.renameSync(tmp, CONFIG_PATH);  // atomic on most OS

Write to a temp file first. Rename it. The rename either completes or it doesn't — there's no half-written state. Small thing. Matters in production.

By end of day one, the build was compiling clean and ub --help was showing commands. Nothing actually worked yet, but it existed.

Day 2: The Most Frustrating Six Hours of My Life

This is the part I almost didn't include. But it's the most honest part, so here it is.

I tried to run ub login against the local backend. I pasted my test token. And I got this:

✓ Logged in successfully.
✖ Unable to connect to the urBackend API.

Success and failure. At the same time. For six hours.

The first problem was that the PAT UI wasn't built yet. The dashboard had no "Generate Token" page. So I had to manually insert a fake token directly into MongoDB by computing its SHA-256 hash and writing it to the pats collection. That took an hour just to figure out.

const raw = 'ubpat_test_localdevtoken123';
const hash = crypto.createHash('sha256').update(raw).digest('hex');
db.pats.insertOne({ developer: ObjectId('...'), tokenHash: hash, ... });

Second problem: even after fixing that, ub login would print "Logged in successfully" and then immediately print "Unable to connect." I added a debug line to see the raw API response:

{
  "error": "Not Found",
  "replayId": "kiroo-1782642930559-63fbf1"
}

Not Found. But the curl command worked fine. Same token. Same endpoint. Different result.

I spent two hours on this before I realized: every time I ran ub login before setting the URBACKEND_API_URL environment variable, the CLI saved https://api.urbackend.bitbros.in (the production URL) to ~/.ub/config.json. Then even after I set the env variable, the config file took priority and the CLI kept hitting production.

rm ~/.ub/config.json
export URBACKEND_API_URL=http://localhost:1234
ub login

That fixed it. One deleted file. Six hours of debugging.

The third problem was CSRF. The dashboard API protects all routes with CSRF tokens for browser sessions. The CLI doesn't use cookies — it uses Bearer tokens — but CSRF middleware was still running and blocking requests. I had to add a bypass in app.js:

if (req.path === '/api/billing/webhook' || req.path.startsWith('/api/user/cli')) {
    return next(); // skip CSRF for CLI routes
}

The fourth problem: all the project routes used authMiddleware which validates JWT session cookies. The CLI sends a Bearer PAT token. So every ub project list call got "Invalid Token."

The fix was a new middleware called authFlexible.js:

const authFlexible = (req, res, next) => {
    const authHeader = req.headers.authorization;
    if (authHeader && authHeader.startsWith('Bearer ubpat_')) {
        return authenticateCLI(req, res, next);
    }
    return authMiddleware(req, res, next);
};

One middleware. Accepts both. Browser requests unchanged. CLI requests work.

By end of day two, ub login, ub whoami, ub project list, ub project use, and ub collection list were all working.

Day 3: CI, Review Comments, and What I Learned About Hidden Files

I opened the PR on day three. 12 commits. The CI pipeline immediately failed:

FAIL src/__tests__/routes.user.test.js
  ● Test suite failed to run
    REDIS_URL is not defined in .env

My authenticateCLI middleware imports from @urbackend/common, which imports Redis, which crashes on import if REDIS_URL isn't set. The test environment didn't have it.

Two fixes. First, add the env var to CI:

env:
  REDIS_URL: redis://localhost:6379

Second, mock the middlewares in the test file so the ESM import chain never reaches Redis:

jest.mock('../middlewares/authenticateCLI', () =>
    jest.fn((req, _res, next) => { req.user = { _id: 'mock_user_id' }; next(); })
);

155 tests passing. 0 failing.

Then came the review comments. The maintainer pointed out that my ub doctor command was collapsing all errors into the same bucket. A timeout looked the same as a bad token, which would tell users to re-login when the real problem was connectivity.

He was right. I added a three-state system:

true — check passed
false — definitively failed (HTTP 401, 404)
"unknown" — could not validate due to network or 5xx

So now ub doctor shows:

⚠  PAT    Could not validate — API may be unreachable

instead of:

✖  PAT    Invalid or expired — run 'ub login'

when the server is just down. Small change. Much less confusing for users.

Things I Actually Learned

PATs (Personal Access Tokens) — I had used GitHub tokens before without thinking about how they work. Building this made it concrete: the raw token is shown once and never stored. What gets stored is a SHA-256 hash. When you authenticate, your token gets hashed and compared against the stored hash. The raw token never touches the database.

Hidden files start with a dot — ~/.ub/config.json is hidden because the folder is .ub. That's it. No special flag, no metadata. Just a dot prefix. Same reason you never see .gitconfig, .npmrc, or .ssh in your home folder without ls -a. Decades-old Unix convention that every CLI tool follows.

CSRF doesn't apply to Bearer token auth — CSRF attacks work by tricking a browser into making requests using its stored cookies. If you're not using cookies, CSRF protection does nothing useful. The CLI uses Bearer tokens, not cookies, so bypassing CSRF for CLI routes is correct and safe.

Tests mock things for a reason — The marked package is ESM-only. Jest runs in CommonJS mode. When my middleware imported @urbackend/common, which imported emailService.js, which imported marked, the entire test suite crashed. Mocking the middleware in tests isn't laziness — it's isolating what you're actually testing.

Read the config file before debugging for six hours — If something worked yesterday and doesn't today, check your config file first.

The Final Command List

ub login              # authenticate with PAT
ub logout             # remove stored credentials
ub whoami             # show authenticated developer
ub project list       # list all projects with usage
ub project use        # select active project
ub project info       # show project details
ub collection list    # list collections with schema
ub collection delete  # delete collection (with confirmation)
ub status             # account plan, limits, recent activity
ub doctor             # diagnostic checks
ub doctor --json      # same output as JSON for CI/AI agents

The --json flag on ub doctor is something I'm especially happy with. AI agents and CI pipelines can consume it directly without parsing terminal output. One command tells you everything about your setup in a machine-readable format.

What's Next

ub pull, ub push, and ub generate aren't implemented yet — they need a schema sync endpoint on the backend that doesn't exist yet. That's Phase 3 of the roadmap. I'll build it when the backend is ready.

Why I'm Writing This

I'm a second-year student with no internship and no referral. What I have is a merged PR in a real open source project, a CLI that actual developers will use, and a much better understanding of how auth middleware actually works.

If you're in the same position — no experience, no connections — find a project with a real issue, claim it, and do the work. The debugging is miserable. The CI failures are annoying. The review comments sting a little. But the PR number at the end is real, and nobody can take it away.

PR #340 if you want to see the code: github.com/geturbackend/urBackend/pull/340

Follow me on X for more open source, systems programming, and the unglamorous parts of learning to code.*

👉 @KATSUKI_EXPO
👉 Github

Courage Browser — 1 month Later: CSS Variables, Tabs, Link Navigation & More

Nitin Kumar Yadav — Sat, 09 May 2026 16:25:47 +0000

1 month ago I posted about building a browser from scratch — no Chromium, no WebKit, no libraries. Just Node.js, Electron, and a Canvas to draw on.

👉 Missed Part 1? → "I Built a Web Browser from Scratch in 42 Days"

That post covered the first 42 days: raw TCP connections, HTML tokenizer, DOM builder, CSS parser, layout engine, and a working Canvas renderer. Basic text showed up. It was exciting but rough.

Since then — approximately 30 more days of building. Here's what Courage can do now.

🆕 What shipped in Days 43–57

Tabs

The most visually obvious change. Courage now has a working tab system:

+ button creates a new tab
Each tab maintains its own history, URL, and rendered page
Clicking a tab switches context; the × button closes it
Active tab is highlighted

Every tab is fully independent — opening a link in a new tab doesn't share state with others.

Clickable Links (Anchor Navigation)

This one took the most debugging. The challenge: Canvas 2D has no DOM events — I had to implement my own hit-testing.

When you click the canvas, Courage:

Gets the click coordinates via canvas.getBoundingClientRect()
Walks the layout boxes looking for an anchor whose bounding rect contains that point
If found, navigates to the href

I also added a pointer cursor on hover — mousemove triggers the same hit-test, and if the cursor is over a link, cursor: pointer is set on the canvas element. Small detail, huge feel difference.

External CSS Fetching

Before Day 44, Courage only read <style> blocks inline. Now it fetches external stylesheets — it looks for <link rel="stylesheet"> tags in the DOM, fires a second HTTP request for each one, and merges the rules into the cascade. This is what made real sites start to look like real sites.

Class & ID Selector Matching

Added proper .className and #idName selector support. Before this, only tag selectors (h1, p, a) worked. Now the full selector matching order is:
tag → class → ID → pseudo-class (:link, :visited)

CSS `var()` Resolution — The Big One

GitHub, Wikipedia, and most modern sites define their entire color scheme using CSS custom properties like --color-fg-default on :root. Without var() support, everything was either black or invisible.

I added:

A new computed-styles.js module with a getComputedStyle() function
:root selector support so variables defined globally actually register
parentNode references in dom-builder.js so the resolver walks up the tree correctly
Pipeline wiring in browser.js to run computed styles after selector matching

The resolver works recursively — var(--x) where --x is itself var(--y) chains correctly.

UA Stylesheet + `em` Units + Bold/Italic

Three smaller but visible wins:

UA stylesheet: Added browser default styles — h1 is now big and bold, h2 slightly smaller, etc. Before this, every element rendered the same size.

em units: Font sizes expressed as 1.5em or 2em now compute correctly via a headingSizes lookup table relative to the parent's font size.

Bold/italic fix: The Canvas ctx.font string has a strict format — bold 16px serif works, 16px bold serif does not. Fixed a bug where both were silently ignored even when the styles matched correctly.

📸 Current state

Here's how Courage has evolved:

Day 42	Day 57
Text renders, basic colors	Tabs, links, h1 large & bold
Inline CSS only	External CSS fetched over network
No link clicking	Click navigates, hover shows pointer cursor
No CSS variables	`var()` resolves recursively

🔭 What's next: Attribute Selectors

The next open issue is attribute selector matching — things like:

[data-color-mode="dark"] { ... }
[rel="stylesheet"] { ... }
[type="text"] { ... }

GitHub's entire dark theme is gated behind [data-color-mode="dark"] on the <html> element. Once this lands, CSS variables on GitHub and Wikipedia will finally resolve to the right values.

After that: image rendering. <img> tags currently just get skipped.

💻 Code

Everything is open source:

👉 github.com/Nitin-kumar-yadav1307/Courage

I post updates here as milestones land. If you're curious about how browsers actually work — the TCP handshake, the tokenizer state machine, the CSS cascade, the layout algorithm — the code is readable and heavily iterative. No magic, no black boxes.

Day 57. Still going.

"I Built a Web Browser from Scratch in 42 Days — No Libraries, Just Node.js"

Nitin Kumar Yadav — Sat, 04 Apr 2026 19:02:26 +0000

I Built a Web Browser from Scratch in 42 Days

42 days ago I made a decision.

I wanted to understand how the internet actually works. Not just use it. Not just build on top of it. Actually understand it — at the wire level.

So I started building a web browser from scratch. In Node.js. No external libraries. Every line written by hand.

I called it Courage.

What Courage can do today

...

Parse URLs into protocol, host, port, path
Open raw TCP and TLS connections
Build and send HTTP GET requests
Parse HTTP responses including chunked encoding
Tokenize raw HTML character by character
Build a DOM tree using a stack
Match CSS rules to DOM nodes
Calculate layout (x, y, width, height) for every element
Paint rectangles and text on a Canvas using Electron
Execute JavaScript via eval()
Navigate with back, forward, reload
Multiple tabs with independent history
Render real websites — today it rendered Wikipedia

What I learned

Before this project I knew how to use the web. Now I understand it.

TCP handshakes aren't magic. HTTP is just text. HTML is just tokens. CSS is just rules. A browser is just a pipeline.

Every abstraction that used to feel like magic now makes complete sense.

The most surprising thing — a layout engine is just two passes over a tree. Width flows down from parent to child. Height bubbles up from child to parent. That's it. That's what every browser does.

The hard days

Day 9 — built a DOM tree using a stack. Failed 6 times before it clicked.

Day 21 — layout engine born. Took 3 days to get width and height right.

Day 42 — fixed a bug where CSS inside style tags was breaking the entire DOM tree because my tokenizer treated > in CSS selectors as HTML tag endings.

Every bug taught me something real.

The code

github.com/Nitin-kumar-yadav1307/Courage

42 days. No libraries. Every line by hand.

This is just the beginning.

BugVaulty — Auto-Track Every Error to Notion with AI Solutions 🐛

Nitin Kumar Yadav — Sat, 28 Mar 2026 07:23:31 +0000

🤖 This is a submission for the Notion MCP Challenge

What I Built

BugVaulty is an npm package that automatically catches
every error in your Node.js, Express, or React app — analyzes
it with AI — and saves it to Notion automatically.

No manual work. One line of code. Forever.

In my early coding journey, I used to write down errors because it's one of the best ways to debug. If you already know how an error happened, it becomes easier to fix.

Also, if you're working in a team, everyone can see the errors and help debug them, so you don't have to search the same error again and again on Google or AI.

So I automated this process using Notion, MCP, and AI. Once you install and configure this package, all the errors from your terminal will automatically be tracked in your Notion.

How it works:

Error happens in your app
        ↓
BugVaulty catches it automatically
        ↓
AI analyzes it (Groq / OpenAI / Claude)
        ↓
Notion page created automatically with:
  📅 Date & Time
  📁 File path & line number  
  ❌ What went wrong
  💡 Step by step solution
  🔧 Code fix
  🚀 How to avoid it
  ⭐ Difficulty rating
  🏷️ Tags

One line setup:

require('dotenv').config();
const bugvaulty = require('bugvaulty');

bugvaulty.init();
// That's it! All errors now tracked to Notion automatically

Supports 3 AI providers:

// Free option - Groq
bugvaulty.init({ ai: { provider: 'groq', apiKey: 'gsk_xxx' }})

// OpenAI
bugvaulty.init({ ai: { provider: 'openai', apiKey: 'sk-xxx' }})

// Anthropic Claude
bugvaulty.init({ ai: { provider: 'claude', apiKey: 'sk-ant-xxx' }})

Works with Express:

app.use(bugvaulty.expressMiddleware());

Works with React:

import { BugVaultyProvider } from 'bugvaulty/react';

<BugVaultyProvider keys={{...}}>
  <App />
</BugVaultyProvider>

What Notion looks like after an error:

Every project gets its own page in Notion — detected automatically from your package.json name!

Video Demo

Show us the code

📦 npm package

💻 GitHub

Install it:

npm install bugvaulty

How I Used Notion MCP

Notion MCP is the entire backbone of BugVaulty.

Instead of building a custom database or dashboard,
I used Notion as the storage and display layer via
the Notion API and MCP.

Here is what Notion MCP unlocks:

1. Auto project organization
BugVaulty detects your project name from package.json
and automatically creates a dedicated Notion page for
that project. Every error goes under the right project
automatically.

2. Rich structured pages
Each error is saved as a beautifully structured Notion
page with headings, bullet points, and code blocks —
not just plain text.

3. Searchable knowledge base
Because everything is in Notion, you can search your
entire error history instantly. Next time you hit the
same error — your own solution is already there.

4. Zero infrastructure
No custom dashboard needed. No database to maintain.
Notion IS the interface. This is what makes Notion MCP
so powerful for developer tools.

BugVaulty + Notion MCP = your personal AI debugging
brain that never forgets. 🧠

⚡ GitZip — Turning Git Commands into One-Word Spells with GitHub Copilot CLI

Nitin Kumar Yadav — Tue, 10 Feb 2026 05:11:28 +0000

What I Built

GitZip is a CLI productivity tool that turns long and hard-to-remember Git commands into short, reusable one-word "spells".

Instead of repeatedly typing complex Git commands or copy-pasting them from Google or ChatGPT, developers can save a command once and reuse it instantly.

For example, instead of running:

git reset --soft HEAD~1

I can save it as a spell called gundo and run it anytime with a single word.

GitZip focuses on improving developer productivity, reducing mistakes, and making Git easier to use — especially for beginners.

Demo

🎥 Demo Video:

for demo video click here

The demo shows:

Creating a Git command spell
Running the spell inside a Git repository
Using gitzip demo, which automatically:
- Initializes a Git repository
- Creates commits
- Creates a spell
- Undoes a commit
- Shows before/after Git logs

This makes it very easy for judges to test and understand the project.

My Experience with GitHub Copilot CLI

GitHub Copilot CLI played an important role in my development workflow.

While building GitZip, I frequently used Copilot (CLI / Chat) to:

Ask for correct Git commands
Understand safer alternatives to risky Git operations
Validate commands before saving them as reusable spells

GitZip is designed around this exact workflow:
Ask GitHub Copilot for a Git command → Save it once → Reuse it forever.

Instead of replacing Copilot, GitZip extends it by making Copilot's output reusable inside the terminal. This helped me build faster, avoid mistakes, and focus on designing a better user experience.

Source Code

🔗 GitHub Repository:

https://github.com/Nitin-kumar-yadav1307/GitZip

DEV Community: Nitin Kumar Yadav

I Spent 3 Days Building a CLI for an Open Source Project. Here’s What Actually Happened.

How I Found This

What I Was Building

Day 1: Building the Foundation

Day 2: The Most Frustrating Six Hours of My Life

Day 3: CI, Review Comments, and What I Learned About Hidden Files

Things I Actually Learned

The Final Command List

What's Next

Why I'm Writing This

Courage Browser — 1 month Later: CSS Variables, Tabs, Link Navigation & More

🆕 What shipped in Days 43–57

Tabs

Clickable Links (Anchor Navigation)

External CSS Fetching

Class & ID Selector Matching

CSS var() Resolution — The Big One

UA Stylesheet + em Units + Bold/Italic

📸 Current state

🔭 What's next: Attribute Selectors

💻 Code

"I Built a Web Browser from Scratch in 42 Days — No Libraries, Just Node.js"

I Built a Web Browser from Scratch in 42 Days

What Courage can do today

What I learned

The hard days

The code

BugVaulty — Auto-Track Every Error to Notion with AI Solutions 🐛

What I Built

How it works:

One line setup:

Supports 3 AI providers:

Works with Express:

Works with React:

What Notion looks like after an error:

Video Demo

Show us the code

How I Used Notion MCP

⚡ GitZip — Turning Git Commands into One-Word Spells with GitHub Copilot CLI

What I Built

Demo

My Experience with GitHub Copilot CLI

Source Code

CSS `var()` Resolution — The Big One

UA Stylesheet + `em` Units + Bold/Italic