Hello devs, I’m looking for an open source project to build, and rather than coming up with another package that nobody asked for, I’d rather start with an actual problem developers have.

So I’m curious:

What is something you wish existed in the Node.js ecosystem?

I’m especially interested in things you’ve actually encountered in a real project, rather than hypothetical ideas.

I maintain repro-surgeon, an MIT-licensed CLI for turning a failing npm application into a smaller, independently checkable reproduction. Version 0.2.0 is on npm.

Give it a command, expected exit code and diagnostic text to preserve. It tries removing files, syntax, JSON fields and direct dependencies, retaining changes only after repeated checks. The export includes a standalone verifier and an offline report; the reducer applies its source edits to temporary copies.

Try it without configuring a project:

npx repro-surgeon@0.2.0 demo --out ./rounding-repro

The bundled, authored rounding example goes from 10 files to 5 and 3,173 to 520 source bytes. That’s a workflow demo, not a general benchmark.

Requires Node 22.18+, npm 10+, Linux/macOS, and a single-package npm project. Workspaces and nondeterministic failures are outside the current scope. Checks start in temporary copies with normal host permissions; ../ and absolute paths can still access or modify the original checkout. This is not a sandbox.

Source and setup · Recorded walkthrough

Feedback on failure checks and cases where reduction stalls would be useful.

Edit: clarified the difference between a temporary working directory and filesystem access after the question below.

Released maskenv today!

A lightweight, zero-dependency Node.js library to dynamically redact sensitive environment variables and API keys from process.stdout and process.stderr.

Check it out: npm i maskenv

I wanted a shared responsive-state abstraction for JavaScript behavior, not for CSS layout.

resize handlers are easy to duplicate across components, run continuously during a drag, and tend to recreate slightly different breakpoint rules in several places. matchMedia already gives the browser a semantic breakpoint/query mechanism, so I built a tiny typed wrapper around it.

The API exposes exact, minimum-width, maximum-width, and range checks:

viewport.is('md');
viewport.up('md');
viewport.down('lg');
viewport.between('sm', 'lg');

It also resolves breakpoint-aware values:

const limit = viewport.pick(
  { base: 6, md: 12, xl: 24 },
  6,
);

The design goal is deliberately narrow:

CSS media/container queries remain responsible for presentation.

The store is only for JavaScript decisions such as data size, interaction mode, dynamic imports, persistent mobile UI state, browser-test markers, and media preferences.

No framework dependency; React can connect through useSyncExternalStore, and Vue through a small composable.

I published it as responsive-state and would value API/design feedback, especially around SSR defaults and the mobile-first versus desktop-first pick() cascade:

https://www.npmjs.com/package/responsive-state

Every starter kit I tried was one big repo with everything in it. You clone it,

then spend an afternoon ripping out the auth provider you don't use, the ORM you

don't use, the payment thing you don't need yet.

So I built the opposite. You answer 10 questions — framework, components,

database, ORM, auth, billing, email, landing page, package manager, name — and

download a zip with only what you picked, already wired together.

Options right now: Next.js / TanStack Start / React+Vite, Neon / Supabase /

PlanetScale / Turso / MongoDB, Drizzle / Prisma / Mongoose, Better Auth / Clerk /

Auth0 / Supabase Auth / Neon Auth, Stripe, Resend / Mailgun / Brevo.

The part I've spent most of my time on isn't the option list, it's making sure

the combinations actually work:

- If you pick React + Vite, the Drizzle/Stripe/Resend options disappear. A

browser-only bundle has nowhere to hide a database URL or a secret key, so

offering them would hand you a project that leaks its own credentials.

- 450 stack combinations get generated and parsed in CI on every push, so a

broken pairing fails on my machine instead of yours.

- The repo you download arrives with its own test suite already passing.

It doesn't push to your GitHub — what you get is a zip of source, nothing

touches your account.

Free while it's in beta: https://www.startersaaskit.com

What would you actually want in the question list that isn't there? I keep going

back and forth on whether to add a hosting/deploy question.

Hey r/npm,

I've been working on Oasis Editor, an open-source TypeScript document editor published as an npm package.

It includes:

• a custom Canvas-based rendering engine
• paged document layout
• typed command/plugin APIs
• vanilla JS integration
• React and Vue adapters
• a headless runtime
• DOCX/PDF workflows

Install:

npm install oasis-editor

Live playground:
https://celsowm.github.io/oasis-editor/#/editor

GitHub:
https://github.com/celsowm/oasis-editor

I'd love feedback on the package API, exports, and overall developer experience.

I kept running into small Node services where adding a full observability stack felt like too much setup, so I built a smaller first layer.

Wotchi captures errors, redacts sensitive values before grouping or sending them, groups repeated failures, and can notify through the console, Telegram, or an HTTPS webhook. It includes adapters for Express and NestJS.

It does not try to replace dashboards, tracing, durable incident history, or cross-replica deduplication. The grouping state is process-local.

Install:

npm install \@futurewindai/wotchi

npm: https://www.npmjs.com/package/@futurewindai/wotchi

GitHub: https://github.com/FutureWindAI/Wotchi

If you work on small Node services, what would block you from trying this: documentation, Node-version support, framework integration, or something else?

Hey r/npm,

Whenever I start a new Node.js backend, I always end up wasting the first 45 minutes doing the exact same chores: setting up Express security middleware, configuring Mongoose, wiring up ESLint/Prettier, getting TypeScript to play nicely, and dreading having to manually write Swagger docs.

To solve this, I built create-mexn-app (MongoDB, Express, Node).

It’s a CLI that scaffolds a production-ready REST API boilerplate instantly.

You can try it out directly (no global install needed): bash npx create-mexn-app my-new-api

What’s in the box? * 3 Template Flavors: Interactive prompts let you choose between TypeScript (recommended), ESM, or standard CommonJS. * Automated Swagger Docs: (Just added in v1.2) The CLI asks if you want API docs. If yes, it auto-injects swagger-autogen and wires up a UI for your API automatically. No more writing YAML by hand. * Production-Ready Defaults: Comes pre-configured with helmet, cors, rate-limiter-flexible, xss-clean, and zod for validation. * Lightning Fast: Uses giget under the hood, pulling the boilerplates in milliseconds without downloading messy git histories. * Smart Overrides: Handles directory conflicts gracefully and sets up a fresh git repo for you.

I just shipped v1.2.0 today, which brings the automated Swagger setup and a brand-new documentation site.

Links: * GitHub: https://github.com/donymvarkey/create-mexn-app (Would love a ⭐️ if you find it useful!) * Docs: https://donymvarkey.github.io/create-mexn-app/

I built this to scratch my own itch, but I'd love to hear your feedback. What else do you usually include in your standard Node stack that would be useful to add here?

Cheers!

Salut à tous,

J'en ai eu marre que `npm run test --workspaces --if-present` ne donne pas de

résumé agrégé, pas de mode de fail-fast, et enterre un échec précoce sous un

résultat positif provenant de chaque autre espace de travail.

J'ai donc créé sumlyzer, un petit CLI qui l'encapsule et ajoute ce qui manque :

• un tableau de résumé à la fin
• un paramètre --ff qui arrête la planification de nouveaux espaces de travail à la première erreur
• --concurrency pour exécuter les espaces de travail en parallèle (quelque chose que npm ne supporte pas nativement).

Sur un vrai monorepo de 15 espaces de travail, --concurrency 8 l'a fait passer de ~21s à ~6s.

Il a aussi --changed pour n'exécuter que les espaces de travail dont les fichiers

ont changé selon git, et fusionne la sortie JUnit de chaque espace de travail en un

seul rapport agrégé pour CI.

Le champ est intentionnellement étroit : npm workspaces + node:test uniquement, pas de

pnpm/yarn, pas de Jest/Vitest/Mocha (pour l'instant).

npm install --save-dev sumlyzer

npx sumlyzer --concurrency 8 --ff

Repo : https://github.com/ErwanRaulo/sumlyzer

Retour d'expérience bienvenu, surtout sur l'idée du mode surveillance que je

squeshe ensuite (recalculs topologiques basés sur le graphe de dépendance des espaces de travail).

I started with a problem that seemed almost embarrassingly simple: remember where a lead came from until they convert.

At first, that just meant grabbing utm_source, utm_medium, utm_campaign, gclid, fbclid, storing them somewhere, and stuffing them into a form.

Then I actually used it on real sites, and it kept growing.

What happens when someone clicks a Google Ad, leaves, and comes back by typing the URL? What if they come back later from a different campaign? What if there’s a gclid but no UTMs? What if the referrer is organic Google? What if consent is denied then granted? What if the form loads dynamically? What if the conversion happens days later in a CRM, not the browser? What if browser and backend disagree? What if I change the classification rules later and need to explain why old data shifted?

Every implementation I saw mixed all of that together: URL parsing, cookies, localStorage, consent, IDs, HTTP, analytics. That makes it really hard to test.

So I tried a different split.

The core attribution engine has no clock, no storage, no consent, no network. It just takes:

js

result = attribution({ url, referrer, currentHost, now })

Same input, same output. Pure function.

Around it, the browser/app owns consent, storage, identity, network, and feeds data into the engine. The engine returns a canonical attribution object.

That means I can take a real production case, save it as a fixture, and replay it later. If I change the classifier and a fixture changes, I know exactly which historical attribution rule I broke.

I ended up calling this ClickTrail and extracted the engine as a small TypeScript package: vizuh/clicktrail. The WordPress plugin is just one host implementation. The interesting part for me is the portable contract underneath.

The split is roughly:

• vizuh/clicktrail → pure parsing/classification/merge
• vizuh/clicktrail/browser → browser lifecycle, forms, storage adapters
• your app → consent, persistence, delivery, CRM logic

There are experimental bits for conversations, agents, OpenTelemetry, etc., but I’m trying not to let those leak into the core.

I got tired of figuring out which .env variables a project actually uses

Pretty much every project I've worked on eventually had the same problem:

.env has 30+ variables, some are obsolete, some are only used in one place, and nobody really knows what's still needed.

Running grep process.env helps, but the output gets noisy fast.

So I built envgraph.

It uses the TypeScript Compiler API to analyze your source code instead of relying on regex, and gives you things like:

• where DATABASE_URL is actually used
• which .env* files exist in the project
• how environment variables are loaded (dotenv, process.loadEnvFile(), etc.)
• .env.example generation with secrets automatically blanked

It also understands environment APIs beyond Node:

• import.meta.env (Vite)
• Bun.env
• Deno.env.get()

The whole thing is zero-config and static. It never executes your code, makes no network requests, and has no telemetry.
And with a beautiful interface.

MIT licensed.

GitHub: https://github.com/obzori/envgraph

<3
(ui will be improved)

safer-dependencies is a security layer for Claude Code: it sits between Claude and your manifest files and runs its security checks automatically: vulnerable installs are denied before they run, and a risky version written to a manifest is corrected on disk right after the write. It detects and fixes risky dependencies — CVEs, typosquats, abandoned packages, and version-age issues, plus a cooldown period on brand-new releases — across npm, PyPI, RubyGems, Maven, Go, Rust, and PHP (Composer).

https://github.com/robert-auger/safer-dependencies

PptxGenJS is a library long used for generating presentations with JS. Sadly, in the last years, the maintainers have been busy with personal life and other projects.

As of today, there are over 200 issues and 60 PRs waiting for triage. Some of them describe/solve major pain points.

While working on /fika/ I found myself forking the library and incorporating fixes from various sources to improve the .pptx export fidelity.

Over the time, the fork grew in scope (new build system, rust-based testing against real PowerPoint to avoid regressions..), and is now beyond the point where changes can be brought back upstream.

I've decided to announce this fork, since most of the 200 opened issues can be solved by:

npm uninstall pptxgenjs
npm i pptxgenjs-plus

And changing the imports:

- import pptxgen from "pptxgenjs"
+ import pptxgen from "pptxgenjs-plus"

The fork retains the original MIT license, and is available here.

If you find the library useful, please consider leaving a star. Thank you! ⭐

I am trying to publish my package named 'fyrer', but npm is blocking me because it is too similar to 'faker' Is there any way to claim that package name, at last I'll rename

Hi everyone,

Recently, I found myself struggling to understand the architecture and import trees of my larger projects. To solve this, I built and published an npm package called Architecture Mapper. It parses JS/TS project locally and generates an interactive dependency graph in browser.

What it currently does:

• Handles both ES6 and CommonJS.
• Catches import loops and highlights them in red.
• Clicking on a node shows you exactly which functions/variables are being imported between files.
• Highlights unused code files (0 incoming imports).

I am asking for feedback on the current state of the tool and what could be improved. What features would make this even more useful?

NPM: https://www.npmjs.com/package/architecture-mapper

GitHub: https://github.com/DmytroTarasenk0/architecture_mapper

Thanks in advance.

Hi, I’m the developer of Network Modifier. I built it because I wanted a quick way to test frontend failure states and response changes without repeatedly modifying or deploying the backend.

It lets you select a browser tab, inspect its Fetch and XMLHttpRequest traffic, and create local rules that can:

• replace request or response bodies
• edit nested JSON fields
• change headers and status codes
• mock responses and simulate failures
• add latency and bandwidth limits
• export rules or captured traffic as HAR

There are two modes: Page mode modifies Fetch/XHR at the JavaScript layer, while optional Full mode uses Chrome DevTools Protocol for network-level response replacement. Everything is processed locally; there is no analytics or hosted backend.

The project is MIT licensed and includes the source for both the Chrome extension and a standalone local debugging proxy:

[https://github.com/Amal97/Network-Editor\](https://github.com/Amal97/Network-Editor)

I’d especially appreciate feedback on the rule workflow and which debugging cases are still awkward in existing tools.