Forem: CinfiniteDev

🗺️ Fixing Ola Web’s Cramped Map — and Why Small UX Gaps Ship to Production

CinfiniteDev — Mon, 13 Apr 2026 22:33:39 +0000

So, I was using the Ola web app recently and ran into something just… odd.

The map — arguably the most important part — was stuck in a tiny section of the screen.

No fullscreen button
No resize option
No setting to change it

Just… a constrained map UI.

🤔 The Obvious Question

Why can’t I expand this?

And more importantly:

Why do I have to wait for the app to fix it?

💡 A Simple Hack

Instead of working around the UI, I decided to override it.

I wrote a small bookmarklet that:

injects a button into the page
expands the map to full usable size
lets me toggle it back

No extensions. No installs. Just a click.

🔖 Why a Bookmarklet?

Because it’s the lowest-friction way to modify a live website:

runs instantly in the browser
no setup or permissions
works directly on the DOM

It’s essentially a tiny user-side patch.

⚙️ What It Does

Nothing complex — just direct DOM manipulation.

👉 Repo: https://github.com/cinfinit/ola-web-bookmarklet

🧠 But This Isn’t Really About the Bookmarklet

While building this, a more interesting question came up:

How do small UX gaps like this make it to production?

This isn’t a crash.

It’s not even a “bug” in the traditional sense.

It’s just… missing functionality.

⚙️ Why These Gaps Slip Through

From the outside, it’s easy to say:

“frontend should’ve fixed this”
“design missed it”
“QA didn’t catch it”

But in reality, production systems are shaped by constraints:

shipping deadlines > polish
core flows > edge usability
measurable metrics > subjective friction

If the map technically works, it ships.

Even if the experience isn’t great.

But should it be that way? We’ll get to that.

📉 The Problem with “Small” UX Issues

These issues are hard to catch because:

they don’t break anything
they don’t throw errors
they don’t trigger alerts
they rarely show up clearly in analytics

But they silently degrade the experience.

And over time, that adds up.

👀 Who Owns This?

The uncomfortable answer:

No one fully owns these gaps.

They sit in between:

design decisions
frontend implementation
product prioritization

Which makes them easy to overlook.

🛠️ How Do We Prevent This?

You can’t eliminate these issues completely — but you can reduce them.

1. Treat UX Friction as a First-Class Signal

Not everything important shows up in metrics.

watch real user sessions
collect qualitative feedback
pay attention to “annoyances,” not just failures

2. Add “UX Sanity Checks” Before Shipping

Alongside QA, ask:

“Is this actually comfortable to use?”
“Are key interactions constrained unnecessarily?”

These are simple questions, but often skipped.

3. Build Small Internal Tools

Encourage engineers to:

prototype quick fixes
experiment with UI improvements

This bookmarklet is exactly that — a lightweight experiment.

4. Close the Gap Between Design and Reality

Sometimes designs look fine, but:

screen constraints
layout nesting
real-world usage

…make them worse in practice.

Regularly test in real conditions, not just mockups.

5. Track “Minor” Issues Somewhere

Not everything deserves a sprint.

But having a place for:

small UX gaps
polish improvements

…prevents them from disappearing completely.

💡 A Different Mindset

This experience changed how I think about production apps:

The UI you see isn’t final — it’s just what shipped under constraints.

🧩 Takeaway

Not every missing feature needs a feature request.

Sometimes:

the fix is small
the impact is real
and the fastest path is doing it yourself

In this case, it was just a bookmarklet.

But yes — a production fix is a production fix.

Here's how the fix looked

🚀 Try It

If you want to try the bookmarklet:

https://github.com/cinfinit/ola-web-bookmarklet

Takes less than a minute to set up.

From Chaos to Control: Multiple Node.js Environments with Multi-Env CLI

CinfiniteDev — Wed, 25 Mar 2026 23:10:11 +0000

⚡ Multi-Env CLI

Stop juggling .env files for Node.js projects. Run multiple environments side-by-side with hot-reload support.

💡 Why Multi-Env CLI?

If you’ve ever worked on a Node.js project, you know the pain of juggling multiple environments.

For testing a feature across dev, staging, and prod, every time we needed to tweak an environment variable, we typically:

🛑 Stop the server
📄 Copy .env to .env.staging or .env.prod
🔄 Restart the app
👀 Double-check which instance was running

By the end of the day, we had three terminals open, three versions of .env floating around — it felt like manually juggling spinning plates.

💡 The Thought

There has to be a better way.

That’s how Multi-Env CLI came to life — a small CLI tool that:

🚀 Runs multiple Node.js instances at the same time
✏️ Lets you edit environment variables live without restarting
🔒 Keeps your original .env files untouched
🛠️ Makes it easy to list, kill, and manage instances

🔥 Pain Points Solved

Before Multi-Env CLI, developers often ran into:

📂 Constantly copying .env files for each environment
🔄 Restarting the server every time a variable changes
🤯 Losing track of which instance is running which environment

With Multi-Env CLI, all of that is gone:

📝 Temporary env files for each instance
⚡ Hot reload — editing the temp env automatically restarts the app
📋 Instance management — list, kill, and clean up instances safely

🛠️ Typical Workflow

Generic Multi-Env CLI Command

npx multi-env run --env-file <path-to-env-file> --cmd "<your-command>"

Run a staging instance

npx multi-env run --env-file .env.staging --cmd "node server.js" --auto-cleanup

Edit Environment Variables Live

Open .multi-env/env.temp.

Change variables and save → the app restarts automatically

Run Production Instance Simultaneously

npx multi-env run --env-file .env.prod --cmd "node server.js"

List Running Instances

npx multi-env list

Kill Any Instance When Done

npx multi-env kill --id <instance-id>

✨ Key Features

📝 Hot-editable env files — no more manual restarts
🔀 Run multiple instances side by side (dev, staging, prod)
📂 CLI-managed temp files — original .env stays safe
🛡️ Crash-safe — dead instances are cleaned automatically
⚡ Plug-and-play — works with any Node.js project

👥 Who It’s For

💻 Node.js developers running multiple environments locally
🧪 Teams testing feature flags or environment-dependent features
🚀 Anyone doing rapid prototyping, CI/CD testing, or multi-tenant apps

🚀 Getting Started

Install globally:

npm install -g multi-env-cli

Or use via npx without installing:

npx multi-env run

📂 Temp Env Files

All temp env files are stored in .multi-env/ inside your project

Original .env files are never modified

Editing temp env files triggers auto-restart for the specific instance

🏁 Ending Note

Multi-Env CLI was built to make working with multiple Node.js environments simpler, faster, and safer. No more juggling .env files, restarting servers manually, or losing track of instances.

Whether you’re testing feature flags, running dev/staging/prod side by side, or experimenting with rapid prototyping, this tool helps you stay in control — and keeps your workflow smooth and stress-free.

Give it a try, and see how much easier managing Node.js environments can be! 🚀

“Temp files are my playground — shuffle, duplicate, or vanish them without breaking a sweat.” — The Env Whisperer

npm link: https://www.npmjs.com/package/multi-env-cli

🧩 Next Component Analyzer: Stop Guessing if Your Components Should Be Server or Client

CinfiniteDev — Wed, 18 Mar 2026 08:41:28 +0000

Ever added "use client" somewhere in your Next.js app just because "it might need state" — and then wondered a week later?

"Wait… does this even need to be a client component?"

Yeah… we’ve all been there.

This is the story of Next Component Analyzer: the tool built to stop guessing and help you classify components correctly, every time.

🔍 From Developer Pain to Solution

Working with Next.js, I noticed a pattern: developers often overuse "use client". Why?

They’re not sure if a component uses state or browser APIs
They’re following a habit: “Better safe than sorry”
A missed "use client" can break hooks or event handlers

But overusing "use client" isn’t harmless — it can:

Increase bundle size
Move server-renderable components to the client unnecessarily
Make your project harder to maintain , it wont just appear like that , but it can , you never know.

Wanted a way to audit components automatically and answer the question:

“Does this component really need to be a client component?”

That’s how Next Component Analyzer was like build me .

🛠 What Next Component Analyzer Does

Next Component Analyzer is your CLI sidekick for Next.js:

Scans your entire project
Detects React hooks, browser APIs, and JSX events
Suggests whether a component should be Server or Client
Highlights unnecessary "use client" directives

It’s AST-based, so it doesn’t rely on naive string matching — no false positives here.

📊 Component Classifications

The analyzer classifies components into four meaningful categories:

Category	What it means
Client Component (correct)	Has client features and `"use client"`
Suggested: Client Component	Has client features but missing `"use client"`
Suggested: Server Component	No client features, no `"use client"`
Could be Server Component (unnecessary client)	`"use client"` is present, but no client features

⚡ Installation & CLI Usage

Run without installing:

npx next-component-analyzer

Or install globally:

npm install -g next-component-analyzer
next-component-analyzer

The CLI will scan your project and produce a classification report.

💻 Programmatic Usage

Perfect for CI pipelines, dashboards, or custom scripts:

import { analyzeProject } from "next-component-analyzer";

async function run() {
  const results = await analyzeProject();
  console.log(results);
}

run();

Example output:

[
  {
    "filePath": "app/page.tsx",
    "classification": "server",
    "detected": ["fetch"]
  },
  {
    "filePath": "components/button.tsx",
    "classification": "client",
    "detected": ["useState", "useEffect"]
  }
]

✅ Integrate results into CI checks, dashboards, or editor tools.

🌟 Why This Matters

Next Component Analyzer helps you:

Keep your Next.js apps lean
Avoid unnecessary client components
Automatically enforce component architecture rules
Reduce bugs caused by forgotten "use client" directives

It turns guesswork into data-driven decisions, saving time and improving performance.

🧠 Philosophy

Every component should answer a simple question:

“Do I actually need to be a client component?”

Next Component Analyzer gives you the answer. By analyzing hooks, browser APIs, and events, it ensures intentional "use client" usage — no more guesswork, no more cluttered client bundles.

🔗 Try It Yourself

npx next-component-analyzer

Scan your Next.js project today and see exactly which components should be server, which should be client, and which might be overdoing it.

Here's the link to package : https://www.npmjs.com/package/next-component-analyzer

🕵️‍♂️ Dependencies Should Not Be Silent: Inspect What Your npm Packages Actually Do

CinfiniteDev — Mon, 16 Mar 2026 06:49:42 +0000

SO ,

Every time you run:

npm install some-package

you are executing someone else's code on your machine.

But here’s the uncomfortable truth:

Do you really know what that code is doing?

Most don’t.

🚀 From User to Producer: How I Realized the Risk

Before I first started building npm packages, I was just a user like everyone else. Install a package, trust it works, move on.

But when you switch from user → producer, everything changes: you see how packages execute, which scripts run automatically, and the sheer power even a tiny package can hold.

Then I read about this: npm supply-chain attack happened sometime back.

A single compromised package could affect millions of machines.

💡 That’s when I thought:

“Even a small package can impact huge systems. What if we could see what it does before we install it?”

That thought sparked npm-telemetry.

⚠️ The Problem With Blind Trust

npm packages can:

🌐 Make network requests
📁 Access the file system
🔐 Read environment variables
⚙️ Spawn child processes
🧙 Execute dynamic code (eval / new Function)
📦 Run postinstall scripts

Most developers only realize this after something goes wrong. Supply-chain attacks are becoming increasingly common — and frighteningly easy.

npm-telemetry gives visibility upfront, letting you make informed decisions before installing.

🛠 Introducing npm-telemetry

npm-telemetry is a lightweight CLI and Node.js library that inspects packages and reports on their capabilities.

Think of it as a nutrition label for npm packages: you inspect, you understand, you trust consciously.

What It Detects

🌐 Network access
📁 File system read/write
🔐 Environment variable access
⚙️ Child processes
🧙 Dynamic execution (eval / new Function)
📦 Postinstall scripts

It also calculates an analysis coverage score, so you know how thoroughly the package was inspected.

🏃‍♂️ Getting Started

No global installation needed. Run:

npx npm-telemetry <package_name>

Example:

npx npm-telemetry axios

Output:

🔍 Analysis Report: axios
Permissions:
🌐 Network: YES
📁 FS Read: NO
📁 FS Write: NO
🔐 Env Access: NO
⚙️ Child Process: NO
⚠ Dynamic code execution: NO
⚠ Postinstall script: null

✅ Instantly know what the package is capable of doing.

💻 Programmatic Usage

Integrate npm-telemetry into CI pipelines, dashboards, or custom scripts.

CommonJS

const analyzePackage = require("npm-telemetry");

(async () => {
  const result = await analyzePackage("axios");
  console.log(result.coverage);
  console.log(result.report.network);
})();

ES Modules

import analyzePackage from "npm-telemetry";

const result = await analyzePackage("axios");
console.log(result.coverage);
console.log(result.report.network);

Returned object:

{
  "package": "axios",
  "coverage": 92,
  "report": {
    "fsRead": false,
    "fsWrite": false,
    "network": true,
    "env": false,
    "childProcess": false,
    "usesEval": false,
    "dynamicRequire": false,
    "postinstall": null
  }
}

🔬 How npm-telemetry Works

Under the hood:

Scans package code for sensitive APIs
Detects dynamic code (eval, new Function)
Flags postinstall scripts
Generates a coverage score

💡 No execution happens on your machine, keeping it safe.

[Package] 
    ↓
[npm-telemetry analysis] 
    ↓
[Permissions report & coverage score]

🛡 Why This Matters

npm-telemetry:

Makes dependency behavior visible
Lets developers audit packages before installing
Helps enforce security policies
Enables custom risk scoring

Not to accuse packages, but to give developers conscious control.

💡 Philosophy

Every dependency should answer one question:

“What am I doing on your system?”

npm-telemetry provides visibility, honesty, and peace of mind.

Software shouldn’t be magic — trust should never be blind.

✅ Try It Yourself

npx npm-telemetry <package_name>

Inspect any npm package before installing it — you may be surprised at what you discover.

Here's the link to package : https://www.npmjs.com/package/npm-telemetry