Flare Redact scans text and nested objects locally, then masks API keys, tokens, credentials, and PII before they reach Pino, Winston, Express, OpenAI, or Anthropic.

Fully open source with zero runtime dependencies.

GitHub: https://github.com/umudhasanli/flare-redact
npm: https://www.npmjs.com/package/flare-redact

Hey everyone! I am DoMe, a founding moderator of r/lancache_ng.

This is our new home for all things related to

since I was a longterm user of lancache, but gone quiet i thought about a better generation.
herefore it is under heavy developerment and one key feature: SSL Support, Pre-Warming etc

We're excited to have you join us!

I hope i find a lot ppl to try out my in dev software :D
Fun aside, sometimes i may break by accident something but i try to fix it. feel free to open an issue on https://github.com/wiki-mod/lancache-ng

Community Vibe
We're all about being friendly, constructive, and inclusive. Let's build a space where everyone feels comfortable sharing and connecting.

Thanks for being part of the very first wave. Together, let's make r/lancache_ng amazing.

Hey everyone! I built a Node.js CLI called licenseproof and I'd love some feedback before I do a wider launch.

It scans your npm dependency tree (package-lock.json, pnpm-lock.yaml, or yarn.lock) resolves every dependency license, flags conflicts with your project's license, and explains the results in plain English.

Design goals:

Runs completely offline

No telemetry

No hosted service

npx-friendly

Example: npx licenseproof scan --project-license MIT

I'm especially interested in feedback from anyone who's dealt with npm licensing or compliance before. What edge cases am I missing?

Things I'm thinking about:

Lockfile parsing strategy

Package metadata resolution

Ambiguous/custom licenses

CLI/API design

Human-readable vs machine-readable outputs

The repo is private while I'm working on it , but attached a short demo GIF. Happy to answer implementation questions or show snippets if there's something you'd like to see. Thank you!

When AI coding assistants like Claude add packages to your project, they often pick whatever version sounds right — without checking whether it has known security vulnerabilities, whether the package is still actively maintained, or whether the name is a typo away from a malicious lookalike.

safer-dependencies is a security layer for Claude Code that audits packages before they’re added to your project. It detects and fixes risky dependencies, including CVEs, typosquats, abandoned packages, version-age issues, and adds package-cooldown periods across npm, PyPI, RubyGems, Maven, Go, and Rust.

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

I kept shipping React/Next apps and finding accessibility and SEO issues after deploy — missing alt text, bad heading hierarchy, unoptimized meta tags, stuff that's easy to catch if you check early but easy to miss under deadline pressure.

Built UIAudit.js to fix that — a CLI + VS Code extension that scans your React/Next.js codebase and flags accessibility, SEO, and performance issues directly in your editor, before you ever open Lighthouse.

Works on React and Next.js projects

Catches a11y issues (missing alt, ARIA misuse, contrast-adjacent stuff), SEO gaps, perf smells

CLI for CI pipelines, extension for inline feedback while coding

Free, open source, on

npm: https://www.npmjs.com/package/uiaudit.js

Github repo: https://github.com/Dheeraj-pilakkat/UiAudit.js

Currently v2.2.1. Would genuinely value feedback from people running it against real production codebases — especially where it false-positives or misses something obvious. If you try it, please drop your feedback so I know what to work on next

Hey everyone! 👋

Like many of you, I have a terrible habit of starting side projects, cloning repos, and then forgetting about them. Before I realized it, my hard drive was completely choked by dozens of massive node_modules folders scattered everywhere.

I used tools like npkill in the past, but since I also dabble in other languages, I needed something that could clean up everything at once (like Rust's target or Python's .venv).

So, I built dev-sweeper.

It's a blazingly fast, cross-platform Terminal UI built with Node.js, TypeScript, and React (via Ink). It scans your machine, finds heavy dependency folders, and lets you interactively delete them to instantly reclaim disk space.

Why is it fast? ⚡ Under the hood, it uses an asynchronous crawler (fdir) that smartly ignores hidden directories like .git and stops recursing the moment it finds a target folder (because there's no point searching inside a node_modules folder if you're going to delete the whole thing anyway).

You can try it right now without installing anything globally:

npx dev-sweeper

(Or pass a specific path: npx dev-sweeper ~/Projects*)*

Out of the box it finds:

• node_modules (Node.js)
• target (Rust/Cargo)
• venv / .venv (Python)
• vendor (PHP)

🐙 GitHub Repo: https://github.com/dvigo/dev-sweeper-node
📦 NPM: https://www.npmjs.com/package/dev-sweeper

I'd love to hear your feedback or feature requests! Hope it helps you reclaim some gigabytes today! 🚀

I kept switching to a browser tab just to ask a quick "how do I undo this git commit" — so I built tlme, a small terminal tool that streams the answer right where I'm already working.

$ tlme how do I undo the last git commit but keep changes
git reset --soft HEAD~1

What it does:

• Multi-provider — Claude, OpenAI, Grok, Google AI Studio, and OpenRouter. Switch per-call with -p, or set a default.
• Streamed answers — text appears as it's generated (hand-parsed SSE), not one big blob at the end.
• Zero npm dependencies — just native fetch + node:*. No axios, commander, chalk, or dotenv. Single index.js.
• Pipe-friendly — cat error.log | tlme why is this failing or git diff | tlme write a commit message.
• Nice setup UI — an OpenCode-style full-screen picker: arrow keys, type-to-filter, masked key entry. Falls back to plain prompts on dumb terminals.

Install (needs Node 18+):

npm install -g tlme-cli
tlme --setup

Keys are stored in ~/.tlme/config.json (chmod 600), or read from env vars like ANTHROPIC_API_KEY / OPENAI_API_KEY first.

npm: https://www.npmjs.com/package/tlme-cli

Ever inherited a codebase and spent the first week just trying to figure out what depends on what?

I've been there too many times. Grepping for imports, maintaining manual architecture docs that go stale within a week, drawing boxes in Excalidraw that don't match reality. So I built something to fix it.

codebase-vis parses your project using tree-sitter, real AST grammars, not regex and produces an interactive dependency graph as a single self-contained HTML file. You open it in a browser, and you can pan, zoom, search, click nodes to inspect, and filter by module.

It works for JS, TS, Python, C/C++, HTML, and CSS.

Some features that might be useful:

-query <file> — shows what a file imports and what imports it (terminal, no browser needed)
-path <a> <b> — shortest dependency chain between any two files (bidirectional BFS)
-explain — clusters your codebase with Louvain community detection, then summarizes each cluster via an LLM (you provide a Groq key, everything else is local)
-Incremental caching— re-parsing is near-instant after the first run

Everything runs locally ,no data leaves your machine except the optional `explain` feature.

Full disclosure: I built this. I needed it for my own projects, and I kept adding to it over the past few weeks. Would love feedback or ideas from anyone who's dealt with the same problem.
I cant dump everything in here go check yourself and do let me know what you think.

GitHub: (https://github.com/Arham-Qureshi/codebase-vis) (ISC, open source)

A while ago I started digging into IoC/DI containers mostly as a learning exercise.

I wanted to understand how existing solutions work under the hood, so I spent time reading source code, trying different designs, and comparing tradeoffs around decorators, metadata, scopes, and dependency resolution.

That eventually turned into a small project of its own: Injectus.

The goal wasn’t to build a replacement for every DI library out there. I was mostly curious what a DI library would look like if it leaned on modern Node.js features and used the functional inject() style Angular popularized, while staying focused on backend apps.

Some of the design choices:

• Zero dependencies
• Native ES Module
• No decorators or reflect-metadata
• Synchronous resolution only
• Singleton, Scoped, and Transient lifetimes
• Request-scoped child injectors
• Captive dependency detection
• Resource disposal through modern Node.js APIs (Symbol.asyncDispose)

Example:

class Database {
  url = inject(DB_URL);
}

class UserService {
  db = inject(Database);
}

Building it taught me a lot about dependency graphs, lifecycle management, circular dependency detection, disposal semantics, and API design in general.

I’m mostly curious about the functional injection approach versus constructor injection. If you use DI in Node.js, what pain points have you run into with the libraries you’re using today?

If you depend on jscrambler, it's worth checking your lockfiles, build logs, and CI history. The official npm package was compromised in v8.14.0, where a malicious preinstall script executed a Rust-based infostealer during npm install. Since the payload ran at install time, simply installing the affected version was enough to compromise a developer workstation or CI runner. According to the vendor, v8.22.0 is the first clean release. If v8.14.0 was installed anywhere in your environment, it's recommended to upgrade, audit the affected systems, and rotate any credentials that may have been exposed

I jump between node yarn, npm, pnpm projects, and every repo has a different way to run the same things: npm run dev, pnpmtest, yarn dev…

So I made samecmd. It detects the project you’re in and gives you the same commands everywhere (dev, build, test, lint, fmt, etc.). Basically resolving a daily friction of mine in the last few weeks.

Curious if anyone else has this problem, or if it’s just me 😄

https://github.com/behnamazimi/samecmd

Why another one? The existing wrappers I found were unmaintained, Vue 2 era, or shipped with dependencies I didn't want. This one keeps it minimal:

- zero runtime dependencies (Vue is a peer dep, that's it)

- full TypeScript types

- useRecaptcha composable with reactive token and isVerified

- v-model works if you prefer that

- multiple widgets per page, theming, custom language

- ready-made Laravel + Inertia.js integration examples, including server-side verification

- 100% statement coverage, audited deps in CI, npm provenance

Install: npm install recaptcha-vue

npm: https://www.npmjs.com/package/recaptcha-vue

GitHub: https://github.com/Souhailmakni/recaptcha-vue

Feedback welcome, especially from anyone doing Inertia forms. And if it's useful to you, a GitHub star goes a long way for a brand new package.

I'm the maintainer of OpenHarness, an MIT-licensed TypeScript SDK built on Vercel AI SDK. I split it into @openharness/core plus small React/Vue and provider packages because I didn't want UI dependencies or experimental auth code in the runtime package.

Core contains the agent loop, session state, middleware, MCP/skills support, and filesystem/shell tools. The awkward question is where integrations belong. Keeping everything separate makes core lighter, but users have to discover and version several packages just to build one agent UI.

npm: https://www.npmjs.com/package/@openharness/core repo: https://github.com/MaxGfeller/open-harness

For people maintaining TypeScript package families: would you keep these separate, or fold the stable React/Vue bindings into core and leave only providers on their own? I'm more interested in packaging and API feedback than a general project review.

Hey everyone,

React performance optimization can be a massive headache. Profiling components, chasing down accidental re-renders, and hunting for memory leaks usually requires opening up DevTools and digging through deep flame graphs.

I wanted something faster and more automated—closer to how ESLint catches syntax bugs or SonarQube catches code smell, but explicitly focused on React performance bottlenecks.

So, I built @prism-guard/cli. It’s completely open-source, has zero dependencies, and weighs in at just 5kb.

What does it actually do?

Think of it as a static and runtime analysis hybrid for your component architecture. It scans your React project to answer:

Where are your most expensive component trees?

Which hooks are triggering unnecessary updates?

Are there unoptimized asset pipelines slowing down your initial render?

Instead of massive HTML reports, it gives you actionable, line-by-line feedback right in your terminal.

Quick Start

You don't even need to install it permanently. You can audit your project right now by running:

npx @prism-guard/cli analyze

Why I made it 5kb

I'm incredibly tired of "lightweight" dev tools that pull in 40MB of ⁠node_modules⁠. I wrote this with zero external dependencies so it runs instantly in your local workflow or as a quick check in your CI/CD pipeline without bloating your build times.

Source Code & Contributing

The project is entirely open source. I’m really looking for feedback from the community:

Are the terminal error messages clear enough?

What specific React performance metrics do you wish it tracked?

Check out the repo here:

https://www.npmjs.com/package/@prism-guard/cli

Hey everyone!

I'm working on building an open-source NPM package that solves a real problem for developers, not just another package that already has 20 alternatives.

Instead of guessing what people need, I thought I'd ask the community directly.

If you could have any NPM package that would make your development workflow easier, what would it do?

It could be:

• A utility that saves you time.
• A better wrapper around an existing API.
• A debugging or testing tool.
• A CLI that automates something annoying.
• A package for React, Node.js, TypeScript, Express, Next.js, or any other ecosystem.
• Or just something you've always thought, "Someone should build this."

I'm looking for ideas that solve actual developer pain points, whether they're small annoyances or bigger workflow problems.

If I end up building your idea, I'll make it open source and give you a shout-out for the suggestion.

Looking forward to hearing your ideas!

I have just published my first npm package and i wanted to share it with you.

It is a modular and customizable properties panel, similar to the one Figma or Unity uses, made for React. it is completely open source and can be installed via npm.

Features:
- Multi-object editing (mixed values handling)
- Customizable layout (reorderable blocks, similar to Unity components)
- Optional no-schema data visualization (for any json object)
- Color & Vectors support.
- Arrays visualization.
- History Ready
- Fully customizable styles

You can play with the playgrounds in this website: reactpropertiespanel.vercel.app

If you like it, I'd really appreciate your ⭐ on GitHub.

Feedback is welcome!