DEV Community: Ishika Thakur

Building PackageGuard: Dependency Traversal, External APIs, and Explainable Risk Scoring in TypeScript

Ishika Thakur — Thu, 15 Oct 2026 13:09:51 +0000

First, what exactly is PackageGuard?

PackageGuard is a TypeScript command-line tool that scans a Node.js project's dependencies and flags packages that may deserve security scrutiny.

The problem it addresses is dependency risk.

Imagine you're building a backend service. You install a package to make an HTTP request, parse a file, or handle authentication. That package may itself depend on other packages, and those packages may have dependencies of their own.
Your application therefore relies on more code than the code you wrote personally.

Some packages might be:

Recently published, with little history.
Downloaded very infrequently.
Missing repository information.
Configured with installation scripts that execute during installation.
No longer available in the npm registry.

These characteristics do not automatically mean a package is malicious. However, they can help identify dependencies that deserve further investigation.

PackageGuard uses a set of heuristics to assign risk scores to dependencies and summarizes their severity.

The important distinction is this:

PackageGuard is a dependency-risk triage tool, not a malware detector. It helps prioritize investigation; it does not prove that a package is safe or malicious.

Conceptual Architecture

What each component does?

Component 1 — CLI entry point

I built a command-line interface using TypeScript and Commander.
The user runs:
node dist/index.js scan

The dist directory contains the compiled JavaScript output.

Why Commander?
Commander helps define commands, arguments, options, and command-line help without requiring you to write all the argument parsing yourself.

Engineering decision: use an existing CLI library rather than spending the project building a custom command parser.

Commander handles the interface, but it does not perform the dependency scan or calculate the risk score. Those are application responsibilities.

Component 2 — Project and dependency discovery
PackageGuard needs to know which packages to evaluate.
Consider this hypothetical package.json:
{
"dependencies": {
"express": "^5.0.0",
"axios": "^1.0.0"
},
"devDependencies": {
"typescript": "^5.0.0"
}
}

These are the dependencies declared by the project.
But there's a complication: express and axios can have their own dependencies.

PackageGuard traverses the installed node_modules tree recursively, with a maximum traversal depth of five and a duplicate guard.
Three concepts matter here.

Recursion: a function can call itself to explore nested dependencies.
Depth limit: restricts how far traversal proceeds.
Duplicate guard: tracks packages already visited so repeated encounters don't cause redundant traversal.

Why do this?
Without a depth limit, a malformed or unusually deep directory structure could consume excessive resources. Without a duplicate guard, shared dependencies might be revisited repeatedly.
There is a trade-off: a depth limit of five bounds work but can miss dependencies deeper in the tree. A duplicate guard also needs to use an appropriate package identity; two versions of the same package are not necessarily interchangeable.

Important: package.json describes declared dependencies, while node_modules reflects the installed layout. They answer related but different questions. My implementation uses dependency information and recursively examines the installed tree; before claiming exact coverage of every declared, optional, peer, or platform-specific dependency, we should verify the traversal code.

Component 3 — External npm APIs
Once a package has been identified, PackageGuard gathers evidence from npm.
It uses two sources for different kinds of information:

npm Registry API
Retrieves package metadata, such as whether a package exists, publication information, repository information, and package configuration details.

npm Downloads API
Provides download statistics used as a popularity signal.

*Why use external APIs instead of looking only at local files?
*
A local dependency directory can tell you what is installed, but it cannot reliably tell you the package's current registry status, its wider popularity, or all the metadata used by your scoring rules.

Why two APIs rather than one?
Because package metadata and download statistics are different categories of evidence. Separating the sources makes their roles clearer and lets the analyzer reason about different signals.

This introduces an engineering trade-off: better evidence comes with network latency and external failure modes.

For example:

The registry may be unavailable.
A request might time out.
A response could be malformed.
Rate limits could affect scanning.
Package metadata could change between scans. We should inspect the actual HTTP-client and error-handling code before claiming that all of these cases are handled robustly. Using an API does not automatically mean you have implemented retries, caching, concurrency limits, or graceful degradation.

Component 4 — Risk analyzer

This is the decision-making core of PackageGuard.
Instead of displaying raw npm metadata and expecting the developer to interpret it, the analyzer converts evidence into a numerical score.

The known heuristic rules are:

Signal Score contribution
Package is very new: under 7 days old +30
Fewer than 100 downloads per week +20
Repository information missing +15
Installation scripts present +20
Package does not exist in the registry Directly assigned 100

The score is capped at 100. The thresholds are:
Score Severity
0–29 LOW
30–59 MEDIUM
60–79 HIGH
80–100 CRITICAL

Let's calculate a hypothetical example.

Suppose a package is three days old, has fewer than 100 weekly downloads, and has no repository information.
[
R = 30 + 20 + 15 = 65
]

Its score would be 65, placing it in the HIGH category.

There is another important case. A package that doesn't exist in the registry is assigned a score of 100 directly. That is different from adding the ordinary signal contributions together.

Why?
A package that cannot be found may be a typo, an unpublished package, a removed package, a private-registry dependency, or something else. It is a significant finding, but the score alone does not establish malicious intent.

The trade-off is that the rules are crude. Legitimate new packages can score highly, while malicious packages can have many downloads and complete metadata.

The exact aggregation, missing-data handling, and precedence of the individual rules should be confirmed against the source before we make stronger claims about them.

Component 5 — Reporting

The last stage converts the analyzer's findings into something a developer can act on.

Instead of forcing the user to examine multiple API responses for every package, PackageGuard summarizes the findings by risk and severity.
The value of the report is not simply that it contains a score. It makes a potentially large set of dependency metadata easier to prioritize.

A strong report should help answer:

Which packages deserve attention first?
What evidence triggered the warning?
What should the developer investigate next?

The first is supported by the scoring and severity levels. The second depends on how much explanatory detail the report exposes. The third is an area where a future version could offer remediation guidance.

PackageGuard started as an idea about npm dependency visibility. It became an opportunity to work through the full lifecycle of a small developer tool: defining the problem, dividing responsibilities, building modules, connecting to an external service, implementing explainable rules, testing, packaging, publishing, and validating the result.

The most valuable lesson was that shipping software requires more than making the happy path work.

You need to think about what the program knows, what it doesn't know, how its parts interact, how users invoke it, and how to communicate the limits of its output.

PackageGuard is an early experiment, not a complete supply-chain security solution. But it is now a real npm package that other developers can install and try.

Try it out:

npm: [https://www.npmjs.com/package/packageguard]

Source code: [https://github.com/ishika-thakur7802/packageguard]

I'm looking forward to improving the implementation, strengthening its tests, and learning from what the next iteration reveals.

Thanks for reading!

PawPal is your New Dog's AI Sidekick 🐶⭐

Ishika Thakur — Sun, 16 Aug 2026 22:13:40 +0000

What I Built

Bringing a new dog home is exciting... and also confusing.

Why are they crying?
Why are they hiding?
Why won't they eat?
Why are they biting my feet? 😭

I built PawPal, a playful AI companion for new dog owners that helps turn those confusing moments into simple, reassuring guidance.

I especially wanted PawPal to feel useful for people welcoming a rescued dog into their home, where a new environment can be overwhelming for both the dog and the person trying to understand them.

You describe what's happening, and PawPal explains what might be going on, suggests a few things you can try, and gives you a playful "What your dog really means" translation.

And then... you can actually hear your dog say it. 🐶🔊

PawPal isn't meant to diagnose a dog or replace a veterinarian. It's a friendly first step for a confused human trying to understand their new companion.

Demo

🐾 Try PawPal:
https://pawpalweb.netlify.app/

Try asking:

"My rescued puppy keeps hiding under the bed. What should I do?"

Then listen to "What your dog really means." 🐶

Code

The project is open source:
https://github.com/ishika-thakur7802/pawpal

How I Built It

PawPal is a small React/Vite application backed by Netlify serverless functions.

The basic flow is:

User → React UI → Netlify Function → Google Gemini → PawPal response

For the voice experience:

PawPal response → ElevenLabs → audio → user

I used Google Gemini to generate the personalized responses. The prompt gives PawPal a specific personality and structure so that responses stay concise, friendly, practical, and appropriate for someone who may be a first-time dog owner.

I then used ElevenLabs to turn the playful "What your dog really means" part into speech.

I kept the project intentionally small. Rather than building a huge pet-management platform, I focused on one interaction:

"I don't understand what my dog is doing. Help."

The rescued-dog prompts were also designed to require no additional backend complexity — they simply give new adopters useful starting questions.

Prize Categories

🌟 Best Use of Google AI

PawPal uses Google Gemini as the core reasoning layer.

Gemini takes the owner's description of what's happening and generates a personalized response with:

what might be happening
practical things the owner can try
when professional help may be appropriate
a playful interpretation from the dog's perspective

The AI isn't just decorating the interface — the main purpose of PawPal depends on it.

🌟 Best Use of ElevenLabs

ElevenLabs powers PawPal's voice experience.

After Gemini generates the dog's playful "translation," ElevenLabs turns it into audio so the user can hear what their dog is supposedly trying to say. 🐶

That was important to me because the interaction should feel fun rather than like filling out another AI form.

Why I Built It

I wanted to make something that could be genuinely useful during those first confusing days of having a new dog — especially when that dog has come from a rescue situation and both sides are still learning to trust each other.

Sometimes you don't need another complicated pet platform.

You just need someone to say:

"Okay. Your dog is probably trying to tell you something. Let's figure it out." 🐾

Built for the DEV Weekend Challenge: Dog Days Edition.

Building eXtab #1: The Problem

Ishika Thakur — Mon, 13 Jul 2026 07:23:18 +0000

how many tabs are currently open in your window?
how many do you remember the context for?

if you're a fellow techie too, i know you too have been through one of those days with an endless number of tabs open in the window and having no clue where the music is coming from?

Hi there, I'm Ishika and I faced the same problem. It actually became crazy when I started working in the Incident Response Team. There would be duplicate tabs of logs, dashboards, documentations and so much more.

I could have just closed the window- but ouch! it'd have definitely hurt. :(

the emotional attachment to my tabs led me to build eXtab-
a smart chrome extension that sits on your window and helps you understand your tabs better

why a chrome extension?
honestly:
A. not one more tab please
B. i'm genuinely intrigued by how powerful but how underrated web extensions are!!

so the current techstack is:

JavaScript (ES6)
Chrome Extensions Manifest V3
Chrome Tabs API
Chrome Storage API
HTML
CSS

Architecture

Current Features

Read All Open Tabs
Displays every currently open browser tab.

Reads tab title
Reads tab URL
Retrieves all open tabs using the Chrome Tabs API

Detect Duplicate Tabs
Identifies duplicate tabs based on their URLs.

Example:

YouTube
YouTube
YouTube

↓

Duplicate found (3)

Remove Duplicate Tabs
Automatically closes duplicate tabs while preserving one instance.

This helps reduce browser clutter without manually searching for duplicates.

Show Idle Tabs (4h+)
Tracks browser activity and lists tabs that haven't been accessed for more than 4 hours.

Displays:

Tab title
Idle duration
Number of idle tabs detected
Example:

Number of Idle Tabs: 9

YouTube — Idle for 20 hours
Pinterest — Idle for 20 hours
LeetCode — Idle for 22 hours

The user can then either navigate to the tab, close the tab or review the tab.