Coder Legion - Recent posts tagged npm

Who Can Change Your npm Release Tags?

Thu, 01 Oct 2026 11:37:54 +0000

Who Should Be Allowed to Change Your npm Release Tags?

Your CI/CD pipeline may already be able to publish an npm package.

But here’s the more important question:

Should every workflow that can publish also be allowed to change latest, next, or beta tags?

GitHub’s recent npm trusted publishing update makes this separation much clearer.

Workflows can now receive explicit permission to manage npm distribution tags using short-lived OIDC credentials instead of keeping long-lived automation tokens around.

Why this matters

Release tags can directly affect which version users install.

Changing:

latest
next
beta

may look like a small metadata change, but in practice it can influence production adoption, prerelease testing, and package distribution.

That means tag management deserves its own permission boundary.

What development teams should review

Before changing anything in production, I’d check these first:

Which workflow actually needs to manage release tags?
Does that workflow really need broader publishing permissions too?
Can the operation be handled through OIDC-based trusted publishing?
Have you tested tag updates before removing existing credentials?
Are old automation tokens still required anywhere else?

A good principle here is:

Give automation only the permissions it actually needs.

The tag-management permission is off by default, which is a sensible security choice.

And importantly, moving to short-lived credentials does not remove the need for:

release testing
permission reviews
CI/CD controls
rollback planning
software supply-chain security

Discussion

I think this is a good example of where least privilege becomes practical, not theoretical.

Publishing a package and deciding which release becomes latest are related actions—but they are not necessarily the same responsibility.

How are you handling this in your npm workflows today?

Do you keep publishing and tag management in one workflow, or would you separate them?

#NPM #GitHubActions #DevSecOps #CICD #OIDC #SoftwareEngineering #DevOps #SoftwareSupplyChain #PackageManagement #OpenSource #DeveloperTools #Automation #NodeJS #WaqasAhmad

@seosiri/developer-ui-kit — a zero-dependency React licensing guard for SaaS dashboards

Thu, 24 Sep 2026 03:38:24 +0000

TL;DR: @seosiri/developer-ui-kit (v1.0.1, MIT, 0 dependencies) is a framework-agnostic React component library with a built-in Flexible Licensing Guard for gating PRO/ENT features in SaaS dashboards. Works with Vite, Next.js, Electron, and Atlassian Forge out of the box.

Why this exists

Every SaaS dashboard eventually needs to answer: is this user allowed to see this feature? Usually that turns into a one-off component, duplicated across every internal tool a team ships. This package makes that component reusable and auditable instead of reinvented per project.

How it works

The UniversalSaaSWidget component takes a license token, checks its prefix (PRO_ or ENT_) either locally or against a backend gateway, and renders the corresponding tier — with a real-time telemetry state (verifying / verified / error) so the UI never sits in an ambiguous loading state.

npm install @seosiri/developer-ui-kit

import { UniversalSaaSWidget } from '@seosiri/developer-ui-kit';

<UniversalSaaSWidget
  productName="SEOSiri Analytics Panel"
  productVersion="1.0.1"
  accentColor="#0284c7"
  theme="dark"
  onProTask={() => alert('Executing secure enterprise pipeline task...')}
/>

What's actually notable here

0 dependencies — verifiable on the npm page itself, not a marketing claim.
Framework-agnostic by construction — no CSS provider, no context wrapper; it's pure React with encapsulated inline styles, which is why it compiles across Vite/Next.js/Electron/Forge without extra config.
MIT licensed, source on GitHub — open core, with the licensing guard controlling feature access, not code access.

Worth discussing

If you're doing something similar — gating features by license tier in a React dashboard — how are you currently handling it? Custom hook, context provider, or something like this baked into a component? Curious what other teams have converged on.

Full technical breakdown (with architecture diagram and a build-vs-buy comparison table): https://www.seosiri.com/2026/09/developer-ui-kit.html

agentsmyth

Thu, 17 Sep 2026 19:31:38 +0000

Picture the last thing an AI agent built for you. The diff landed. It probably worked. Now answer three questions without scrolling back: which requirement did line 40 satisfy, what did you decide against and why, and what evidence proved it worked.

If you cannot, you did not lose the code. You lost everything around it.

agentsmyth exists to keep everything around it.

It is a portable AI engineering lifecycle, shipped as an npm package. You run one command, say one sentence to your agent, and the agent installs a gated seven-phase workflow into your repository. From then on, every non-trivial change moves through the same loop:

Requirements captured
Plan written
Code built
Reviewed
Tested
Shipped,
and reflected on, each phase leaving a

"durable file on disk".

Those files are the point.
Chat memory is smoke. It looks solid, then it is gone.

An artifact is steel: cold, inspectable, and still there when a different agent picks up the work three weeks later.

It is not a framework, not a linter, not an agent. It is a contract that the agent you already use agrees to follow.

Drop it into any repo; your agent drives it and leaves durable artifacts behind, not chat smoke.

I Kept Rebuilding PDF Features in Vue 3, So I Built vue-pdf-export

Fri, 04 Sep 2026 00:10:12 +0000

Hey everyone 👋

I recently released vue-pdf-export, an open-source Vue 3 + TypeScript library for generating PDFs directly in the browser.

I built it after repeatedly needing the same PDF features across different Vue projects and wanting one reusable solution instead of rebuilding the same logic each time.

What it supports

Some of the main features include:

Canvas and selectable-text PDF rendering
Automatic and manual pagination
Preview, download, and browser print
Headers and footers
Watermarks and page targeting
Clickable PDF links
Password protection and permissions
PDF metadata and compression
Progress reporting and cancellation
Large-document rendering
Blob, ArrayBuffer, Base64, and PDF data URL outputs
data-pdf-ignore for excluding UI elements from exports
Export-only page and body styling
Nuxt 3 and Nuxt 4 SSR-safe package imports

The package also has compatibility coverage for npm, pnpm, Yarn, Yarn Plug'n'Play, and Bun.

Installation

npm install vue-pdf-export

Basic usage

<script setup lang="ts">
import { ref } from 'vue'
import { Html2Pdf } from 'vue3-pdf-export'
import 'vue3-pdf-export/style.css'

const pdf = ref<InstanceType<typeof Html2Pdf> | null>(null)

async function generate() {
  await pdf.value?.generatePdf()
}
</script>

<template>
  <button @click="generate">
    Generate PDF
  </button>

  <Html2Pdf
    ref="pdf"
    filename="example.pdf"
    :preview-modal="true"
  >
    <template #pdf-content>
      <main>
        <h1>Hello from Vue</h1>
        <p>This content will be exported to PDF.</p>
      </main>
    </template>
  </Html2Pdf>
</template>

Canvas or selectable text

Use Canvas rendering when HTML/CSS fidelity is the priority:

<Html2Pdf render-mode="canvas">

Or use selectable-text rendering when users need to select, search, and copy text from the generated PDF:

<Html2Pdf render-mode="text">

This makes the package useful for both highly visual layouts and text-heavy documents such as reports, invoices, statements, and documentation.

The idea is to let developers choose between maximum browser-style fidelity and real selectable PDF text depending on their use case.

Programmatic output

The generated PDF can also be used directly in your application:

const blob = await pdf.value?.generatePdf()
const buffer = await pdf.value?.generatePdfArrayBuffer()
const base64 = await pdf.value?.generatePdfBase64()

This is useful when you want to upload, store, preview, or pass the PDF to another API instead of immediately downloading it.

Nuxt support

The package is designed so importing it does not crash Nuxt SSR.

Actual PDF generation still happens in the browser, so a typical Nuxt integration can use ClientOnly or lazy client-side rendering when needed.

Pagination

The package supports both automatic and manual pagination.

For an explicit manual page break:

<div class="html2pdf__page-break"></div>

There are also options for keeping elements together and avoiding unwanted page breaks.

Large-document rendering

Large PDFs were one of the areas I wanted to improve significantly.

Canvas rendering can become expensive when a browser attempts to create one extremely tall canvas for an entire document.

vue3-pdf-export can now render paginated Canvas documents incrementally, page by page, instead of depending on one giant full-document capture.

In one benchmark fixture, the previous long-document capture surface was around:

99.96 million pixels

while incremental rendering kept the maximum capture surface around:

1.74 million pixels per page

That is approximately a 98.26% reduction in peak capture-surface geometry for that fixture.

This is specifically a rendering-surface measurement, not a claim that total browser memory always drops by the same percentage.

The current regression suite includes documents across:

10 / 25 / 40 / 50 / 60 / 75 / 100 pages

50-page and 100-page Canvas documents are part of the current verified test range.

100 pages is not a hard package limit. Practical limits still depend on the document, images, browser memory, rendering mode, security settings, and the device being used.

Cancellation

Long-running PDF generation can now be cancelled.

pdf.value?.cancelGeneration()

Cancellation is cooperative and works across the generation pipeline.

The library also tests recovery after cancellation, so a new PDF can be generated after an earlier operation was cancelled.

Some already-running synchronous browser operations cannot always be stopped immediately, but the pipeline checks for cancellation between major stages.

Page-aware progress

Progress reporting now includes more than a simple percentage.

The package can expose:

current progress
current page
total pages
current processing stage

Stages include:

pagination
images
preparing
rendering
watermark
header
footer
metadata
serializing
complete
error

This makes it possible to build UI such as:

Rendering page 18 of 50...

instead of showing an indefinite spinner.

Headers

Headers can contain:

plain text
trusted HTML
optional logos
custom backgrounds and text colors
configurable logo dimensions
selected-page targeting

A header can appear on:

all pages
the first page only
the last page only
every page except the first
explicit page numbers

Selective header targeting also uses page-aware spacing, so header space is reserved only where the header is actually rendered.

Footers

Footers support:

HTML mode
text mode
trusted HTML content
optional logos
configurable logo dimensions
background and text colors
page-number templates

For example:

Page {n} of {total}

Header and footer logos preserve their aspect ratio instead of being stretched into a fixed box.

Static HTML footers are now rendered once and reused across pages instead of being rasterized repeatedly.

In project benchmark fixtures:

HTML footer without logo
7.82s -> 1.43s

HTML footer with logo
11.81s -> 1.29s

Footer-heavy PDF size
~46.7 MB -> ~1.0 MB

These numbers are specific to the benchmark fixtures and should not be treated as universal performance guarantees.

Repeated image optimization

Selectable-text rendering now caches repeated images within a single generation.

If the same image is reused across many pages, the package can avoid repeatedly loading and encoding the same source.

The cache is scoped to one PDF generation and is cleared afterward.

This is especially useful for documents containing repeated logos, icons, product images, or other shared assets.

Resource cleanup

A lot of work also went into cleaning temporary resources earlier.

The generation pipeline now handles cleanup of things such as:

temporary cloned DOM nodes
temporary canvases
encoded image data
per-generation image caches
rendering state

Canvas backing stores are also released when possible after they are no longer needed.

Repeated-generation and isolation tests were added to help detect regressions in cleanup behavior.

Browser responsiveness

Large PDF generation is naturally expensive, especially in Canvas mode.

The pipeline now yields between selected expensive operations so the browser gets opportunities to process UI work while generation is running.

Combined with cancellation and page-aware progress, this makes long-running generation easier to integrate into real applications.

Watermarks

Watermarks can be:

text or image
foreground or background
single or repeated
rotated
positioned
configured with opacity
targeted to selected PDF pages

PDF security

You can optionally generate password-protected PDFs with:

user/open password
owner password
configurable permissions
password construction from multiple password parts

Supported permission controls include:

print
modify
copy
annot-forms

Metadata and compression

PDF metadata can include:

title
author
subject
keywords
creator

jsPDF stream compression can also be enabled when needed.

Clickable links

PDF link annotations are also supported, allowing links in generated documents to remain interactive instead of becoming plain visual text.

Safer filenames

Generated filenames are normalized before download.

This includes handling invalid filename characters, whitespace, reserved Windows names, trailing dots or spaces, and overly long filenames.

Unicode filenames are still preserved.

A note about encrypted raster PDFs

While profiling larger secured documents, I found that encrypted raster PDFs could retain significantly more browser memory than equivalent unencrypted PDFs.

I reproduced the behavior directly with jsPDF outside the main vue3-pdf-export rendering pipeline.

That means a substantial part of this behavior appears to come from the underlying PDF library rather than from the Vue component itself.

I opened an upstream jsPDF issue with the reproduction and benchmark details:

https://github.com/parallax/jsPDF/issues/4017

For large secured documents, selectable-text mode can sometimes be a useful alternative because text-based PDFs are generally much smaller than equivalent rasterized documents.

This is still workload-dependent, so applications generating large encrypted PDFs should test their own representative content.

Testing and performance work

The project now includes automated testing around:

unit behavior
Chromium
Firefox
WebKit
large documents
Canvas rendering
selectable-text rendering
cancellation and recovery
image-heavy documents
repeated images
footer optimization
browser cleanup
security behavior
memory measurements
repeated generation
stress testing

The current unit suite contains:

19 test files
106 tests

There are also dedicated benchmark and Playwright workflows for performance-heavy scenarios.

For heavy PDF tests, I intentionally run browser work sequentially where appropriate so multiple workers do not distort memory measurements.

Why I built a Vue layer instead of replacing the underlying libraries

The goal was never to pretend that html2pdf.js, html2canvas, or jsPDF do not exist.

Those libraries still provide important pieces of the Canvas rendering pipeline.

The goal of vue3-pdf-export is to provide a Vue-oriented layer around PDF generation so common production requirements do not need to be rebuilt for every application.

At the same time, developers can still pass advanced html2pdf.js and jsPDF options when the higher-level API is not enough.

The selectable-text renderer provides another option for cases where real PDF text matters more than exact Canvas-style browser rendering.

Current release

The current release is:

vue-pdf-export v1.0.0

The project has grown significantly since the original release, including:

Canvas and selectable-text rendering modes
incremental page-by-page Canvas generation
large-document regression coverage
cancellation and recovery
current-page / total-page progress
repeated-image caching
footer rendering optimization
earlier DOM and Canvas cleanup
browser responsiveness improvements
PDF security
metadata and compression
clickable links
trusted HTML headers and footers
logo support
watermarks
filename normalization
expanded unit, browser, stress, and performance testing

Try it

🧪 Live Playground
https://vue-pdf-export-playground.vercel.app/

📖 Documentation
https://vue-pdf-export-docs.vercel.app/

📦 npm
https://www.npmjs.com/package/vue-pdf-export

💬 Feature requests & feedback
https://vue3-pdf-export.canny.io/

I’d really appreciate feedback from Vue and Nuxt developers, especially around real-world PDF edge cases, API ergonomics, pagination, large documents, or features you would expect from a Vue PDF library.

If you are building a Vue application that needs client-side PDF generation, I would love to hear about the kinds of documents you are generating and the edge cases you run into.

The project is still evolving, and real-world feedback is one of the most useful inputs for deciding what to improve next. If you find a bug, performance cases, or have an idea for an API improvement, feel free to let me know.

SEOSiri IAIG: An open MCP API control plane to stop AI agents from breaking production infrastructur

Mon, 24 Aug 2026 14:17:52 +0000

Hey devs,

As agentic workflows expand from sandboxed chat into production systems and IoT hardware, prompt engineering alone isn't a sufficient safety barrier. If an agent hallucinates a payload or triggers a cascading loop, traditional error-handling often catches it too late.

We launched SEOSiri Industrial AI Gateway (IAIG), an MCP-compliant API gateway that acts as a deterministic boundary between agent decision-making and physical/API endpoints.

Quick Specs:

License: MIT (Open Source)
Distribution: Live on npm
Tools Included: 21 documented tools (iaig_firewall_inspect, iaig_budget_gate, iaig_queue_proposal_hmi, iaig_audit_ledger, etc.)
Tier: Free tier available

Check out the architecture overview and get API access here:
https://www.seosiri.com/2026/08/industrial-ai-api.html

Feedback and tool requests are welcome!

Understanding exec() in FSCSS — Two Completely Different Jobs

Sat, 22 Aug 2026 22:45:11 +0000

Understanding `exec()` in FSCSS

In FSCSS, exec() serves two completely different purposes depending on where you write it:

Inside your stylesheet: as a utility / debugging function
In JavaScript / HTML: to load and compile the styles

Let’s break both down clearly.

1. Inside Stylesheets: Debugging & Logging

When used inside an @event block or after processing an array, exec() lets you run small JavaScript helpers directly from your CSS.
Its main job here is printing debug information to the browser console so you can check if your logic is working.

Console Logging

You can pass flags like _log, _warn, _info, or _error:

@event scaleSize(e) {
  if e >= 8 {
    return| num(8*2)em exec(_log, "Scaling to 16em for optimal readability")
  }
}

Checking Array Data

You can also inspect the current values inside an FSCSS array:

@arr fruits[ apple, orange, banana ]

/* Prints: apple orange banana straight to your browser console */
exec(_log, "@arr.fruits")

This is extremely useful while building complex logic with @event, @arr, or calculated values.

2. In JavaScript & Imports: Compilation Engine

Outside the stylesheet, exec is the core engine that compiles and runs FSCSS source code.

CDN Initialization (HTML)

The compiler file loaded via CDN is named exec.min.js:

<script src="https://cdn.jsdelivr.net/npm/fscss@1.1.25/exec.min.js" defer></script>

<style>
  /* Tells the engine to execute the initialization for a module */
  @import(exec(_init circle-progress))
</style>

Programmatic JavaScript Usage

You can also import and control the compiler directly from JavaScript:

import { exec } from "https://cdn.jsdelivr.net/npm/fscss@1.1.25/e/xfscss.min.js";

new exec({
  type: "URL",
  content: "styles.fscss",
  onSuccess: "Styles loaded successfully!",
  onError: "Oops, style compilation failed!"
});

This gives you full control over loading, success messages, and error handling.

Quick Summary

Location	Purpose	Common Use Case
Inside `.fscss`	Debugging & console logging	Check `@event` logic or array values
In HTML / JavaScript	Compile and run FSCSS	Load styles or initialize modules

Two different jobs. Same name.
Once you know the context, exec() becomes much clearer.

Useful links

Docs → fscss.devtem.org
vscode extention FSCSS Support
npm → npmjs.com/package/fscss

Developer Weekly Briefing — August 21, 2026

Fri, 21 Aug 2026 12:36:02 +0000

A busy week across tooling, supply chain security, and governance. Two stories have immediate action items attached. Here's what mattered.

GitHub Copilot bets on model choice, not model loyalty

GitHub's latest Copilot update, covering the week of August 10, adds two new models — Kimi K3 across all plan tiers and MAI-Code-1.1-Flash with native image understanding — and enables per-turn model switching in VS Code 1.133. Developers can now move between Claude BYOK and built-in Copilot models mid-session without restarting or losing context.

The direction is clear: GitHub is building Copilot as a multi-model orchestration layer, not a tool that wins by having the best single model. Agent Plugins 1.0 is now GA and works the same way across VS Code, Copilot CLI, the Copilot app, and the SDK — meaning internal tooling built for one surface no longer has to be rebuilt for another. JetBrains adds Copilot Memory for cross-session context retention and Ollama support for local model access.

Copilot CLI got the most substantial updates: a /tasks command for subagent management, prompt queuing while agents are mid-task, headless autopilot combining --plan and --mode flags, and /rewind for undoing Copilot changes without touching git.

The governance gap worth flagging: Copilot doesn't record which model contributed to which line of code. Per-turn model switching makes that gap wider, not smaller. By the time something breaks in production, the decision about which model wrote the relevant code is invisible in the build record. That's an audit and incident-response problem waiting to happen for any team that needs to reconstruct what happened and why.

VS Code decouples AI agents from the editor window

Microsoft separated AI agent sessions from the VS Code editor itself in the latest release, meaning agent workloads can run independently of whatever the developer has open in the editor. For teams running parallel agent tasks or background automation, this is a meaningful architectural change — agents no longer compete with active editing sessions for the same window context.

Claude Code's temporary usage boost expires tonight

If you're a Claude Code user on the temporary expanded usage tier, the boost ends tonight. This is worth checking before you kick off anything long-running this evening. Anthropic hasn't announced what the new baseline looks like post-expiry, so it's worth knowing where you stand before the session caps reset.

npm v12 shuts down a popular malware trick — the threat isn't gone

npm v12 is now generally available, and the install script changes from July are in effect. The specific malware technique it blocks: postinstall scripts that run automatically on package installation, which have been a primary vector for supply chain attacks across the JavaScript ecosystem. That particular trick is now off by default.

But it's worth being clear about what v12 doesn't fix. Attackers will adapt. The next wave of npm-based attacks will use whatever path npm v12 left open. The value of the upgrade is closing a well-documented, heavily exploited vector — not ending the supply chain threat category.

LangChain's dcode isn't new — its governance play for sensitive code is

LangChain has been shipping dcode for a while. What's new is a governance layer that lets organizations enforce policies around what happens when AI agents interact with sensitive code — access controls, audit trails, and restrictions on what can be passed to external models. For teams that've held back on agentic coding tools specifically because of sensitive IP concerns, this addresses the gap more directly than most tools in the space.

GitHub sharpens CodeQL for Actions workflows and modern JavaScript

CodeQL now covers GitHub Actions workflow files and modern JavaScript patterns that the previous ruleset wasn't catching. If you run CodeQL as part of your CI/CD security scanning, the coverage improvements apply automatically. Worth a scan run after the update to see what surfaces.

Tessl is betting on standards to close the AI code review gap

AI agents write code faster than anyone can review it — that's the established problem. Tessl's argument is that the solution isn't better tooling, it's standards: a shared specification layer that defines what AI-generated code is expected to do, so review can be partially automated against a known target rather than always requiring a human to reconstruct intent from the output. An interesting architectural bet worth tracking.

One retiring developer nearly broke a retailer's core system. Hypercubic built AI to catch that kind of undocumented institutional knowledge before it walks out the door. Read more
Harness GM Rahul Sood: most "AI remediation" claims don't actually work. A candid breakdown of where vendor promises outrun what the tools can actually deliver — and what real remediation looks like in production. Read more
Crogl's Monzy Merza: the SOC agent that refuses to say it can replace you. An honest conversation about where AI agents belong in security operations and where they don't. Read more
Blumira's Hearth turns security investigations from hours into minutes. AI reasoning applied to the investigation workflow, not just the alert triage layer. Read more
Detectify's Rickard Carlsson: attackers don't have new tricks, they have a faster clock. A grounded take on why the threat landscape feels more urgent even when the techniques haven't fundamentally changed. Read more
AWS is betting $500M that students will learn cloud by building. The payoff is still unproven, but the investment signals where Amazon thinks developer education is heading. Read more
Windows Server still has gravity. Kubernetes hasn't escaped its pull. A look at why the migration away from Windows Server in enterprise environments keeps moving slower than the cloud-native narrative suggests. Read more

The through-line this week: the tooling is getting faster and more capable across the board — model switching, agent decoupling, automated code standards — and the governance layer is still catching up. The Copilot model attribution gap and the LangChain sensitive code controls are both responses to the same underlying tension: moving fast with AI tools is getting easier, and knowing exactly what happened and why is getting harder.

See you next Friday.

Developer Weekly Briefing is published every Friday on Coder Legion. Written by Tom Smith.

The evolution of Shai-Hulud-style worms

Fri, 14 Aug 2026 08:32:08 +0000

The software supply chain landscape changed forever in early-to-mid 2026. What began as a series of isolated credential-theft incidents quickly mutated into a highly coordinated, multi-registry, self-propagating worm campaign.

By abusing trusted relationships, hijacking CI workflows, poisoning build caches, and even embedding execution scripts inside compiled native binaries, the threat actors behind this campaign (tracked as TeamPCP) bypassed traditional static scanner defences.

As of the time of writing, this is a somewhat complete, chronological teardown of the three distinct waves of this campaign: Shai-Hulud, Hades, and Miasma.

Shai-Hulud, Mini Shai-Hulud and similar worms

The Shai-Hulud worm lineage first surfaced in late 2025 as a direct credential stealer targeting the npm ecosystem. However, on May 11th, 2026, a highly automated, modernised variant called Mini Shai-Hulud struck with vastly expanded scope. While it heavily impacted npm, compromising more than 170 packages across the TanStack, Mistral AI, UiPath, and OpenSearch ecosystems, the worm simultaneously breached the broader software supply chain, orchestrating coordinated attacks against PyPI, RubyGems, Docker Hub, and even malicious extensions within VS Code.

Unlike the earliest waves of Shai-Hulud that relied specifically on stolen static developer credentials, Mini Shai-Hulud (believed to have been created by a different group to TeamPCP), gained entry to these diverse environments via entirely new approaches, like pull request workflow misconfigurations in GitHub Actions (as seen in the TanStack compromise).

The basic workflow looked like this. An attacker submitted a pull request from a fork. This triggers a workflow that grants write access to the base repository's cache. The attacker proceeds to poison the cache with malicious payloads. Hours later, a legitimate maintainer merges a commit, triggering the standard release workflow. And this all concludes with the release run pulling the poisoned cache and executing the malicious payload invisibly.

Rather than exposing static tokens, the worm scraped live tokens directly from the GitHub Actions runner’s active memory (the Runner.Worker process via /proc/<pid>/mem). Depending on the target ecosystem, it then exchanged these temporary workflow credentials for registry-specific publish tokens, using OIDC token exchange endpoints for npm and PyPI, or harvesting raw API keys for RubyGems and container registries like Docker Hub.

This allowed the published packages, container images, and extensions to carry valid SLSA Build track provenance signatures. To defenders, the updates appeared completely legitimate and officially attested across all affected registries. It’s the equivalent of deepfakes for the software supply chain.

Perhaps the most malicious aspect of this multi-registry wave was its defence mechanism. Once inside a developer's local machine or build server (whether pulled via a Python pip install, a Ruby gem, an npm package, or a VS Code extension) the payload established a background daemon named gh-token-monitor. This daemon monitored whether its stolen tokens had been rotated or revoked, acting as a dead man’s switch. If a defender revoked the token, the daemon immediately triggered a local script that executed rm -rf ~/ and rm -rf ~/Documents, wiping the victim's entire home directory to eliminate forensic traces and punish the developer.

Miasma

Discovered on June 4th, 2026, Miasma represents the third evolution of the Shai-Hulud family of worm attacks, compromising hundreds of npm components (including packages within the @redhat-cloud-services and @asyncapi namespaces).

In this workflow, a simple npm install forces a node-gyp rebuild which executes a binding.gyp command that drops the Miasma payload. Again, the tactics and techniques of this Shai-Hulud worm have changed multiple times so far this year. Most security scanners and manual reviewers focus closely on scripts blocks in package.json (watching for preinstall or postinstall triggers).

Miasma bypassed this completely by abusing binding.gyp. The binding.gyp, for context, is a legitimate config file used to compile native C++ Node.js add-ons. When a package containing this file is installed, the npm client automatically spawns node-gyp rebuild. The attackers embedded direct command execution wrappers inside the binding.gyp target configs. The system executes the malicious payload during compilation, completely avoiding the need for suspicious package.json lifecycle scripts.

Miasma focused heavily on capturing cloud identities instead of static keys, implementing collectors specifically designed to steal active GCP and Azure SSO credentials. Furthermore, if the infected CI container had access to the host's Docker socket (/var/run/docker.sock), the malware would’ve performed a Docker escape. It identifies and terminates security monitoring containers (such as Step Security’s harden-runner), creating a privileged Alpine container to write passwordless sudo access to the host's /etc/sudoers.d, and altered local DNS resolution to block telemetry reporting domains.

Hades

Discovered on June 8th, 2026, straight after the Miasma variant, the campaign expanded to the Python ecosystem, targeting critical academic genomics and phenotype analysis packages on PyPI (ensmallen, embiggen, pyphetools).

In this attack, a simple Python Import loads a .so extension which executes embedded javascript. The embedded javascript code executes a final Bun payload which exfiltrates to a GitHub endpoint.

In a major evasion upgrade, the attackers did not modify any Python source files. Instead, they embedded the malicious JavaScript loader inside the compiled Rust/C++ binary extension (.abi3.so).

When a researcher imports the package via Python (import ensmallen), it triggers dlopen() on the trojanised .so file. The shared object discreetly initialises and runs an embedded JavaScript engine to execute the payload. This makes the new attack completely invisible to code-reviewers looking at Python source files.

The payload's primary file, _index.js, contains a massive block of comment text representing a fake LLM jailbreak prompt. The decoy simulated classified briefings, asking for technical steps on weaponising biological agents and designing nuclear devices. This was a deliberate attempt to pollute static analysers and AI-assisted tooling, causing them to choke, flag false positives on safety boundaries, or even worse, misclassify the file as a prompt-injection experiment rather than a credential-stealing worm.

Instead of a standard server, the Hades variant registered dozens of GitHub repositories using the compromise-controlled user account felixEvora. The repositories used underworld-themed naming conventions (like lethean-tartarus-61322 and abyssal-acheron-97481) and were described as Hades – The End for the Damned. The exfiltrated data was stored in an encrypted envelope format, signed with GPG keys.

keyv and cachable packages compromised

In August 2026, the open-sourced Mini Shai-Hulud codebase was weaponised in one of the most widespread multi-registry campaigns to date. The outbreak began with the compromise of npm maintainer Jared Wray's account. This was the primary developer behind popular, heavily downloaded packages like keyv and cachable.

From this single entry point, the worm exponentially expanded into over 444 packages across 2,000+ published releases, hit 100 packages in the ServiceTitan ecosystem alone, and aggressively turned every infected machine into an automated propagation node.

The execution chain relies on the preinstall hook inside the package.json (addressed in npm v.12) to trigger a setup.mjs dropper. To evade standard JavaScript static analysis tuned for Node.js patterns, the setup.mjs file detected the host architecture, downloaded a bundled Bun 1.3.13 runtime, and proceeded to execute a massive, heavily obfuscated payload named math_init.js.

Rather than stopping at passive credential dumping, this variant actively probed and harvested deeper infrastructure credentials: It actively queried AWS IMDSv2 and ECS endpoints, enumerated AWS SecretsManager paths, read mounted Kubernetes ServiceAccount tokens, and extracted HashiCorp Vault secrets across KV v1 & v2 mounts. It even hunted local crypto wallets like bitcoin wallet files. It was observed that exfiltration calls were routed to a dynamic domain endpoint. Crucially, if the server returned an execute payload in its JSON response, the worm immediately executed it using eval, giving the threat actors live remote code execution on infected dev machines and CI runners. Finally, if the primary C2 server failed, the worm fell back to using stolen GitHub tokens to automatically create public GitHub repos containing base64-encoded stolen data, tagging the repo descriptions with a distinctive campaign marker. This time Shai-Hulud: Here We Go Again.

To ensure propagation, the worm scraped npm creds or even exchanged GitHub Actions OIDC tokens to auto-publish patch updates of packages the maintainer controlled. It inserted @opensearch/setup as an optional dependency, allowing the payload to silently cascade into downstream installs without causing build failures. Furthermore, it even expanded on the infection vectors directly inside dev workflows by writing malicious GitHub Actions workflows disguised with the name "Run Copilot", as well as altering AI-related dev tooling via poisoned .claude and .vscode config files.

Shai-Hulud-style worms will continue to change shape

The open-sourcing or leaking of a complex piece of malware like the Shai-Hulud worm typically triggers a significant shift in the threat landscape. When a sophisticated framework (originally tightly controlled by an advanced group like TeamPCP) becomes publicly accessible, it lowers the barrier to entry for a much wider, more disorganised pool of actors. Independent operators, smaller cybercriminal syndicates, and even security researchers looking to understand its mechanics can dissect the original codebase. This democratisation of advanced tech means that features previously requiring high-level engineering, such as automated supply-chain propagation or complex credential harvesting, become plug-and-play modules for anyone with basic development skills.

Without a centralised command structure like TeamPCP directing its deployment, the evolution of Shai-Hulud has naturally fragmented into highly specialised or experimental variants (such as IronWorm). Newer threat actors are combining Shai-Hulud’s core self-propagating mechanisms with different payloads or evasion techniques tailored to their specific objectives. For instance, some variants strip away the heavier components to create lightweight stealth tools, while others swap out the exfiltration methods to target different developer ecosystems beyond npm or GitHub, such as PyPI and Cargo. This fragmentation complicates defense strategies, as defenders can no longer rely on a single set of behavioural signatures or specific infrastructure indicators associated with the original group.

Furthermore, this post-TeamPCP era accelerated the timeline of dual-use engineering, where threat actors repurpose and optimise techniques from Shai-Hulud in unexpected ways (as seen in the Suno breach). Independent devs often modify the codebase to patch flaws left by the original authors (such as fixing loud fallback routines or refining how the worm handles OIDC token exchanges). Because these new variants are built and deployed by completely unrelated clusters of users, the attribution of attacks becomes incredibly muddy. The signature architecture of Shai-Hulud is no longer a reliable indicator of who is attacking, but rather a reflection of a shared, open-source repository of commodity supply-chain threats. This is glaringly the case with alleged supply chain competitions organised by BreachForums.

Quick recap of what you’ve read

If the evolution of Shai-Hulud proves anything, it's that attackers are exceptionally creative and relying purely on reactive remediation is a losing strategy. When malware can pass SLSA attestations, bypass package.json inspection via native builds, and hide inside compiled binaries, you simply cannot predict every vector. It only takes one compromised token to trigger a massive downstream disaster. While rapid incident response remains essential, putting heavy effort into proactive preventions, such as universal package cooldown policies and strict pipeline boundaries is the only way to neutralise these threats before they execute. Stopping the attack at the gate will always be easier than cleaning up the damage after a worm gets through.

🚀 Built an MCP Developer Ecosystem at SEOSiri

Tue, 11 Aug 2026 13:12:11 +0000

I’ve been working on the SEOSiri MCP Suite—an evolving infrastructure layer for developers building with AI agents.

Current architecture:

⚙️ 16 MCP Servers
🧠 163 AI Tools
🌐 11 Edge Gateways
🗺️ Interactive MCP Topology
📦 Developer packages & integrations

The goal isn’t simply to create more AI tools.

It’s to build an ecosystem where AI agents can discover, connect with, and work through real tools and services.

I’d especially love feedback from developers working with MCP, AI agents, LLM applications, and developer infrastructure.

🔗 Explore the architecture:
SEOSiri Developer Portal- https://developers.seosiri.com/

Research → Build → Connect → Verify.

MCP #ModelContextProtocol #AIAgents #LLM #AIEngineering #DeveloperTools #AIInfrastructure #SoftwareArchitecture #SEOSiri

Giving an AI Agent a Benchmark Tool It Can Install and Actually Trust

Tue, 28 Jul 2026 18:15:44 +0000

Part 2 of 2: the npm-to-uv-to-PyPI bridge that closes the installation gap, and the adversarial re-verification discipline that makes the output worth acting on autonomously

Co-authored by Rudrendu Paul and Sourav Nandy.

Repo: github.com/RudrenduPaul/memtrust, an independent, reproducible benchmark harness for agent-memory backends. pip install memtrust-cli.

Quick summary: memtrust-cli is now on npm. npx memtrust-cli runs a Python benchmark tool automatically using uv, with no Python toolchain required. Below is the full bridge design, a concrete temporal-KG boundary bug the eval caught, and the verification discipline that makes the output worth acting on autonomously.

In Part 1 of this series, we found our own MemPalace adapter calling a fabricated API method. Every result it had ever reported for that backend was fiction. Closing that gap meant an adversarial, from-scratch re-verification of every adapter in the project. That story stands on its own, and this one picks up right after it to answer a related question: when an autonomous agent runs this tool, what does "trustworthy" actually mean?

Here's the real command surface memtrust ships today. This is the output an agent or a CI script parses.

Every flag shown here is real, pulled straight from memtrust run --help. This GIF shows the live output.

Defining "agent-native" requirements

"Agent-native" gets used loosely enough that it needs a strict definition. A tool that's actually agent-native has to satisfy two conditions at the same time:

Installable automatically. An agent or a CI job needs to go from "nothing installed" to "tool running" using a single programmatically constructed command, and it needs to run on whatever runtime the environment already has.
Machine-legible. Every response has to be structured data a program can parse and act on directly.

Most developer tools, including memtrust's earlier releases, miss both marks. Running pip install memtrust-cli assumes the system already has a specific Python version provisioned, a virtual environment configured, and a writable path for pip. A CI runner or an agent sandbox shipping only Node hits a dead end there. Early memtrust CLI output also targeted human readers only. We printed colored tables, progress bars, and summary lines.

The npm side of this project closes the installation gap. The rest of this article focuses on the legibility problem, which turned out to be the harder challenge of the two.

Live on both registries

You can install memtrust-cli via npx memtrust-cli right now. It's on the npm registry. Running npm view memtrust-cli version against the registry today returns 0.3.3, which matches the version on PyPI.

We shipped a complete, tested npm package at npm/memtrust-cli/ in the repo alongside six per-platform companion packages (@memtrust-cli/darwin-arm64, @memtrust-cli/darwin-x64, @memtrust-cli/linux-arm64, @memtrust-cli/linux-x64, @memtrust-cli/win32-arm64, @memtrust-cli/win32-x64). The publish process followed a strict dry-run discipline: npm pack --dry-run produced a correct tarball, then npm publish --dry-run walked through the whole publish flow with registry auth included, and only after that did the real npm publish run. Running a dry run before the real thing is the same verification habit we apply to eval claims. We just applied it to a release instead.

The live path on PyPI is pip install memtrust-cli, version 0.3.3, confirmed against PyPI's own API on 2026-07-21, the date of the npm publish. A mirror package named memtrust currently sits at the same version for anyone who reaches for that shorter name, kept in sync by a manual release step rather than an automated one. Every example below works today through either pip or npx.

Here's the full implementation of bin/memtrust.js. The entire design fits in well under a hundred lines:

// Pinned to this npm package's own version, not left floating: "uv tool run
// --from memtrust" with no version qualifier always fetches whatever is
// currently newest on PyPI. Pinning to this package's own version keeps the
// two registries in lockstep: bump this package.json's version when PyPI's
// memtrust ships a new release, and every subsequent npm install/npx run
// resolves to that exact pinned release, not whatever is newest at run time.
const PACKAGE_VERSION = require(path.join(__dirname, "..", "package.json")).version;
...
const result = spawnSync(
  uvPath,
  ["tool", "run", "--from", `memtrust==${PACKAGE_VERSION}`, "memtrust", ...process.argv.slice(2)],
  { stdio: "inherit" }
);

The script resolves a platform-specific uv binary from require.resolve(), hands off every argument unchanged, and delegates all memtrust logic to the binary, pinning only the PyPI release to its own package version. Reading the whole file top to bottom takes about a minute, which was the point: we wanted a small bridge you can audit at a glance, one that gives you both determinism and simplicity without hiding anything.

We spent a good amount of time deciding where to actually source the uv binary from. Each platform package's prepack script fetches the matching uv release archive directly from Astral's GitHub releases, along with the per-archive .sha256 checksum file uv publishes alongside it, and the script requires an exact match before it will proceed. The maintainer running the release does this verification once, at npm publish time. We chose that tradeoff on purpose: a maintainer verifying the checksum with full visibility into the supply chain gives a stronger guarantee than repeating the check on every install, and downstream npm install runs simply rely on that already-verified state. An offline or network-restricted install never has to reach out to Astral's servers at all, since the uv binary already sits in node_modules ready to run.

uv tool run --from memtrust==<pinned version> memtrust <args> does the heavy lifting after that. It provisions a Python interpreter if the system doesn't have one, installs that pinned memtrust release from PyPI into an isolated tool environment on first use, then caches and runs the tool. An agent or a CI job with Node available ends up with a fully working Python benchmark tool, no extra setup required.

Node's footprint is big enough to justify closing this gap on its own. Sonatype's 2026 State of the Software Supply Chain Report puts npm at 7.97 trillion package downloads across 2025, up 65.43% year over year, against 804.97 billion for PyPI in the same period (Sonatype, 2026). Take that as a rough proxy for what's likely sitting in CI images: Node-based tooling reaches a huge share of environments by default, which raises the odds that Node is already present even where a curated Python toolchain isn't. A Node wrapper bridges that gap directly.

The uv tool itself has real adoption behind it. Astral's repository sits at 87,595 GitHub stars as of 2026-07-17 (GitHub API, astral-sh/uv). pypistats.org reports 165.67 million downloads in the trailing month. The Python Developers Survey run by the PSF and JetBrains found uv usage went from 0% to 11% adoption in the single year it was introduced, reported in JetBrains' "The State of Python 2025." Stack Overflow's 2025 Developer Survey puts uv at 9.5% adoption against pip's 40.9% and npm's 56.8%. Building a bootstrap step on top of uv was an easy call given those numbers.

Generating structured JSON output

Every memtrust run invocation writes a full JSON report to disk by default, saving to ./memtrust-report-<date>.json unless you point it elsewhere with --output. The command produces that JSON report on top of its console summary, so you never have to remember a --json switch. The report's results block breaks down per-backend, per-eval outcomes using the same signal taxonomy the underlying evals use internally. The memtrust run --eval command currently exposes seventeen registered evals, from longmemeval through temporal_kg_boundary. A program reading the file gets the same verdict a person reading the console table would get.

Here's the actual payload an agent or CI job parses. We pulled this directly from a real memtrust run --backends mempalace,mem0,zep,openviking --eval all invocation against memtrust 0.3.3. The run used zero configured credentials, and we left the output completely unedited:

{
  "mempalace": {
    "status": "skipped",
    "reason": "mempalace is not configured: environment variable MEMPALACE_STORAGE_PATH is not set. Skipping this backend. See docs/methodology.md for setup instructions.",
    "missing_env_var": "MEMPALACE_STORAGE_PATH"
  },
  "mem0": {
    "status": "skipped",
    "reason": "mem0 is not configured: environment variable MEM0_API_KEY is not set. Skipping this backend. See docs/methodology.md for setup instructions.",
    "missing_env_var": "MEM0_API_KEY"
  }
}

The output is strict key-value pairs. The status and missing_env_var fields give programs machine-checkable data to act on right away, which leads to a design choice worth calling out.

We added a memtrust report <path> subcommand for reading a prior run's JSON back and printing a formatted summary. That's useful when the agent running the eval and the person or system reviewing it are two separate processes.

There's an easy way for a parser to get this wrong, though. A backend missing a configured credential environment variable keeps the run alive: it prints SKIPPED in that backend's section and continues on. A CLI running unattended in CI needs to behave this way, since a missing API key for one backend shouldn't stop the rest of the eval suite from finishing. But that means a program parsing the JSON has to check each backend's own status field. If it relies only on the command's exit code, it'll wrongly assume a skipped backend actually passed.

The CLI also includes a --sign flag backed by an Ed25519 keypair generated with memtrust keygen. This writes a signed receipt alongside the JSON report, and the signature proves which key produced the file and that the contents haven't been altered. We built this for agent-to-agent consumption: structured output only means something if the agent reading it can verify where it came from, and an unsigned JSON file is trivial to spoof. Signing stays optional for standard runs, but it's there for reports that need to cross a trust boundary.

Current approaches to agent tool distribution

Several existing practices try to close the agent-tool distribution gap. It's worth being precise about what each one actually solves, and where each one stops short.

Protocol-level standards for agent-tool-calling give a direct answer for tool invocation. The Model Context Protocol, introduced in November 2024 and donated in December 2025 to the newly formed Agentic AI Foundation, a directed fund under the Linux Foundation, reported over 97 million monthly SDK downloads and more than 10,000 active public servers at the time of that announcement. A protocol standard solves the invocation contract: it defines how a tool describes its own capabilities and how an agent calls them in a predictable shape. But the underlying tool still bears full responsibility for returning truthful values. Standardizing the envelope leaves the contents completely unverified.

Traditional package-manager install flows, including pip and npm's default behavior, need a human reading terminal output to make judgment calls. The user has to accept prompts, notice warnings, and interpret stack traces. A default pip install or npm install outputs unstructured text, because the people who designed these tools built them for a person watching the terminal, not a program parsing it.

Benchmark and leaderboard self-reporting in the broader ML ecosystem has a well-documented gaming problem. A 2025 analysis found that one major model provider privately tested 27 model variants against a popular crowdsourced arena benchmark before release. Proprietary models received access to 54.3% to 70.1% of the benchmark's evaluation data, while openly available models got far less. That additional arena data access alone produced score gains of up to 112% relative to a baseline (Singh, Nan, Wang, et al., "The Leaderboard Illusion," NeurIPS 2025). A separate survey documented the broader pattern of train/test contamination undermining leaderboard comparisons across the field. A self-reported number that relies entirely on trust is easy to optimize toward instead of actually earning.

Detection-capable claims in vulnerability and bug-finding tooling frequently get conflated with live-reproduced claims. The industry has started to recognize this distinction directly. Recent work building automated exploit-verification pipelines highlights the difference: identifying a plausible flaw is a categorically easier claim than producing a working reproduction against a real running system, and treating the two as equivalent overstates what the detection tool actually found (a 2025 paper on automated exploit generation and validation makes this argument in those terms).

There's a gap running through all four of these categories. Each one lets a tool output well-formatted or plausible data without proving it's true. A protocol standardizes the call. A package manager gets the bits onto disk. A leaderboard reports a number. A detection tool flags a candidate. What none of them do is the adversarial re-verification this project treats as mandatory. An agent-native benchmark tool has to add that on top of everything those categories already handle well: install cleanly, call predictably, report a number, flag a candidate, and then prove that number or flag actually holds up when an independent engineer checks the work.

Verifying the tool's internal claims

The distribution mechanics only matter if the underlying tool is trustworthy. An agent calling memtrust run autonomously parses the JSON and decides what to do next, with no visibility into any silent failures behind it. Part 1 laid out exactly what's at stake here: a fictional API call inside that adapter forced every downstream consumer to act on claims nobody had actually verified.

The discipline from that re-verification keeps running on repeat. Every time the project's backlog surfaces a missing capability, an engineer looks at the actual gap, builds the smallest piece of it that can genuinely be closed, and re-verifies the result independently before calling it done. We scope partial fixes to their real boundaries on purpose, to keep the backlog honest rather than padded. A recent knowledge-graph boundary bug is a good example of this loop in action, and the memtrust eval suite missed it entirely until a few days ago.

Fixing the temporal-KG boundary bug

The bug lives upstream, inside the vendor's own knowledge-graph store. Issue MemPalace/mempalace#1913 reported a race condition: querying a knowledge-graph fact with an as_of point-in-time filter at the exact instant that fact was invalidated returned both the old value and the new value at once. The code used a closed-interval SQL comparison (valid_to >= as_of) where it needed a half-open interval (valid_to > as_of). A fact ending exactly at the query instant still matched, and if its replacement started at that same instant, a single-valued predicate like uses_model reported two contradictory answers at once with no warning at all. The pattern that triggers this is invalidating a fact and adding its replacement at the same shared timestamp, and the vendor's own pre-fix onboarding guidance told every agent to use exactly that pattern. The maintainers fixed it in merged PR #1914, switching to the half-open interval and adding a new supersede() primitive as the preferred atomic replacement.

The memtrust backlog had flagged the capability to detect this class of bug months earlier. We'd bundled it together with a second, unrelated capability (drawer neighbor-expansion leak scoping) into one item, and that item sat open because it was too big for a single scoped fix. Forcing it through just to close the backlog line would have meant shipping something half-built, or quietly widening what counts as "done," and the project rules rule out both of those. The item stayed open until we could shrink it down to a manageable unit.

The scope-expanding investigation is where the real work happened. Splitting the bundled item meant reading the adapter code directly, and that reading turned up something useful: the wiring for kg_query(entity, as_of=..., direction="both") already existed post-rewrite and passed straight through to the confirmed tool_kg_query. The evals were simply passing a zero value for as_of. So the actual capability gap was building a classifier and a test to exercise the path that already worked, which was a much smaller job than the original bundled item made it look. You only find that kind of distinction by reading the actual code with the goal of shrinking the claim down to what's true. Re-estimating a vague item over and over just hides these details instead of surfacing them.

We built a new TemporalBoundarySignal enum (CLEAN, DOUBLE_COUNT, NOT_APPLICABLE) in adapters/base.py, and added a dedicated eval at evals/temporal_kg_boundary.py. This eval seeds a fact, invalidates it, and adds its replacement at the same boundary instant to match the shape of #1913. It queries the database at that instant and classifies the response two separate ways: first, it checks the adapter's own self-reported signal, and second, it computes an independent classification straight from the raw list of facts the query actually returned. That second check is what forces the eval to verify the raw data on its own rather than trusting the adapter's word for it. A disagreement between the two signals points to a bug in the adapter's own classification logic, which is a different failure from a backend double-count, and the eval catches both separately.

The test suite behind this holds to the same standard. It runs against two from-scratch fake implementations that faithfully reproduce the real pre-#1914 closed-interval comparison and the real post-#1914 half-open comparison, computing a real answer from real logic each time rather than leaning on hardcoded stubs.

Fifteen tests, all passing, against fakes that implement both the buggy closed-interval logic and the fixed half-open logic in full.

We'll lay out the limitations here as plainly as the eval's own docstring does. First, the real mempalace package is still absent from the build environment. PR #1914 is merged to the vendor's develop branch, but it's absent from the 3.5.0 release this adapter was built and live-verified against. That makes this a detection-capable harness: we proved it correct against faithful synthetic reproductions of both the buggy and fixed comparison logic, but it currently only runs against synthetic targets. The eval should flag #1913's failure shape the moment we point it at a pre-fix deployment, but we still need to actually run that live test before we call this done. Second, temporal_kg_boundary is now wired into the CLI's eval registry as the seventeenth entry memtrust run --eval can invoke by name. It reports not_applicable against any backend other than mempalace, since MemPalace is the only adapter implementing the knowledge-graph calls this eval needs.

Before this change merged, a second engineer independently re-ran the full suite and confirmed every test passed. ruff check, ruff format --check, and mypy --strict all ran clean against the actual merge commit. The suite has grown since then: we're at 590 tests passing and 8 skipped, at 93% overall coverage as of this writing. We applied the same discipline from Part 1's re-verification here, on a much smaller change, because the habit has to hold on boring changes just as much as it held on the dramatic one.

The drawer neighbor-expansion half of that original bundled backlog item remains open and untouched on purpose. Splitting the item let us close only the piece we could actually verify, and we left the other half exactly where it was.

Catching regressions in mem0 during a live run

The same habit produced a second example a few days later, from a real live benchmark run. The mem0_direct adapter uses self-hosted mem0ai running in-process against a local Qdrant instance and the OpenAI API. It ran contradiction detection, compression/round-trip fidelity, and extraction quality. Contradiction detection came back with 7 for 7 cases silently overwritten and 0% flagged: if you tell it your meeting moved from 2pm to 3pm, it stores the new fact and reports zero changes. Compression/round-trip fidelity landed at a 31.6% mean literal fidelity across 5 cases, which we expected, since mem0's design goal is semantic extraction, not literal fidelity. Extraction quality ran 15 cases, 12 deliberately junk inputs and 3 deliberately valid ones. The system correctly rejected all 12 junk inputs, but lost all 3 valid ones on retrieval. That's a small sample, and we're treating it as a signal worth investigating further rather than a conclusion.

Getting any of those numbers required fixing a bug first: the gpt-5-mini/gpt-5o-mini single-character mismatch described in Part 1, which mem0ai/mem0#6085 had already documented independently, 16 days earlier. That's the value of an automated npm install path in practice: a CI job that pulls this tool in on a schedule, with almost no setup effort, catches real regressions automatically.

Unifying distribution and verification

An agent that installs your CLI automatically but gets back false data hasn't actually solved anything. It still needs a human to check the result behind it, which means a benchmark tool with airtight verification discipline that only runs for a person with a curated Python environment never reaches the audience it's meant for. Agents and CI pipelines make decisions with no human supervision in the loop, so a tool built for autonomous execution has to hold its own claims to the same evidentiary bar it applies to the systems it's benchmarking.

We still have real limitations here. We've wired temporal_kg_boundary into the CLI, but we've only pointed it at the synthetic fakes described above, and we still need to test it against a live, pre-fix MemPalace deployment before it's more than a detection-capable claim. A Kuzu graph-database driver stays unbuilt on purpose, since the upstream project backing it formally deprecated that path and dropped default test coverage for it, and building against an abandoned dependency is a bad trade regardless of what it might buy us. "Detection-capable" and "field-tested against a live deployment of the exact bug" are two different claims, and security and eval tooling generally blur that line. We're calling it out directly so the softer claim has to stand on its own instead of borrowing credibility from the stronger one.

Installation and verification both have to work, together, for any of this to mean something. An agent that can install your tool in one command but can't trust what it prints back hasn't gained much over the tools that came before it.

Repo: github.com/RudrenduPaul/memtrust.

References

Sonatype. "2026 State of the Software Supply Chain." 2026.
GitHub API, astral-sh/uv repository metadata, fetched 2026-07-17.
pypistats.org: uv package download statistics. Fetched 2026-07-17.
JetBrains. "The State of Python 2025." August 2025, based on the Python Developers Survey (PSF + JetBrains).
Stack Overflow. 2025 Developer Survey, Technology section. 2025.
MemPalace. mempalace#1913, "kg query --as-of returns two values for a single-valued fact at a supersession boundary."
MemPalace. mempalace#1914, "fix: half-open as-of interval + supersede() to end KG boundary double-count." Merged.
Anthropic. "Donating the Model Context Protocol and Establishing the Agentic AI Foundation." December 2025.
Linux Foundation. "Linux Foundation Announces the Formation of the Agentic AI Foundation." December 2025.
Singh, Nan, Wang, et al. "The Leaderboard Illusion." NeurIPS 2025, arXiv:2504.20879.
"Benchmark Data Contamination of LLMs: A Survey." arXiv:2406.04244, June 2024.
"CVE-Genie: From CVE Entries to Verifiable Exploits." arXiv:2509.01835. 2025.

Co-authored by Rudrendu Paul and Sourav Nandy. Rudrendu is an engineer building agent-native open-source tooling, including memtrust and a companion suite of AI-agent infrastructure projects. Find the code at github.com/RudrenduPaul.

They Asked for My AI Rules. But I Could Not Just Hand Them Over.

Mon, 13 Jul 2026 18:56:49 +0000

A team lead announces that the team will start using AI-assisted development. Everyone nods. Nobody asks what that actually means on Monday morning.

Some times ago I was in that position. A project I was working on needed to start using AI-assisted development, and the team was new to it. Nobody had rules written down for an agent to follow. Nobody had skills defined for it to load. There was no shared idea of how this should work inside our specific repo. Someone had to go first. That someone was me.

The rules worked because I built them for one repo

I spent time curating a set of rules and skills for that project. Not generic ones. I shaped them tightly around how that repo was actually structured, its conventions, its layout, the things a new engineer usually has to learn by asking around. I wanted an agent working inside that codebase to already know what a human teammate would have picked up in the first two weeks.

I gave a demo. It landed well. Well enough that it got shared further across team, as something other teams could learn from.

I gave the demo again. Same reaction. Then a few developers reached out for the actual rules and skills files.

I said sure, and then I actually looked at what I would be handing them.

The problem showed up the moment other people wanted in

It was not copy-paste-able. The rules referenced folder names, module boundaries, and patterns specific to one repo. Handing them over as-is would have meant handing over advice that was wrong for their project, dressed up as a shortcut.

So I told them to use it as a reference. Look at the structure, understand the reasoning, adapt it to your own repo.

That is correct advice. I watched people nod at it and then quietly missing it.

I was solving the wrong problem the whole time

I had been thinking about this as a documentation problem. Write good rules, explain them well, let people copy the idea. What I actually had was a generation problem. The rules that worked were the ones rendered specifically for a stack, not the ones written generically and left for someone to translate.

The thing that was supposed to spread across other teams did not land as expected. What reached them was a reference nobody had time to turn into anything real. That gap sat there whether I looked at it or not.

What I wanted to build was not another generic harness. I wanted something that looked at a repo's actual stack and produced rules and skills that worked from day one, not rules that needed a translation step before they were useful.

Nobody on a team agrees on one AI tool

Once I sat with that problem, a second one showed up right behind it, and this one turned out to matter just as much.

Every adoption plan I had seen quietly assumed one AI tool per team. In practice, that assumption breaks almost immediately. One engineer wants Cursor. Another has already built muscle memory in Claude Code. Someone else is testing Windsurf, or is stuck on Copilot because that is what the company licensed, or wants to try Antigravity because something new just came out.

Nobody wants to be told which editor or which agent to use, and forcing a single choice on a team is its own kind of friction, separate from the rules problem entirely. An adoption effort that only works for one tool is not really team adoption. It is one person's adoption, dressed up as a rollout.

What the tool had to actually do

That is the shape the problem ended up taking. Not "write better rules." Generate rules and skills that are rendered for a specific stack, and make sure they work no matter which of the tools a given engineer has already chosen.

That is what became FARE and BARE, frontend and backend AI starter recipes, published as npm CLI tools. Point either one at a project and it generates rules, skills, and workflow context shaped around that project's actual stack, with adapters for five tools out of the box: Cursor, Claude Code, Windsurf, Copilot, and Antigravity. The output is meant to be used immediately, not adapted first.

The part worth being honest about is that this did not remove the original judgment call. Something still has to decide what "good rules for this stack" means because it's always well opinionated. The CLI just means that decision gets made once, by the tool, instead of once per engineer, per project, under deadline pressure, with wildly inconsistent results.

I did not build everything I wanted to

The scope I first sketched out was larger than what shipped. There were ideas around deeper project-specific customization, additional integrations, and more automated context tracking that I dropped or pushed to later releases. Some of that was a reasonable v1 boundary. Some of it was me wanting to build the interesting version instead of the useful one, and catching myself doing it.

Keeping it simple was not the easy default. It was a decision, and one I had to make more than once while writing it.

I do not know yet whether this is the right shape for other teams' problems or just the right shape for the one I kept running into. If you try FARE or BARE on your own project, I would genuinely like to know where it holds up and where it does not.

Awaiting your feedback!
Frontend Ai starter REcipes
Backend Ai starter REcipes

FNPM Just Became Invisible (In the Good Way): Transparent Alias, Better Tests & a Smoother Experience

Tue, 07 Jul 2026 17:12:02 +0000

There are moments when you stop, look at your terminal, and think:
“Why does something as simple as managing packages in JavaScript has to be… so dramatic?”

If you've been around the Node.js ecosystem for more than 5 minutes, you know exactly what I mean.

Well, FNPM just got its biggest update ever, and no, it’s not “just another technical improvement.” This update is about giving you the experience we all secretly wanted: using your favorite package manager while something way smarter runs behind the scenes.

Let me explain.

Before: npm, pnpm, yarn… drama.

Now: use whatever you want. FNPM does the hard work.

The biggest change (and my personal favorite) is the new transparent alias system.
This means you can now type:

pnpm install

…and behind the scenes, FNPM is actually doing the job.

Why is this so massive?

Because for the first time, an alternative package manager can sneak into (yeah, sounds weird but it’s beautiful) your workflow without asking you to change anything.

If your team uses pnpm, perfect.
If you prefer FNPM’s model and how it handles things, also perfect.
If your environment is mixed… well, guess what? It works too.

FNPM now behaves as a real drop-in replacement, like for real real.

How does this alias magic works?

FNPM now includes a smart hook system that intercepts the traditional package manager commands and transforms them into FNPM operations.

In short:

It detects what you want (install, add, update, run, etc.).
It maps it to FNPM’s internal engine.
It keeps the CLI experience you already know.

All without breaking scripts, without changing your mental model, and without asking you to learn new commands (because, honestly, nobody wants that anymore ).

Better test coverage (and now actually cross-platform)

Another big step forward is the improved test coverage, which now behaves consistently across systems:

Linux
macOS
Windows (yes, Windows got some love this time )

Error messages, symlink behavior, path formatting… all those cross-platform headaches?
FNPM now handles them.

This means FNPM isn’t just “usable” on Windows —
it’s reliable, predictable, and CI-friendly across all platforms.

️ Other cool improvements worth mentioning

New fnpm source command for shell integration
GitHub Workflows + issue templates for better contributing
Updated dependencies (thanks Dependabot )
Cleaner project structure with better dev tooling
A more complete test suite for future expansions

FNPM keeps growing with a focus on simplicity + power, not complexity.

A real example: turning `pnpm` into FNPM (without anyone noticing)

Here’s a real example of how easy this is.
I swear the first time you run it, you’ll feel that “oh wow” moment .

(base) ➜  awesome-project fnpm setup pnpm  
Selected package manager: pnpm  

 FNPM hooks created successfully!

Setup Instructions:  
Unix/Linux/macOS:  
  1. Source the setup script:  
     source .fnpm/setup.sh  
  2. Or add to your shell profile (~/.bashrc, ~/.zshrc):  
     echo 'eval "$(fnpm source)"' >> ~/.zshrc  

Usage:  
  • Now you can use pnpm directly:  
    pnpm add some-package  
    pnpm install  
    pnpm run my-script  
  • Commands will be automatically redirected to fnpm  

Note:  
  • Hooks only work in directories with .fnpm configuration  
  • Use full path to bypass: $(which pnpm) command

Reload your shell:

(base) ➜  awesome-project echo 'eval "$(fnpm source)"' >> ~/.zshrc

Now try any pnpm command:

(base) ➜  awesome-project pnpm --help

You’ll see something like:

 This pnpm command is intercepted by FNPM  
Available commands:  
  install, add, remove, run, list, update, cache, clean  

Use 'fnpm --help' for more information

Boom.
From that moment on, you keep using pnpm like always…
but FNPM is the one doing the heavy lifting behind the curtain.

No workflow changes.
No broken scripts.
No new habits.
Just smooth developer life.

✨ In short: FNPM is no longer “used”… it’s felt

With this transparent alias system, FNPM stops being a command you remember to type, and becomes:

fast
consistent
cross-platform
and completely invisible when you want it to be

If it was useful before, now it feels… kinda magical, honestly.

PS: we used AI to help us write this article — because great tools deserve great storytelling.

Documentation here

I Built a QR Label Designer That Connects Directly to Your Data Tables — Here's How It Works

Wed, 01 Jul 2026 21:00:59 +0000

Ever had to print 200 warehouse bin labels and realized there's no clean way to do it from a web app?

That's what pushed me to build qrlayout-core and qrlayout-ui — two open source npm packages for designing QR label templates and bulk-printing them from React. This post walks through the full workflow with real code.

The Problem

Printing QR labels from a web app usually means one of these:

Generating them one at a time manually
Hardcoding the label layout in your codebase
Exporting a CSV and using a desktop app

None of these scale. And none of them give non-technical users control over the label design.

The Solution: Two Packages, One Pipeline

qrlayout-ui — a drag-and-drop label designer your users can embed directly in your app
qrlayout-core — the headless rendering engine that turns saved templates + data into PNG, PDF, or ZPL

npm install qrlayout-core qrlayout-ui

The workflow looks like this:

Labels Tab   →  Design a template, save it with a title + entity type
Master Table →  Select that saved layout from a dropdown
Table Rows   →  Check the records you want
Export       →  PNG · PDF · ZPL (thermal printer)

The key idea: template and data stay separate. One layout generates labels for hundreds of records. And because each template is tagged to an entity (employee, machine, storage), the master table only shows layouts relevant to it.

Step 1: Define Entity Schemas

You tell the designer what fields each entity has. This powers the live preview — every {{field}} placeholder dropped on the canvas renders with real sample data instantly.

const SAMPLE_SCHEMAS = {
  storage: {
    label: "Storage Master",
    fields: [
      { name: "binCode",     label: "BIN Code" },
      { name: "storageType", label: "Storage Type" },
      { name: "aisle",       label: "Aisle" },
      { name: "rack",        label: "Rack Number" },
    ],
    sampleData: {
      binCode: "BIN-A1-R4", storageType: "Pallet Rack",
      aisle: "Aisle 01",    rack: "R-44"
    }
  },
  // employee and machine follow the same shape
};

Step 2: Mount the Designer in React

qrlayout-ui is framework-agnostic so you mount it with a ref + useEffect. Two things matter most — passing onSave to capture the layout JSON, and calling destroy() on unmount to prevent memory leaks.

useEffect(() => {
  if (!containerRef.current) return;

  designerRef.current = new QRLayoutDesigner({
    element: containerRef.current,
    entitySchemas: SAMPLE_SCHEMAS,
    initialLayout: editingLayout || { ...DEFAULT_NEW_LAYOUT, id: crypto.randomUUID() },
    onSave: (layout) => {
      storage.addLabel(layout);        // persist the layout JSON
      setLabels(storage.getLabels());
      setSubView('list');
    }
  });

  return () => {
    designerRef.current?.destroy();    // always clean up
    designerRef.current = null;
  };
}, [subView, editingLayout]);

When the user clicks Save inside the designer, onSave fires with the complete StickerLayout JSON — name, target entity, dimensions, and all elements. That single JSON object is what flows through the entire rest of the system.

Step 3: The Master Table — Select Rows, Pick Layout, Export

Each master table (Employees, Machines, Storage BINs) filters layouts by targetEntity so users only see relevant templates in the dropdown.

// Only load layouts relevant to this entity
const binLabels = storage.getLabels().filter(l => l.targetEntity === 'storage');

const getSelectedBins = () => bins.filter(b => selectedBinIds.includes(b.id));
const getActiveLayout = () => labels.find(l => l.id === selectedLayoutId);

const handleExportPDF = async () => {
  const layout = getActiveLayout();
  const selected = getSelectedBins();
  if (!layout) return;
  await exportToBatchPDF({
    layout,
    items: selected,
    printer: printer.current,
    baseFilename: 'batch-bin-labels'
  });
};

When rows are selected, the export toolbar appears with three options. Until then the page shows a step-by-step guide so users know what to do.

Step 4: Three Export Formats

// PNG — one file per item
printer.renderToDataURL(layout, item, { format: 'png' })

// PDF — all items in one document
import { exportToPDF } from 'qrlayout-core/pdf';
const pdf = await exportToPDF(layout, items);
pdf.save('labels.pdf');

// ZPL — for Zebra and other thermal printers
const zplCommands = printer.exportToZPL(layout, items);
// In production: send over TCP port 9100 directly to the printer

exportToPDF is a separate optional import to keep the core bundle light. ZPL output is an array of strings — one per label — which you can download as a .txt file or pipe straight to a Zebra printer over TCP.

Try It — Pre-Loaded Demo Data

The live demo seeds everything on first load:

3 layouts — Professional ID Badge, Equipment Asset Tag, Storage Location Label
3 employees — Arjun Mehta, Priya Sharma, Kiran Patel
3 machines — CNC Router X1, Industrial 3D Printer, Hydraulic Press
3 bins — BIN-A1-R1 (Pallet Rack), BIN-A1-R2 (Shelf), BIN-B2-R1 (Cold Storage)

Go to Storage → check all bins → click PDF. Done in 30 seconds.

This is a Frontend Demo — Here's the Production Path

Everything in the demo runs in the browser using localStorage. In a real project you'd swap each layer with a backend equivalent:

Demo	Production
`localStorage` (layouts)	DB table with a `layout_json` column
`localStorage` (bins/machines)	Your existing ERP or database
Client-side filter by `targetEntity`	`WHERE target_entity = 'storage'`
Browser PDF download	Node.js server-side render → stream to client
`.txt` ZPL download	TCP socket → Zebra printer (port 9100)

qrlayout-core has zero browser dependencies — exportToPDF and printer.exportToZPL work identically in Node.js. The full production flow:

React Frontend
  └── qrlayout-ui  →  user designs label → onSave fires layout JSON
  └── POST /api/layouts  →  save to DB

Node.js Backend
  └── GET /api/layouts?entity=storage  →  filtered layouts to frontend
  └── POST /api/labels/print
        ├── fetch layout from DB
        ├── fetch selected records from ERP / DB
        ├── exportToPDF(layout, items)  →  stream PDF to client
        └── printer.exportToZPL(layout, items)  →  TCP → Zebra printer

Links

Happy to answer questions about the implementation in the comments.

I Built a QR Label Designer That Connects Directly to Your Data Tables — Here's How It Works

Wed, 01 Jul 2026 17:06:32 +0000

Ever had to print 200 warehouse bin labels and realized there's no clean way to do it from a web app?

The Problem

Printing QR labels from a web app usually means one of these:

Generating them one at a time manually
Hardcoding the label layout in your codebase
Exporting a CSV and using a desktop app

None of these scale. And none of them give non-technical users control over the label design.

The Solution: Two Packages, One Pipeline

qrlayout-ui — a drag-and-drop label designer your users can embed directly in your app
qrlayout-core — the headless rendering engine that turns saved templates + data into PNG, PDF, or ZPL

npm install qrlayout-core qrlayout-ui

The workflow looks like this:

Labels Tab   →  Design a template, save it with a title + entity type
Master Table →  Select that saved layout from a dropdown
Table Rows   →  Check the records you want
Export       →  PNG · PDF · ZPL (thermal printer)

Step 1: Define Entity Schemas

You tell the designer what fields each entity has. This powers the live preview — every {{field}} placeholder dropped on the canvas renders with real sample data instantly.

const SAMPLE_SCHEMAS = {
  storage: {
    label: "Storage Master",
    fields: [
      { name: "binCode",     label: "BIN Code" },
      { name: "storageType", label: "Storage Type" },
      { name: "aisle",       label: "Aisle" },
      { name: "rack",        label: "Rack Number" },
    ],
    sampleData: {
      binCode: "BIN-A1-R4", storageType: "Pallet Rack",
      aisle: "Aisle 01",    rack: "R-44"
    }
  },
  // employee and machine follow the same shape
};

Step 2: Mount the Designer in React

useEffect(() => {
  if (!containerRef.current) return;

  designerRef.current = new QRLayoutDesigner({
    element: containerRef.current,
    entitySchemas: SAMPLE_SCHEMAS,
    initialLayout: editingLayout || { ...DEFAULT_NEW_LAYOUT, id: crypto.randomUUID() },
    onSave: (layout) => {
      storage.addLabel(layout);        // persist the layout JSON
      setLabels(storage.getLabels());
      setSubView('list');
    }
  });

  return () => {
    designerRef.current?.destroy();    // always clean up
    designerRef.current = null;
  };
}, [subView, editingLayout]);

Step 3: The Master Table — Select Rows, Pick Layout, Export

Each master table (Employees, Machines, Storage BINs) filters layouts by targetEntity so users only see relevant templates in the dropdown.

// Only load layouts relevant to this entity
const binLabels = storage.getLabels().filter(l => l.targetEntity === 'storage');

const getSelectedBins = () => bins.filter(b => selectedBinIds.includes(b.id));
const getActiveLayout = () => labels.find(l => l.id === selectedLayoutId);

const handleExportPDF = async () => {
  const layout = getActiveLayout();
  const selected = getSelectedBins();
  if (!layout) return;
  await exportToBatchPDF({
    layout,
    items: selected,
    printer: printer.current,
    baseFilename: 'batch-bin-labels'
  });
};

When rows are selected, the export toolbar appears with three options. Until then the page shows a step-by-step guide so users know what to do.

Step 4: Three Export Formats

// PNG — one file per item
printer.renderToDataURL(layout, item, { format: 'png' })

// PDF — all items in one document
import { exportToPDF } from 'qrlayout-core/pdf';
const pdf = await exportToPDF(layout, items);
pdf.save('labels.pdf');

// ZPL — for Zebra and other thermal printers
const zplCommands = printer.exportToZPL(layout, items);
// In production: send over TCP port 9100 directly to the printer

Try It — Pre-Loaded Demo Data

The live demo seeds everything on first load:

3 layouts — Professional ID Badge, Equipment Asset Tag, Storage Location Label
3 employees — Arjun Mehta, Priya Sharma, Kiran Patel
3 machines — CNC Router X1, Industrial 3D Printer, Hydraulic Press
3 bins — BIN-A1-R1 (Pallet Rack), BIN-A1-R2 (Shelf), BIN-B2-R1 (Cold Storage)

Go to Storage → check all bins → click PDF. Done in 30 seconds.

This is a Frontend Demo — Here's the Production Path

Everything in the demo runs in the browser using localStorage. In a real project you'd swap each layer with a backend equivalent:

Demo	Production
`localStorage` (layouts)	DB table with a `layout_json` column
`localStorage` (bins/machines)	Your existing ERP or database
Client-side filter by `targetEntity`	`WHERE target_entity = 'storage'`
Browser PDF download	Node.js server-side render → stream to client
`.txt` ZPL download	TCP socket → Zebra printer (port 9100)

qrlayout-core has zero browser dependencies — exportToPDF and printer.exportToZPL work identically in Node.js. The full production flow:

React Frontend
  └── qrlayout-ui  →  user designs label → onSave fires layout JSON
  └── POST /api/layouts  →  save to DB

Node.js Backend
  └── GET /api/layouts?entity=storage  →  filtered layouts to frontend
  └── POST /api/labels/print
        ├── fetch layout from DB
        ├── fetch selected records from ERP / DB
        ├── exportToPDF(layout, items)  →  stream PDF to client
        └── printer.exportToZPL(layout, items)  →  TCP → Zebra printer

Links

Happy to answer questions about the implementation in the comments.

I built a free IDE extension to catch malicious npm packages before they wreck your project

Thu, 18 Jun 2026 08:44:52 +0000

Supply-chain attacks via npm are up year-over-year — packages like event-stream,
the Lazarus group drops, and AI-hallucinated typosquats keep landing in real codebases.
I got tired of finding out after the fact, so I built NPM Safety Guard.

What it does

It scans your package.json and lockfiles right inside your editor — no separate CLI step.

Here's what it currently catches across 22 detection layers:

Known malicious packages — DPRK RAT drops, Lazarus-linked packages, event-stream clones
CVEs — via OSV.dev, cached locally (free, no API key needed)
Typosquatting & homoglyph attacks — catches lodahs, reàct, and AI-hallucinated package names
Install script hooks — flags preinstall/postinstall before you run them
Deep tarball AST scan — detects obfuscation, eval, and payload patterns in the actual source
Dependency confusion — scoped packages planted on public npm to hijack private installs
Exposed secrets — API keys, tokens, private keys accidentally left in .env, .npmrc, .pem
MCP server config scanner — catches typosquatted or malicious MCP transport configs
Supply chain graph — interactive force-directed graph with risk overlay from your lockfile
OSSF Scorecard + Socket.dev score — security hygiene at a glance

Where to get it

VS Code / Cursor / Windsurf → VS Code Marketplace
VS Codium / open-source IDEs → Open VSX Registry
WebStorm / IntelliJ IDEA / all JetBrains IDEs → JetBrains Marketplace

All free. No account required for the core layers. MIT licensed on the VS Code side.

Under the hood

The VS Code extension is TypeScript. The JetBrains plugin is Kotlin. They share the same
detection signatures bundled at build time — no cloud dependency for the core scan.

CVE lookups hit OSV.dev with a 24-hour local cache so you're not waiting on a network
call every keystroke.

Have you been burned by a supply-chain attack before? Or do you have a detection layer
you wish existed? Drop it in the comments — I'm actively adding new signatures.

Developer Weekly Briefing — June 13, 2026

Fri, 12 Jun 2026 12:07:35 +0000

Security dominated this week. A worm hit GitHub's own repos, npm is closing attack vectors that have been open for years, and the developer environment itself is now officially part of the attack surface. But there was plenty of forward-looking news too. Here's what mattered.

The Miasma worm hit 73 Microsoft repos — and your IDE was the entry point

On June 5, GitHub disabled 73 Microsoft-owned repositories after the Miasma worm used a compromised contributor account to plant a credential-harvesting payload. The infected repos spanned Azure, Azure-Samples, Microsoft, and MicrosoftDocs — including well-used projects like azure-search-openai-demo and the Durable Task libraries. GitHub's automated systems contained it in 105 seconds. But the detail that should get your attention: the payload triggered when a developer opened the repo in an IDE or AI coding tool — Claude Code, Gemini CLI, Cursor, or VS Code. Just opening a trusted repo was enough.

npm v12 ships in July — install scripts stop running by default

This is the one with a hard deadline. Starting in July, npm v12 will no longer auto-execute install scripts, resolve Git dependencies, or pull from remote URLs. All of it becomes opt-in. It's a direct response to the wave of supply chain attacks that hit the JavaScript ecosystem over the past year — including the hijacking of 18 popular packages with 2.6 billion combined weekly downloads. The average npm project pulls in 79 transitive dependencies. Any one of them could carry a malicious script. After July, those scripts won't run unless you say so. Run npm approve-scripts --allow-scripts-pending now to find out what's in your dependency chain before the upgrade forces your hand.

VS Code 1.123 adds 1M token context windows, session sync, and a research agent

The headline feature is support for 1-million-token context windows with compatible models, including Claude Opus 4.7 and GPT-5.5 — useful for complex projects where losing context mid-session is a real workflow problem. But the more interesting addition might be session sync: an automatic backup of chat sessions to GitHub that captures conversation history, files touched, and repo context. The companion Chronicle feature lets you query that history in natural language, generate standup reports, and search past work by topic or file. The parallel agents view and a new research agent (preview) round out an update that continues Microsoft's push to make VS Code the center of agentic development.

AI coding tools are making engineers faster — but the review bottleneck is real

Todd Fisher, CEO of CTM, makes a point worth sitting with: if your team becomes 10x more productive with AI, so does your competitor's. The baseline is shifting for everyone. His candid observation about where it actually breaks down: code generation is fast now, but reviewing AI-generated output is still slow, and that's the new bottleneck. Features are nearly complete but stalled due to insufficient time to review everything individually. Speed without oversight isn't a win.

Agentic AI in production: $3.3M in savings and the failure patterns nobody talks about

From Info-Tech LIVE 2026 in Las Vegas — the organizations seeing real results from agentic AI aren't the ones with the most budget or the flashiest tools. They're the ones who got serious about governance and failure patterns early. The $3.3M savings figure is real, but the more useful part of this piece is the failure taxonomy: what actually goes wrong when agents hit production and how to avoid it.

From pilot to production: the agentic AI governance playbook

Most agentic AI pilots succeed. Most production deployments don't — at least not on the first try. The gap isn't a technology problem; the agents work. The problem is that organizations treat the move to production as a scaling exercise when it's actually a governance exercise. This piece lays out the playbook for getting agents out of the lab and into the real world without breaking things.

The developer survival guide for the age of agentification

Agents are taking on more of the work that developers used to do. This isn't a theoretical future — it's already happening. Here's a practical look at what skills still matter, what's changing, and how to position yourself for what comes next.

Also from Coder Legion this week

The through-line this week: the developer environment is now a target, not just the code. Miasma and the npm changes aren't separate stories — they're the same story.

See you next Friday.

Developer Weekly Briefing is published every Friday on Coder Legion. Written by Tom Smith.

Lazy SRE's guide to secure systems, part 1: the dependencies you didn't read

Sun, 07 Jun 2026 21:55:28 +0000

Originally published at harshit.cloud on 2026-04-05.

A few months ago a friend's CI pipeline tried to install a package none of us had heard of. The build failed. The error wasn't a missing dep. The error was a local proxy saying this is malware, I'm not letting it touch disk. The package was a transitive dependency, six levels deep, that had been published to npm 38 minutes earlier. Nobody on the team had asked for it.

I do platform work at a startup. The job is: keep production up, keep the bill down, keep the kind of person who reads HN comments from getting a free shell on the cluster. The thesis for the series is short. The best security work for a small team is the work Future You at 3am will actually execute. The lazy answer is also, almost always, the right one: the configuration that makes the wrong thing impossible, rather than only discouraged. This is part 1. Part 2 is GitHub (tj-actions, OIDC, fork PRs). Part 3 is the unsexy list (IAP, Tailscale, PrivateLink, Okta, default helm creds, the PAT you forgot).

the picture

You opened your editor, ran npm install, and onboarded somewhere between 800 and 2,000 packages maintained by people you have never audited. Your team reviewed five direct dependencies. The other 1,995 came in for the ride.

The job is not to read all 1,995. The job is to make sure that when one of them is the problem, the blast radius is small and the alarm goes off.

chainjacking

Chainjacking is the umbrella term for "someone got control of a package you depend on and pushed a bad version." The attacker doesn't break npm. They get the credentials of the human who publishes the package, ship a patch version, and semver puts it on your machine the next time anyone runs npm install. event-stream (2018), ua-parser-js / coa / rc (2021), lottie-player (2024), and the shai-hulud worm (Sept 2025, with a 2.0 wave in Nov 2025) that self-replicated by stealing tokens from compromised maintainer machines via TruffleHog-style secret scans and then republishing every other package that maintainer owned. The economics still work for the attacker. It is going to keep happening.

Fig. 2 — twenty-four hours from maintainer phish to credential resale. Nobody noticed the version bump.

What matters in that timeline is that the human steps are slow and the automated steps are fast. The window between "malicious version published" and "your CI runs npm install" is whatever your dependabot cron is. If you auto-merge minor and patch bumps, that window is ninety seconds.

dependency confusion

You have a private package called internal-utils. Your CI is configured with both your private registry and the public npm registry. Somebody publishes internal-utils to public npm at a higher version. CI installs the public one. Birsan did this against Apple, Microsoft, Tesla, and PayPal in a weekend in 2021 for bug bounties.

Fix, in .npmrc:

@yourorg:registry=https://npm.yourorg.internal
registry=https://registry.npmjs.org/

Scope everything internal. Register your scope on public npm as a parked placeholder. It costs nothing.

postinstall

Most install-time npm supply-chain incidents I have read the postmortem on shipped their malicious code in a postinstall script — not in runtime code. (Some recent ones, like the chalk/debug compromise of Sept 2025, activate at runtime in the browser or on first import; the switch below doesn't help against those. It does help against the install-time class, which is still the majority.) The install hook runs before your tests, before your linter, as part of the install. Default is enabled. The one-line change with the highest blast-radius reduction:

# .npmrc
ignore-scripts=true

You'll need to allowlist two to five packages that genuinely need it (typically bcrypt-shaped things). That number is small. The alternative is letting every package run code on install. Pick.

the install that buys the most

Aikido's safe-chain is an open-source local proxy that sits in front of npm, npx, yarn, pnpm, pnpx, bun, pip, uv, poetry, pipx. Every package download is intercepted and checked against Aikido Intel, an open malware feed. Malware is blocked before bytes hit disk. Which is before postinstall runs. Free. No account.

Fig. 3 — safe-chain in one picture. A local proxy in front of every package manager, checked against an open threat-intel feed.

On a dev machine:

curl -fsSL https://github.com/AikidoSec/safe-chain/releases/latest/download/install-safe-chain.sh | sh
# restart your shell
npm safe-chain-verify
# expected: OK: Safe-chain works!

In CI:

- name: Install safe-chain
  run: |
    curl -fsSL https://github.com/AikidoSec/safe-chain/releases/latest/download/install-safe-chain.sh \
      | sh -s -- --install-dir /usr/local/.safe-chain
    echo "$HOME/.safe-chain/bin" >> "$GITHUB_PATH"
- run: npm ci

And, the part that quietly does the most work — refuse to install anything younger than 48 hours, because that's the window in which most npm malware is caught and removed:

export SAFE_CHAIN_MINIMUM_PACKAGE_AGE_HOURS=48

the receipts

The above stack is approximately one afternoon of work: npm ci from a committed lockfile, ignore-scripts=true with a tiny allowlist, scoped private packages with locked registry resolution, safe-chain in front of every install, minimum package age of 48 hours. It will catch most known-bad packages, kill dependency-confusion at the registry level, and reduce postinstall blast radius to zero for the long tail. It will not catch a maintainer-account compromise that ships clean-looking malware that only activates in production weeks later. Nothing in this post will. The next-tier defenses (sigstore signing, npm provenance, reproducible builds) are real, and Part 3 will name them.

For a startup the delta from this post is moving from "one of the next ten incidents has a non-trivial chance of being yours" to "you would have to be very unlucky." That's the only delta that matters.

If you do one thing this week, go register your npm scope.

diagrams: what i tried

Three diagrams, three different tools, one brief: "explain a supply-chain attack to a tired SRE in one image." Prompts kept short. Results below.

1 — the napkin contrast (coleam00 excalidraw-diagram skill)

Brief: "two-panel hand-drawn napkin. Left panel 'what i installed': five direct deps off a 'your app' box. Right panel 'what npm install pulled in': same five direct deps, transitive sprawl under each, one of them is a red evil-helper@1.2.3, callout reads 'shipping crypto miners.'"

Result: Fig. 1. Built with the excalidraw-diagram skill, a Claude Code skill that enforces a design methodology (depth assessment → pattern mapping → evidence artifacts → mandatory render-and-validate loop) and ships a Playwright-based renderer. The .excalidraw source is downloadable; open it on excalidraw.com to edit.

Two things the skill produced that I wouldn't have prompted for: a semantic color palette (Start/Trigger orange for "your app", Error red for the malicious package, Inactive blue-dashed for the "+N more" bags), and a summary-flow strip at the bottom (5 direct → 1,200 transitive → 1 malicious → full keychain) that compresses the post's thesis into nine words. The methodology turns a drawing into an argument.

One install gotcha worth knowing: the skill loads Excalidraw via ESM and the default CDN (esm.sh) was unreachable from my environment. One-line patch in render_template.html to use cdn.jsdelivr.net and it worked.

Verdict: won for the hero. The Excalidraw aesthetic earns a place when a post needs a punchline; the skill's methodology adds the second zoom level that elevates a punchline into something that teaches.

2 — the chainjacking timeline (diagram-design, polished editorial)

Brief: "Horizontal six-stage timeline. Dark navy #11141c ground, coral #ff6b5a for the two 'compromise' stages, muted cyan #5bc0d9 for the four 'victim' stages. Each stage: small timestamp label (T-7d, T-0, T+12m, T+12m02s, T+1h, T+24h), a node on the line, a short title, one-line caption. Title 'a chainjacking attack, in six steps' (lowercase). Italic figcaption. Magazine-infographic feel, no neon, no scanlines."

Result: Fig. 2. Built by a diagram-design subagent. Came back with a ghosted "COMPROMISE / VICTIM" phase label in the background that I hadn't asked for and now wouldn't part with.

Verdict: won for explaining attacker workflow. Editorial polish without being a dashboard. The agent's improvisation (the phase label) was the part I would not have prompted my way to.

3 — the safe-chain flow (diagram-design, five-column system diagram)

Brief: "Five columns left to right: developer terminal running npm install lodash-utils, shell alias intercepting, local proxy as the focal column, Aikido Intel cloud with a lookup arrow, outcome column with a green 'installed' branch and a red 'install aborted' branch. Dark editorial background #0d1117. Cyan normal flow, red blocked, green allowed. Legend strip at the bottom."

Result: Fig. 3. Same skill as #2. Came back with harshit.cloud · lazy security baked into the footer (also unprompted, also welcome) and a clean two-outcome fork that makes the block/allow decision the visual sink.

Verdict: won for explaining a system. When the diagram has to show what a tool does, this format beats the napkin every time. The napkin is a punchline. This one is a reference.

I did not ship an animated .gif for Part 1. The infographic-gif skill is the right tool for quantitative motion — a funnel decaying, a bar chart counting up. Nothing in Part 1 needed motion to make the point. If Part 3 ends up wanting a "blast radius over 24 hours" visualisation, that's where the GIF goes.

Outside Click

Sun, 31 May 2026 09:47:45 +0000

The Story Behind `use-outside-click`

It started with frustration. Every dropdown, modal, and popover needed the same thing — detect a click outside an element. The existing options were either 6kb class-based relics or unmaintained HOCs. So one late night, Kitsune Labs shipped a fix.

useOutsideClick(ref, () => setOpen(false));

That's the whole API. Hook-first, TypeScript-native, SSR-safe, ~300 bytes gzipped, zero dependencies. Multiple refs, touch + mouse, capture phase, and auto cleanup — all built in.

What's Next

This is just the beginning. We're building a whole family of tiny, focused web-dev utilities under Kitsune Labs — lean tools with clean DX and no bloat.

Contributing

We'd love your help. Open an issue, file a PR, or just share ideas.

git clone https://github.com/kitsunechaos-labs/use-outside-click.git
cd use-outside-click && npm install && npm test

Let's build a kind, quality-first community together. ⭐ Star the repo if it saved you time!

LibKill v0.1.5

Tue, 26 May 2026 07:27:27 +0000

The past 60 days have been brutal for supply chain security:

• 639 malicious versions across 323 packages in ONE hour (AntV wave)
• A worm with valid SLSA Build Level 3 provenance (TanStack)
• North Korean APTs injecting malware into "AI-assisted coding" workflows
• Credential stealers hiding in node-ipc, axios, lightning, and hundreds more
I built LibKill to answer one question: "Is my system clean?"
It scans your npm/pip packages against 2,800+ known compromised artifacts and tells you exactly what to remove. No SaaS, no API keys, no cloud. Just a single binary.

What's new in v0.1.5:

✅ Live threat feeds from 6 sources — Socket.dev, OSV.dev, GitHub Advisory DB, Cisco Talos, Unit 42, BleepingComputer
✅ uv support — detects Python packages installed via uv pip and uv tool
✅ Venv scanning — walks your project directories for virtual environments
✅ Windows Scripts/ path support
✅ 165 new malicious packages added — TrapDoor, Axios/Lazarus, CanisterSprawl, Contagious Interview, Solana typosquats
✅ 19 malware families tracked — PamDOORa, Quasar Linux RAT, CloudZ RAT, Nitrogen, and more
✅ GitHub token integration for live GHSA updates (optional, works without it)
One command to install:

`bash`

curl -fsSL https://lnkd.in/dTv3ukhe | bash

Open source. MIT license. Cross-platform.

https://github.com/firfircelik/libkill

Setting GitHub as a trusted publisher for npm

Tue, 26 May 2026 06:29:10 +0000

So, stuff happened and npm has been updated to reduce the volume of stuff happening. In a world of SBOMs, SLSA, and supply chain attacks, it's time to get serious about publishing packages. In this case, that means using the new Trusted Publisher feature to connect GitHub (or GitLab) to npm.

Set the trusted publisher on npm

Sign into npm
Select the package you want to set up, for example astro-accelerator-utils
Click Settings
In the Trusted Publishers section, select your provider, in my case it's GitHub
Enter you repository information:
- Organization or user name, for example Steve-Fenton
- Repository name, for example astro-accelerator-utils
- The result should be that Steve-Fenton/astro-accelerator-utils matches your repo in GitHub
Provide the workflow file name
- This should match the workflow that will publish the package, in my case build-astro.yml
- The file must be in .github/workflows/
Click Set up connection

If you use environments, you can optionally limit publishing by environment.

Check you GitHub Action

In your permissions section, you need to allow id-token to be written.

permissions:
    id-token: write

You can then use the npm publish step in your workflow.

I conditionally publish based on the version number, so I only publish when the version number changes.

- name: Publish if version has been updated
    env:
        NPM_AUTH_TOKEN: ${{ secrets.NPM_AUTH_TOKEN }}
    run: |
        PACKAGE_NAME=$(node -p "require('./package.json').name")
        LOCAL_VERSION=$(node -p "require('./package.json').version")
        REMOTE_VERSION=$(npm view $PACKAGE_NAME version || echo "0.0.0")

        if [ "$LOCAL_VERSION" != "$REMOTE_VERSION" ] && [ "$(printf '%s\n%s' "$REMOTE_VERSION" "$LOCAL_VERSION" | sort -V | tail -n1)" = "$LOCAL_VERSION" ]; then
        echo "Local version $LOCAL_VERSION is higher than remote version $REMOTE_VERSION. Publishing..."
        echo "//registry.npmjs.org/:_authToken=$NPM_AUTH_TOKEN" > ~/.npmrc
        npm publish --access public
        else
        echo "Version $LOCAL_VERSION is not newer than $REMOTE_VERSION. Skipping publish."
        fi

This is a more secure way to publish npm packages, but it's also easier because you don't need to keep updating tokens and secrets.

3 actionable security upgrades to fix npm’s trust problem

Tue, 19 May 2026 15:42:10 +0000

Liran Tal of Snyk published a really useful Github repo called “Awesome npm security best practices”. In this repo, Liran discusses structural constraints within the CLI toolchain, highlighting many practical, architectural shifts away from npm’s historically permissive, "trust-by-default" model. In the wake of attacks like Shai-Hulud and the Sapphire Sleet Axios compromise, security cannot rely on developer discipline or retroactive registry-side malware yanking. The toolchain itself must be engineered to fail-secure.

In this short blog post, we’ll highlight 3 distinct, highly actionable decisions that should become the new norm as far as interacting with software packages on JavaScript’s npm registry:

1. Stop running unvetted code automatically

Github reference

This should seem obvious from a security standpoint, but historically, npm has treated lifecycle scripts (preinstall, postinstall) as first-class, unrestricted citizens. Attackers are able to exploit this by adding sleeper dependencies that were never even imported by the application runtime code. In these scenarios, the sole purpose is to trigger an install-time script that’s able to drop a Remote Access Trojan (RAT).

The CLI must invert its defaults. Instead of requiring developers to pass --ignore-scripts or manually configure ignore-scripts=true in .npmrc, the toolchain should block all lifecycle scripts out-of-the-box. The npm registry should adopt a mechanism similar to pnpm’s strictDepBuilds or allowBuilds map. If a dependency attempts to execute a script that isn't explicitly greenlit in a locked configuration file, the CLI should throw a hard error and block the installation, forcing an explicit audit rather than permitting a silent compromise.

2. Close any backdoor registry loopholes

Github reference

A major structural loophole is the flexibility JavaScript package managers offer in resolving dependencies from unconventional sources, such as raw Git URLs or direct tarballs. These exotic sources completely sidestep registry-side protections - meaning no malware scanning, no OIDC trusted publisher verification, and no provenance cryptographic auditing. To add more fuel to the fire, an attacker could easily commit a malicious .npmrc inside a git dependency that silently re-enables lifecycle scripts on the victim’s machine.

The toolchain really must enforce strict protocol alignment here. Native CLI defaults should mirror npm's allow-git=none or pnpm's blockExoticSubdeps=true. Transitive dependencies must be structurally banned from pulling code outside of the primary secure registry. The CLI should also enforce that only explicitly audited, direct dependencies declared in the root package.json can utilise non-registry sources, effectively securing the wider dependency tree.

3. Introduce a cool-off period for new updates

Github reference

Most supply chain compromises have a highly volatile, but brief, day-or-so golden window where the malware propagates before security researchers or automated scanners flag and remove the package (the Shai-Hulud waves were typically mitigated within 12 hours, and the Axios compromise was also caught within hours). Permissive semver ranges mean automated CI/CD pipelines blindly pull down these poisoned packages minutes after publication.

If you don’t have an existing artifact management layer, like Cloudsmith or Nexus, we would recommend developers introduce a simple cooldown buffer into the dependency resolution engine itself. While features like min-release-age have started rolling out across package managers (such as in npm versions 11.10.0 and higher), the structural shift requires making a relative age gate (for example min-release-age=3d) an opt-out standard rather than an opt-in luxury. By natively refusing to resolve any direct or transitive package version that has not crossed a stability threshold, the CLI acts as a temporal circuit breaker, completely neutralising the smash-and-grab window of rapid worm propagation.

The software supply chain is broken (but we can fix it)

As discussed, there are practical solutions to many of the existing pain points in the npm ecosystem. To recap, npm shouldn't run setup scripts automatically. Turn them off unless they are explicitly trusted. Stop dependencies from pulling unverified code from raw Git links or external URLs that skip standard security scans. Try to avoid automatically downloading brand-new updates the second they publish (unless you absolutely have a strong reason for doing so). Wait a day or two to let the security community catch any hidden malware. If you have followed the above 3 secure-by-default approaches, you can confidently regain trust in open source software, and securely prevent the next wave of supply chain attacks.

LibKill: Scan Your Machine for Compromised npm, pip, and Bun Packages

Wed, 13 May 2026 11:02:12 +0000

Over the last few weeks, supply chain security has once again become a very real problem for developers.

We keep seeing the same attack pattern:

CI/CD token stolen
→ malicious package version published
→ developers install or update dependencies
→ compromised code lands on real machines

And the worst part is simple:

You may already have one of those compromised packages on your machine without knowing it.

That is why I built LibKill.

What is LibKill?

LibKill is an open-source supply chain security scanner.

It checks your local development environment against a database of known compromised package artifacts.

Currently, it scans:

npm global packages
pip packages
Bun cache

Then it cross-references what it finds against 2,672+ known compromised package artifacts.

If something suspicious is detected, LibKill can help you remove it interactively.

Why I built it

Most developers hear about compromised packages after the damage is already done.

A package gets reported.
A malicious version is removed.
A GitHub advisory appears.
A security company publishes an analysis.

But then comes the real question:

“Is any of this already on my machine?”

That question should be easy to answer.

LibKill is my attempt to make that check fast, local, and simple.

Features

LibKill currently supports:

Scanning npm global packages
Scanning installed pip packages
Scanning Bun cache
Cross-checking against known compromised artifacts
Interactive removal when threats are found
Background daemon mode
Desktop notifications
macOS, Linux, and Windows support
Single binary
Zero runtime dependencies

It is written in Go and distributed as a small standalone binary.

Installation

You can install it with one command:

curl -fsSL https://raw.githubusercontent.com/firfircelik/libkill/main/install.sh | bash

Or build it manually:

git clone https://github.com/firfircelik/libkill.git
cd libkill
make install

Example usage

After installation, run:

libkill scan

To start background monitoring:

libkill daemon

If compromised artifacts are found, LibKill will show the results and offer interactive cleanup options.

Threat coverage

LibKill currently covers known compromised artifacts related to campaigns and threat clusters such as:

Mini Shai-Hulud
Contagious Interview
StegaBin
SANDWORM_MODE
CanisterWorm
W4SP
TeamPCP
and many others

The threat database is built from public security sources including:

Socket.dev
GitHub Advisory Database
OSV.dev
Public security research

Why local scanning matters

A lot of supply chain security tools focus on repositories, lockfiles, or CI pipelines.

That is useful, but it does not fully answer what is already installed locally.

Developers often install tools globally.

They test packages.

They use temporary scripts.

They work across multiple languages and package managers.

They forget what was installed weeks ago.

A compromised package does not need to be in your current production repository to be a problem.

It may already exist somewhere in your local environment.

Project details

Language: Go
License: MIT
Binary size: around 14 MB
Dependencies: zero runtime dependencies
Platforms: macOS, Linux, Windows

GitHub:

https://github.com/firfircelik/libkill

Final note

LibKill is still evolving.

My goal is to make it a practical local security tool for developers who work with open-source packages every day.

If you work with npm, Python, Bun, or modern JavaScript tooling, you should not have to guess whether a known compromised artifact exists on your machine.

You should be able to check it quickly.

That is what LibKill is for.

Feedback, issues, and contributions are welcome.

curl -fsSL https://raw.githubusercontent.com/firfircelik/libkill/main/install.sh | bash

I Published My First npm CLI Tool

Fri, 03 Apr 2026 12:28:31 +0000

Hey folks!

Let me tell you about create-scaffold-kit — what it does, and my experience shipping it for the first time.

Why does this exist?

Every new project I start begins the same way:

ESLint. Prettier. Husky. Docker. CI.

An hour gone before I even write real code.

It’s tedious and honestly, it’s the same copy-paste every time.

So the question became, why not just automate this?

What is create-scaffold-kit?

It's a simple CLI tool that scaffolds a React or Next.js project with all the good stuff already set up. Just run one command:

npx create-scaffold-kit my-app

It asks you a few questions — framework, TypeScript, linting, testing, Docker, CI/CD and generates a full project ready to go.

Things it sets up for you:

✅ TypeScript (strict mode)
✅ ESLint with flat config (strict or standard)
✅ Prettier / OXfmt formatting
✅ Husky + lint-staged git hooks
✅ Vitest + React Testing Library
✅ Tailwind CSS
✅ Docker with multi-stage builds
✅ GitHub Actions CI/CD

No more copy-pasting configs. Just answer the prompts and start coding.

This is especially useful if you:

Start projects frequently
Care about consistent tooling
Don’t want to reinvent setup every time

Things I Didn’t Know Before Building a CLI

Here are things that were genuinely surprising while going through the process of building a CLI package for the first time. Maybe it saves you some time!

1. The `bin` field in package.json is the magic

Always wondered how npx create-something just... works. Turns out it's this little thing:

"bin": {
  "create-scaffold-kit": "dist/index.js"
}

That maps the command name to your entry file. Simple, but easy to miss.

2. Your entry file needs a shebang line

The first line of your CLI entry file must be:

#!/usr/bin/env node

Without it, the command just won't run. With tsup, this can be injected cleanly via the banner option in the config, no manual step needed:

banner: {
  js: '#!/usr/bin/env node',
}

3. Bundling for CLI is different

tsup handles the TypeScript compilation. But a few things stood out:

Setting "type": "module" in package.json
Making sure import paths use .js extensions, even in TypeScript source files
The files field to control what actually gets published to npm

4. The `files` field matters a lot

You can control which files get included when running npm publish:

"files": ["dist"]

Without this, you'd accidentally publish test files, source maps, scripts, everything. Not great.

5. `prepack` and `postpack` scripts are a thing

There are prepack/postpack lifecycle hooks that run before and after packaging. These weren’t on my radar before this project. Turns out they’re really handy for automating pre-publish steps.

6. Testing a CLI is... interesting

Vitest handles the unit tests here. Testing something that writes to disk and executes shell commands is tricky. Mocking fs, child processes, and prompts is a different kind of challenge compared to typical frontend component tests.

7. Publishing is both easy and scary at the same time

npm publish. Just two words. But right before running it:

"Was everything tested?"
"Is the version right?"
"Is the dist clean?"

A prepublishOnly script that runs type checking, linting, tests, and build before every publish is a lifesaver. It catches things before they go out.

Final Thoughts

This isn’t a groundbreaking tool, but building it gave me a much deeper understanding of the Node.js ecosystem, npm publishing, and how CLI tools actually work under the hood.

If you're a frontend dev who has never shipped a CLI tool — try it once. Even something small. The learning is worth it.

And if you give create-scaffold-kit a try, I'd love to hear your thoughts! It’s still early, but it works and is actively evolving..

Try it out

npx create-scaffold-kit my-app

Check out the GitHub

Thanks for reading!

Introducing csv-faker-generator: Generate Realistic Test Data in Seconds

Fri, 28 Nov 2025 22:22:04 +0000

Photo courtesy of Pexels

TL;DR: I just published csv-faker-generator, a TypeScript CLI tool that generates CSV files with realistic fake data. Perfect for testing, prototyping, and development. Install it with npm install csv-faker-generator.

The Problem

How many times have you needed test data for your application? Whether you're building a data pipeline, testing import functionality, or prototyping a feature, you inevitably need realistic-looking CSV files with hundreds or thousands of rows.
You have a few options:

Manually create sample data — tedious and limited
Use existing faker libraries — great, but requires writing boilerplate code
Export production data — risky and time-consuming
Use a generic CSV generator — inflexible and often outdated

None of these felt ideal. I found myself repeatedly writing the same wrapper code around @faker-js/faker and csv-writer just to generate test datasets. That's when I decided to build csv-faker-generator.

The Solution

csv-faker-generator is a lightweight, open-source npm package that makes generating fake CSV data as simple as running a single command.

Features

19+ data types — UUID, names, emails, addresses, phone numbers, dates, and more
CLI & Programmatic API — Use it from the command line or integrate it into your Node.js/TypeScript projects
Full TypeScript support — Complete type definitions included
Customizable output — Define your own columns and data types
Fast & efficient — Generate thousands of rows in milliseconds

Getting Started

Installation

npm install csv-faker-generator
or use it globally
npx csv-faker-generator

CLI Usage

The simplest way to generate a CSV file is through the command line:

Generate 100 user records
npx csv-faker -c id:uuid,name:name,email:email -r 100 -o users.csv

This creates a file with 100 rows containing random UUIDs, names, and emails.

More Examples

Generate customer data:

npx csv-faker --columns "userId:uuid,firstName:firstName,lastName:lastName,email:email,phone:phone" --rows 50 --output customers.csv

Generate company data:

npx csv-faker -c id:uuid,company:company,city:city,country:country -r 20

Generate employee records with salary data:

npx csv-faker -c id:uuid,name:name,jobTitle:jobTitle,salary:number -r 200 --output employees.csv

Programmatic Usage

Use it directly in your Node.js or TypeScript projects:

import { generateCSV } from 'csv-faker-generator';

// Generate user test data
await generateCSV({
  columns: [
    { header: 'id', type: 'uuid' },
    { header: 'name', type: 'name' },
    { header: 'email', type: 'email' },
    { header: 'address', type: 'address' },
  ],
  rows: 100,
  output: 'users.csv',
});

Real-World Use Cases

Testing Data Import Features

When building a feature that imports CSV files, you need realistic test data:

npx csv-faker -c orderId:uuid,customerName:name,email:email,amount:number -r 1000 -o orders.csv

Now you have 1000 realistic order records to test your import logic.

Load Testing & Performance Testing

Generate large datasets quickly to test your application's performance:

npx csv-faker -c id:uuid,data:username,value:number -r 100000 -o large-dataset.csv

Prototyping & Demos

Show stakeholders what your data pipeline looks like with real-looking sample data instead of [SAMPLE DATA] placeholders.

Database Seeding

Generate initial data for your development environment:

import { generateCSV } from 'csv-faker-generator';
import { parseCSV } from './your-parser';

// Generate test data
await generateCSV({
  columns: [
    { header: 'id', type: 'uuid' },
    { header: 'username', type: 'username' },
    { header: 'email', type: 'email' },
  ],
  rows: 500,
  output: 'seed-data.csv',
});

// Then seed your database
const data = await parseCSV('seed-data.csv');
await database.insert(data);

Why I Built This

As an Engineer working heavily with data pipelines and API testing, I found myself repeatedly needing the same thing: quick, realistic test data. The existing solutions either required a lot of boilerplate code or were overly complex for simple use cases.
I wanted something that was:

Dead simple to use (one command)
Flexible for both CLI and programmatic use
Well-typed (since I work with TypeScript)
Focused on the specific problem of CSV generation

Open Source & Contributions

This package is completely open source (MIT licensed) and hosted on GitHub. If you find it useful, have feature requests, or want to contribute, I'd love to hear from you!

Repository: https://github.com/manojkken/csv-faker-generator

npm: https://www.npmjs.com/package/csv-faker-generator

Conclusion

Whether you're testing a data pipeline, prototyping an application, or just need realistic sample data, csv-faker-generator is here to save you time. Give it a try and let me know what you think!

npm install csv-faker-generator

Questions or feedback? Feel free to open an issue on GitHub or reach out to me on Twitter.

A module for a hexagonal masonry layout with CSS and JavaScript

Wed, 01 Oct 2025 15:52:32 +0000

This is an announcement post for a new npm module, hexagonal-masonry-placement, released and maintained by me, Ingo Steinke, creative web developer based in Berlin, Germany.

A hex layout looks something like this.

Maybe it looks familiar from board games or online worlds, as the honeycomb tiling seemt to be the most efficient way to place items apart from the usual square layouts that most web forms and elements default to.

The above screenshot comes from my side project web app at https://devux.ingo-steinke.de/

While the CSS community has working drafts and experimental implementations for so-called masonry layouts, that place rectangular items in a shifted pattern like a brick wall, we can use a simple flex layout to fake more complex structures like in the screenshot above.

CSS flex and grid layouts can place items automatically in a responsive way, trying to fill the available screen space without cutting or hiding anything. That's super useful, and the result looks like a table with rows, only that there is no official built-in way to determine or act on which row an item is placed in. There are no :first-row or nth-row(2) pseudo-selectors in CSS.

I have wrapped my head around mathematical calculations to determine an items' row and set a custom CSS class name accordingly, until I found a much simpler solution that just compares each item's vertical top position with that of its predecessor and increment the row count when they differ.

I decided to publish the code as an npm module so I can refine the code and concept in one central place to avoid further confusion and possible inconsistent states of duplicated code across projects, if I ever use it anywhere else.The utility requires HTML markup and CSS styles similar to the example code provided. You can use the provided base styles in index.css or provide your own.

https://www.npmjs.com/package/hexagonal-masonry-placement

Streamlining Your Next.js Project with Private GitHub/Gitlab Repositories as NPM Packages

Wed, 10 Sep 2025 16:53:12 +0000

Using Private GitHub/Gitlab Repos in Your Next.js Projects

Imagine this scenario: you're working on a super cool Next.js project, and you have some shared code that you'd like to use across multiple projects. You don't really want to make it public by publishing it to npm. You also don't want to pay for an npm account to make your repos private. Is there a way to keep it private, secure, yet reusable? You bet!

In the world of Next.js v13.4 and beyond, using private GitHub or GitLab repositories as npm packages is not only possible, it's also quite straightforward. The steps vary for older versions of Next.js before v13.4 (those using Page Router) and won't be covered in this blog.

Essentially, we’ll be taking code from a private GitHub or GitLab repository and using it directly in our Next.js project. This method is perfect when you have shared components, utilities, or any other code that you need to reuse across several projects, but don't want to expose to the world (or persevere through the overhead of setting up an npm account).

Today, I'll walk you through the steps to make this happen. Buckle up, because we're about to make your life a whole lot easier!

Step 1: Create Your Private GitHub Repo

This is where your shared code will live. If you already have one, fantastic. If not, go ahead and create a new private repository on GitHub or Gitlab.

Step 2: Generate a GitHub Access Token

Navigate to your GitHub settings (or Gitlab settings for those using Gitlab).
Create a new personal access token (make sure it only has read access).
Copy this token and keep it safe (you’ll need it soon).

Step 3: Set Up Your Shared Repo

In your shared repository's package.json, set the name field to whatever you'd like to call your package, e.g., "package-name": "1.0.0".

Step 4: Update Your Next.js Project’s `package.json`

In the package.json of the Next.js project where you want to use your shared code:

{
  "dependencies": {
    "package-name": "git+https://<github_token>:*Emails are not allowed*/<user>/<repo>.git#branch-name"
  }
}

Replace <github_token>, <user>, <repo>, and branch-name with the appropriate values from your setup.

Final Steps: Configuration in Next.js

In your next.config.js, add the following:
```
module.exports = {
    transpilePackages: ["package-name"],
};
```
This tells Next.js to also compile your typescript code from the shared repo and transform it to javascript - that's basically what transpile means; a combination of the word 'transform' and 'compile'. Without this, you'll get module parsing errors for your typescript (.ts) files.
If you're using Tailwind CSS, update your tailwind.config.js to include your shared package:
```
module.exports = {
    content: [
        "./node_modules/<package_name>/src/**/*.{js,ts,jsx,tsx,html,mdx}",
        "./node_modules/<package_name>/app/**/*.{js,ts,jsx,tsx,html,mdx}",
    ],
    //… other tailwind config
};
```
Replace <package_name> with the name of your shared repo. Also, if you aren't using the src folder, feel free to adjust the values according to your setup
Now run npm install and voila! your shared package has now been installed as an NPM dependency and you can use it in your project.

Before We Finish Just Yet

Always remember to update the version number in your package.json with a higher value each time you make a change to your shared repo. After words, run npm update <package_name> where <package_name> is the name of your shared package/repo. This will ensure that your changes in the shared package's changes are published to your project.

Conclusion

Incorporating private GitHub repos as npm packages in your Next.js projects not only keeps your code organized and secure but also significantly boosts your productivity. You no longer need to duplicate code or compromise your privacy by publishing sensitive code to public registries.

So, what are you waiting for? Dive in and streamline your projects today. And remember, it’s these smart shortcuts that often make a big difference in the efficiency and success of your development efforts.

Publish your packages to NPM automatically with GitHub Actions

Tue, 19 Aug 2025 11:21:15 +0000

Automating publication prevents manual errors, speeds up releases, and forces you to maintain a repeatable and transparent process.

In this article, we're going to create a GitHub Actions workflow that publishes to NPM when you push to main. The flow installs dependencies, runs tests, compiles, and, if all goes well, publishes the package using a secure token stored as a secret.

What is the purpose of the workflow?

Every time you merge changes to main, we want to:

Install dependencies
Run tests
Build the package
Publish to NPM using secure credentials

This standardizes the publishing process and reduces the risk of human error.

General workflow structure

name: Publish to NPM
on:
  push:
    branches:
      - main

jobs:
  publish:
    name: publish
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: "22"

      - name: Install dependencies
        run: npm ci

      - name: Run tests
        run: npm run test

      - name: Build package
        run: npm run build

      - name: Publish to NPM
        uses: JS-DevTools/npm-publish@v3
        with:
          token: ${{ secrets.NPM_TOKEN }}

️ ️ What does each step do?

on: push to main

Triggers the workflow when pushing to the main branch. If you prefer to publish only with tags, you can change the trigger to on: push: tags: - ‘v*’.

actions/checkout@v4

Downloads the repository to the runner.

actions/setup-node@v4

Configures Node.js (v22 in the example). You can enable cache: ‘npm’ to speed up installations.

npm ci / npm install

Installs dependencies. npm ci is faster and more reproducible in CI if you use package-lock.json.

npm run test and npm run build

Verify that the package passes tests and compiles correctly before publishing.

JS-DevTools/npm-publish@v3

Publish the package by reading package.json. Use the token you pass through with.token.

Authentication with NPM: NPM_TOKEN

To publish, you need a token in NPM and save it as a secret in GitHub:

Create an Automation Token in your NPM account (recommended for CI; respects 2FA and allows automatic publishing).
In GitHub, go to Settings → Secrets and variables → Actions → New repository secret.
Create the secret NPM_TOKEN with the value of the NPM token.

If your package is scoped (e.g., @your-org/package), make sure that package.json contains “name”: “@your-org/package” and “publishConfig”: { ‘access’: “public” } if you want it to be public.

Example of publishConfig in package.json:

{
  "name": "@tu-org/tu-paquete",
  "version": "1.2.3",
  "publishConfig": {
    "access": "public",
    "tag": "latest"
  }
}

Dry-run and version control

Dry-run: test the flow without actually publishing:

- name: Publish to NPM (dry run)
  uses: JS-DevTools/npm-publish@v3
  with:
    token: ${{ secrets.NPM_TOKEN }}
    dry-run: true

Versioning: this flow publishes the version specified in package.json. Be sure to update the version before merging to main.
If you use automatic versioning (e.g., Conventional Commits + automatic releases), integrate that stage before the publication step.

✅ Final result

With this workflow:

You publish to NPM in a consistent and repeatable manner.
You avoid broken releases thanks to preliminary tests + builds.
You keep credentials secure with GitHub Secrets.
You reduce manual steps and time between merge and release.

Would you rather set it up with a visual interface?

If you're interested in defining this flow with a visual interface and getting the YAML instantly, you can use OctoLab:

Step-by-step visual editor
Dynamic fields for actions and tokens
Real-time YAML preview
Built-in validations
Copy/download and you're done

Try it out: https://www.octolab.app/templates/npm-publish

Conclusion

Automating publication to NPM with GitHub Actions reduces friction and errors. With a simple configuration—tests, build, and a publish step with a secure token—you can standardize releases and focus on building value.

If this was helpful, let me know what you would like to add to the template (tags, prereleases, monorepos, changelogs, etc.). Let's keep going!

Create Launcher CLI (npm Package)

Sun, 03 Aug 2025 08:17:14 +0000

“Why am I still copy pasting the same setup files again and again?”

If you’ve ever asked yourself this after starting yet another web project...

You’re not alone — I’ve been there too.

So I built something to make project bootstrapping painless.

️ Meet `create-launcher`

A zero-config CLI tool that lets you scaffold modern web projects instantly, with everything pre wired and ready to go.

Features at a Glance

✅ Interactive CLI with prompts
⚛️ Project templates:
- React (Vite)
- Next.js
- Eleventy (11ty)
- Vanilla JavaScript & TypeScript
Tailwind CSS integration (optional)
TypeScript support
Pick your favorite package manager (npm, yarn, pnpm)
ESLint pre-configured
⚡ Auto installs everything you need

Get Started in One Line

npx create-launcher

The CLI walks you through setup, just answer a few prompts, and boom
Your project is scaffolded and dependencies installed. No extra config.

See It In Action

⚡ Creating a React + TypeScript + Tailwind project in under 30 seconds

Why I Built This

As a dev who loves shipping fast, I kept hitting the same roadblocks every time I started a new project - boilerplate, repeated setup, switching between Vite and Next.js, etc.

Now, with create-launcher, I can:

Start a project in under 15 seconds
Have a consistent, clean folder structure
Focus on writing code, not configuration

Check It Out

NPM Package
GitHub Repo

Ideas for Future Versions

Templates On (Vue.js, Svelte, Angular etc.)
Git init + first commit
Prettier integration
Optional GitHub Actions CI setup
Custom template support

Feedback Welcome

I’d love to hear what you think.
Found a bug? Have a feature request? PRs are welcome, and stars always appreciated ⭐

Let’s make spinning up projects feel exciting again.

♂️ About the Author

I'm Pranav Verma, a passionate Full Stack Developer and tech enthusiast exploring the intersection of DevTools, AI, and modern web development. I love building tools that simplify developer workflows and enhance productivity.

Connect with me:

If you liked this project, don’t forget to ⭐ it on GitHub and share it with fellow devs!

And, if you want to contribute something helpful to the community, just read the CONTRIBUTING.md in GitHub repo and start helping others and yourselves.

How npm install Works? What Really Happens When You Hit Enter

Wed, 30 Jul 2025 19:52:33 +0000

You've just cloned a new repository. The first command you run, almost by muscle memory, is npm install.

But have you ever paused to wonder why a fresh npm install sometimes takes 30 seconds, and other times 3 minutes? What hidden mechanisms kick in? What separates a smooth install from one that spews errors about peer dependencies or breaks your build?

npm install isn't a simple download command; it's a complex, multi-stage process. In this deep dive, we'll dissect it piece by piece, equipping you with the under the hood intelligence to debug issues, optimize your workflows, and understand the trade offs of the entire Node.js ecosystem.

The Cast of Characters: Key Files and Concepts

Before we follow the trail, let's meet the key players.

package.json: Your project's manifest. It’s the shopping list that names your direct dependencies and their allowed version ranges (e.g., "react": "^18.2.0").
package-lock.json: The detailed, immutable receipt of your installation. It records the exact version of every single package (including sub-dependencies), ensuring deterministic installs. This is your guarantee that every machine gets the same node_modules tree.
node_modules: The directory where the actual package code is stored. It's the "pantry" that gets filled with ingredients.
The npm Registry: The public "supermarket" of packages, located at registry.npmjs.org.
The npm Cache: A local storage area on your computer (find it with npm config get cache) where npm keeps copies of downloaded packages to speed up future installs.
Cameo Appearance: Registry Proxies: In many corporate environments, you won't hit the public npm registry directly. Instead, you'll go through a proxy like Verdaccio or JFrog Artifactory. These cache packages on the company's network, providing security, compliance, and faster installs for common dependencies. They act as a middle man, changing the npm Registry character in our story to a local one.

The Process at a Glance: A Flowchart

Here's a high level map of the journey we're about to explore.

The Step by Step Process

1. Reading the Manifests

npm begins by reading the dependencies, devDependencies, and optionalDependencies from your package.json.

// package.json (excerpt)
{
  "name": "my-project",
  "version": "1.0.0",
  "dependencies": {
    "express": "^4.18.2",
    "dotenv": "^16.3.1"
  },
  "devDependencies": {
    "nodemon": "^2.0.22"
  }
}

2. Resolving the Dependency Tree

This is where the real logic kicks in. npm builds a complete tree of all packages required.

If a package-lock.json exists, it's treated as the absolute source of truth, ensuring a deterministic build.
If not, npm resolves versions based on package.json ranges and generates a new package-lock.json.

3. Checking the Local Cache

Before making any network requests, npm checks its local cache for every package in the tree. If a specific version exists, it's used instantly.

4. Fetching from the Registry

Any packages not found in the cache are downloaded from the configured registry (public npm or your company's proxy).

5. Unpacking and Laying out `node_modules`

npm unpacks the downloaded tarballs into your project's node_modules folder, creating a "flat" dependency tree to minimize duplication.

A Quick Sidebar on Peer Dependencies

You've likely seen warnings like UNMET PEER DEPENDENCY. A peer dependency is when a package expects you (the developer) to install another specific package in your project. For example, react-router-dom requires react as a peer.
Before npm 7, you had to install these manually. Now, npm 7+ auto-installs them, but it will still warn you if it detects a version conflict, which is a signal you need to resolve in your package.json.

6. Running Lifecycle Scripts

This is a powerful, but risky, step. Packages can define scripts (preinstall, install, postinstall) that run arbitrary code on your machine after installation. This is used for tasks like compiling native addons.

Watch Out: The Security Risk of Lifecycle Scripts

Because postinstall scripts can run any code, they are a potential attack vector (e.g., a malicious package stealing environment variables).
The Defense: Be cautious about the dependencies you add. Use npm audit regularly to check for known vulnerabilities in your project's dependency tree.

Beyond `npm`: A Look at the Alternatives

Understanding npm install is great, but a true expert knows the landscape. Here’s how npm's philosophy compares to its main rivals.

`pnpm`: The Disk Space Saver

pnpm takes a radically different approach. Instead of copying packages into every project's node_modules, it stores all packages in a single, global content-addressable store on your machine. It then uses symlinks (or hardlinks) to link them into your node_modules folder.

Pro: Massive disk space savings and significantly faster installs.
Con: Can sometimes have edge-case issues with tools that don't correctly resolve symlinks.

`Yarn (v2+)`: The Plug'n'Play Innovator

Yarn v2+ (often called "Berry") gets rid of the node_modules folder entirely. Instead, it generates a single .pnp.cjs file. This file tells Node.js exactly where to find the code for every required package (which are stored in a compressed .zip format in your .yarn/cache directory).

Pro: Extremely fast and reliable installs, zero phantom dependencies, and a better check-in-to-git experience.
Con: Requires editor and tool integration to work, which can be a steeper learning curve for teams.

Conclusion: Your Turn to Investigate

npm install is a cornerstone of modern web development, balancing speed, determinism, and a vast ecosystem. Now you know its secrets, from the lockfile's critical role to the security implications of its final steps.

Here’s your challenge: Next time you run npm install on a project, add the --timing flag (npm install --timing). This will generate a performance report (npm-debug.log). Open it up, find the total time, and see which step was the bottleneck.

Share your findings in the comments!

Let's Connect

Thanks for diving deep into the world of npm install with me!

If you found this helpful:

Share it with a teammate who's always puzzled by lockfiles
⭐ Leave a reaction or comment, I'd love to hear your thoughts!
Got a tip or trick around npm, pnpm, or dependency management? Drop it below.

Follow me here on Dev.to or connect with me on

• LinkedIn • X (Twitter) • GitHub

for more dev deep dives.

Till next time,

– Pranav Verma

Meet Hippoo: The Lightning-Fast CLI Tool Every Dev Needs to Check NPM Package Sizes

Wed, 14 May 2025 23:27:57 +0000

Introducing Hippoo — a blazing-fast CLI tool that helps you analyze and compare npm package sizes before you install them. Built by James Akpan

“Don’t just install it. Inspect it.”
— Hippoo’s unspoken philosophy

In the age of bloated bundles and performance-first web apps, Hippoo steps in like a digital bodyguard. — Hippoo is a smart, sleek CLI tool that helps you check and compare npm package sizes before they enter your codebase.

No more surprises. No more blind installs.

What is Hippoo?

Hippoo (yes, with two o's) is a lightning-fast command-line tool to analyze and compare npm packages — giving you clear insights about:

Minified & Gzipped Size
Dependency Count
️ Download Time
Tree-shaking Support
Hippoo Score (0–10)
Smart Recommendations

Hippoo answers the real dev questions:

Is this package too heavy?
Should I choose React or Angular?
Will this slow down my app?

Installation

You can install Hippoo globally using either npm or yarn:

# Using npm
npm install -g hippoo

# Using yarn
yarn global add hippoo

Basic Usage

Check a single package:

hippoo react@18.0.0

⚖️ Compare multiple packages:

hippoo compare react angular

✨ Sample Output (Real Example)

hippoo compare react angular

Metric	React	Angular
Size	7.4 kB	181.0 kB
Gzipped	2.8 kB	62.3 kB
Download Time	1ms	2ms
Dependencies	0	0
Tree-Shake	❌	❌
Hippoo Score	8/10	6/10

Best for Performance-Critical Apps: React
Best for Feature-Rich Projects: Angular

️ Command Reference

hippoo [package-name] [options]
hippoo compare [pkg1] [pkg2] [...]

Options:

-v, --version → Show version number
-d, --detailed → Show detailed breakdown
-j, --json → Output results in JSON
-h, --help → Show help info

Why Use Hippoo?

Size Analysis — Know what you're adding.
⚖️ Package Comparison — Pick the better tool.
Performance Insights — Stay light and fast.
Smart Recommendations — Use the right tool for the task/project.

Resources

Official Website
GitHub Repository
MIT License

Final Thoughts

Hippoo isn’t just a tool.
It’s a mindset — inspect before install.
Analyze before adding. Optimize before bloating.
Big ups to @codiejay (James Akpan) for building something every dev can use. Let’s support, test, and spread the word.

Next time you go to install a package, pause and ask:

“Did I Hippoo it first?”

Feel free to share thoughts, issues, or praise in the comments. And if you're vibing with Hippoo, don’t forget to ⭐ the repo!

Coder Legion - Recent posts tagged npm

Who Can Change Your npm Release Tags?

Who Should Be Allowed to Change Your npm Release Tags?

Why this matters

What development teams should review

Discussion

@seosiri/developer-ui-kit — a zero-dependency React licensing guard for SaaS dashboards

Why this exists

How it works

What's actually notable here

Worth discussing

agentsmyth

I Kept Rebuilding PDF Features in Vue 3, So I Built vue-pdf-export

What it supports

Installation

Basic usage

Canvas or selectable text

Programmatic output

Nuxt support

Pagination

Large-document rendering

Cancellation

Page-aware progress

Headers

Footers

Footer performance improvements

Repeated image optimization

Resource cleanup

Browser responsiveness

Watermarks

PDF security

Metadata and compression

Clickable links

Safer filenames

A note about encrypted raster PDFs

Testing and performance work

Why I built a Vue layer instead of replacing the underlying libraries

Current release

Try it

SEOSiri IAIG: An open MCP API control plane to stop AI agents from breaking production infrastructur

Understanding exec() in FSCSS — Two Completely Different Jobs

Understanding exec() in FSCSS

1. Inside Stylesheets: Debugging & Logging

Console Logging

Checking Array Data

2. In JavaScript & Imports: Compilation Engine

CDN Initialization (HTML)

Programmatic JavaScript Usage

Quick Summary

Developer Weekly Briefing — August 21, 2026

GitHub Copilot bets on model choice, not model loyalty

VS Code decouples AI agents from the editor window

Claude Code's temporary usage boost expires tonight

npm v12 shuts down a popular malware trick — the threat isn't gone

LangChain's dcode isn't new — its governance play for sensitive code is

GitHub sharpens CodeQL for Actions workflows and modern JavaScript

Tessl is betting on standards to close the AI code review gap

Also from Coder Legion this week

The evolution of Shai-Hulud-style worms

Shai-Hulud, Mini Shai-Hulud and similar worms

Miasma

Hades

keyv and cachable packages compromised

Shai-Hulud-style worms will continue to change shape

Quick recap of what you’ve read

🚀 Built an MCP Developer Ecosystem at SEOSiri

MCP #ModelContextProtocol #AIAgents #LLM #AIEngineering #DeveloperTools #AIInfrastructure #SoftwareArchitecture #SEOSiri

Giving an AI Agent a Benchmark Tool It Can Install and Actually Trust

Part 2 of 2: the npm-to-uv-to-PyPI bridge that closes the installation gap, and the adversarial re-verification discipline that makes the output worth acting on autonomously

Defining "agent-native" requirements

Live on both registries

Generating structured JSON output

Current approaches to agent tool distribution

Verifying the tool's internal claims

Fixing the temporal-KG boundary bug

Catching regressions in mem0 during a live run

Unifying distribution and verification

References

They Asked for My AI Rules. But I Could Not Just Hand Them Over.

The rules worked because I built them for one repo

Understanding `exec()` in FSCSS

A real example: turning `pnpm` into FNPM (without anyone noticing)

The Story Behind `use-outside-click`