标签：#npm

vlt, created by the original npm team, has launched version 1.0 as a drop-in replacement for npm. It features phased installations to prevent automatic script execution, a queryable dependency graph with over 60 selectors, and hosted registries that block malicious packages. The tool aims to enhance security and streamline the JavaScript development process. By Daniel Curtis

🇪🇸 Leer este post en Español I spent months watching my agent re-solve the exact same problems, over and over, because I never sat down and wrote them up once so anyone else could reuse them. That's the kind of technical debt nobody ever puts on a roadmap. So I published alpha-skills : eight installable Agent Skills and my first MCP server on npm . Where the published skills live The installable catalog lives in skills/ , split into three categories: external/ for third-party APIs, local/ for homelab and workflows, and general/ for cross-project utilities. All three are public: one skill in external/ , one in local/ , and six in general/ . local/ describes the use case. skills/ ├── external/ │ └── nextdns-api/SKILL.md ├── local/ │ └── progressive-search/SKILL.md └── general/ ├── agent-context-generator/SKILL.md ├── nestjs-iam-patterns/SKILL.md ├── nestjs-advanced-patterns/SKILL.md ├── nestjs-graphql/SKILL.md ├── tuning-claude-code/SKILL.md └── obsidian-second-brain/SKILL.md <DIAGRAM 02: 02-public-skills-structure-en.png> The eight skills Three categories: external/ for third-party services, local/ for homelab infrastructure and personal workflows, general/ for cross-cutting utilities that don't depend on any one service. Skill Category Use it for nextdns-api external NextDNS API progressive-search local Code and documentation search agent-context-generator general Project context nestjs-iam-patterns general Authentication and permissions nestjs-advanced-patterns general NestJS internals and architecture nestjs-graphql general Code-first and schema-first GraphQL tuning-claude-code general Claude Code configuration obsidian-second-brain general Note organization and review Each command installs one skill. Run the command for the one you need. 1. nextdns-api A full reference for the NextDNS REST API: profiles, security/privacy/parental-control settings, denylist and allowlist management, analytics, query logs. This is the one the MCP server below is built directly agai

🇺🇸 Read this post in English Llevo meses haciendo que mi agente resuelva los mismos problemas una y otra vez porque nunca me tomé el tiempo de escribirlos una sola vez, bien, y dejar que otros los reusaran. Ese es exactamente el tipo de deuda técnica que nadie pone en un roadmap. Así que publiqué alpha-skills : ocho Agent Skills instalables y mi primer servidor MCP en npm . Dónde están las skills publicadas El catálogo instalable vive en skills/ , separado en tres categorías: external/ para APIs de terceros, local/ para homelab y flujos de trabajo, y general/ para utilidades transversales. Las tres son públicas: una skill en external/ , una en local/ y seis en general/ . local/ describe su ámbito de uso. skills/ ├── external/ │ └── nextdns-api/SKILL.md ├── local/ │ └── progressive-search/SKILL.md └── general/ ├── agent-context-generator/SKILL.md ├── nestjs-iam-patterns/SKILL.md ├── nestjs-advanced-patterns/SKILL.md ├── nestjs-graphql/SKILL.md ├── tuning-claude-code/SKILL.md └── obsidian-second-brain/SKILL.md Las ocho skills Tres categorías: external/ para servicios de terceros, local/ para infraestructura de homelab y workflows propios, general/ para utilidades transversales que no dependen de ningún servicio en particular. Skill Categoría Para qué sirve nextdns-api external API de NextDNS progressive-search local Búsqueda de código y documentación agent-context-generator general Contexto de proyecto nestjs-iam-patterns general Autenticación y permisos nestjs-advanced-patterns general Internals y arquitectura de NestJS nestjs-graphql general GraphQL code-first y schema-first tuning-claude-code general Configuración de Claude Code obsidian-second-brain general Organización y revisión de notas Cada comando instala una skill. Ejecuta el de la que necesites. 1. nextdns-api Referencia completa de la API REST de NextDNS: perfiles, seguridad/privacidad/control parental, listas de bloqueo y permitidas, analíticas, logs de consultas. Es la que respalda al MCP server que desc

When a checkout form receives a card number, the first useful question is often not whether the payment will be approved. It is whether the input is structurally plausible and which network rules should be shown to the user. The open-source credit-card-brand-detector package provides that small client-side or server-side building block. It detects 11 brands, removes spaces and hyphens, and applies a Luhn checksum. It has zero runtime dependencies and exposes CommonJS functions for validation and brand detection. This tutorial builds a minimal Node.js check, verifies the result with known test numbers, and explains what this kind of validation cannot tell you. TL;DR Install version 1.0.1 , call validateCreditCard when you need both a boolean result and a brand, and call detectBrand when you only need the network name. The package does not contact a payment processor, authorize a transaction, tokenize data, or prove that a card exists. Prerequisites You need: Node.js 12 or newer. The package declares >=12.0.0 in its metadata. npm. A terminal and a small JavaScript file. The package is released under the MIT license . The examples below target the published npm package version 1.0.1 , which is also the version I installed for this walkthrough. Install the package Create a directory for the example and install the pinned version: mkdir card-check-example cd card-check-example npm init -y npm install credit-card-brand-detector@1.0.1 Pinning the version makes the example reproducible. If you use a different version later, check its README and package metadata before copying the behavior into a production application. Build the smallest useful check Create check-card.js : const { validateCreditCard , detectBrand , getBrand , } = require ( ' credit-card-brand-detector ' ); const formattedVisa = ' 4532 0151-1283-0366 ' ; const mastercard = ' 5555555555554444 ' ; console . log ( validateCreditCard ( formattedVisa )); console . log ( detectBrand ( mastercard )); console . log

pnpm 12 has transitioned to a native Rust implementation, maintaining compatibility with pnpm 11 commands, flags, and formats. This update enhances startup and filesystem performance, particularly when using existing caches. Community feedback highlights the performance gains while noting some trade-offs in larger artifact sizes. By Daniel Curtis

The finding EventCatalog exposes a common monorepo failure mode: generated code may exist, its producer may be green, and the real downstream consumer can still fail. Its Langium language server generates AST, grammar, module, and syntax files; a sibling VS Code extension consumes that output alongside the workspace SDK and visualiser. The useful question is therefore not "did generation finish?" It is whether the repository can execute the complete consumer closure from declared dependency hydration through the package that needs the generated result. The contract boundary Ota models the generated output separately from the tasks that establish and consume it: artifacts : language-server-ast : kind : generated_source producer : language-server:generate paths : - packages/language-server/src/generated/ast.ts - packages/language-server/src/generated/grammar.ts - packages/language-server/src/generated/module.ts - packages/language-server/syntaxes/ec.tmLanguage.json - packages/vscode-extension/syntaxes/ec.tmLanguage.json inputs : - packages/language-server/src/ec.langium - packages/language-server/langium-config.json tasks : vscode-extension:build : depends_on : - language-server:generate - language-server:build - sdk:build - visualiser:build requires_artifacts : - language-server-ast The setup task owns typed, frozen-lockfile pnpm hydration with the language-server package filter. That removes bespoke install shell glue without pretending the dependency path is harmless: it reaches the package registry, so the selected closure is intentionally not routine agent-safe execution. Humans and CI can run the declared verification workflow; unattended agents cannot silently acquire that networked setup authority. What Ota had to learn This pressure case made two platform requirements concrete. Generated-source lineage had to remain visible at consumer admission and in execution evidence, rather than surfacing only after a build failure. And pnpm dependency hydration needed a

Published : August 27, 2026 Package : @bananacool467/ui-tools I want to clarify a security issue affecting earlier versions of @bananacool467/ui-tools . Versions 0.1.0-beta through 0.1.7-beta contained an unauthenticated WebSocket terminal endpoint. This allowed a client connecting to the endpoint to interact with a PTY running on the server. The issue has since been addressed. Affected versions The OSV advisory MAL-2026-13416 currently identifies these versions as affected: 0.1.0-beta 0.1.1-beta 0.1.2-beta 0.1.3-beta 0.1.4-beta 0.1.5-beta 0.1.6-beta 0.1.7-beta The advisory was generated from findings by Amazon Inspector and includes hashes identifying the affected package artifacts. Patched versions Do not use the affected versions 0.1.0-beta through 0.1.7-beta . Use 0.1.9-beta or newer. In 0.1.9-beta, I added authentication before the WebSocket upgrade is accepted. The 0.1.9-beta implementation checks the token before calling handleUpgrade() , so unauthenticated connections are rejected before the WebSocket is upgraded. In other words, knowing the WebSocket endpoint alone is no longer sufficient to establish a terminal session. What should I do? If your project uses an affected version, update it: npm install @bananacool467/ui-tools@latest Or explicitly: npm install @bananacool467/ui-tools@0.1.9-beta You can check your installed version with: npm ls @bananacool467/ui-tools If you're using a version from 0.1.0-beta through 0.1.7-beta , upgrade immediately . What happened? The terminal functionality is intentional. ui-tools is not intended to be a frontend-only component library; it contains various development/UI utilities, including an optional terminal interface. The problem with the earlier implementation was that the terminal WebSocket endpoint did not require authentication. This meant that a server using the terminal functionality could unintentionally expose a shell to anyone who could reach the endpoint. This was not acceptable, and authentication was added

MyAnimeList Module This module is neither affiliated with nor endorsed by MyAnimeList. All data returned by this module is provided by MyAnimeList. Version 1.0.5 Installation Install myanimelist-module with npm npm install myanimelist-module Usage/Examples const { MyAnimeList } = require ( ' myanimelist-module ' ) const mal = new MyAnimeList ({ client_id : `YOUR_MAL_CLIENT_ID` // Get it here: https://myanimelist.net/apiconfig }) async function test () { const response = await mal . getAnimeInfo ({ name : " Anime name " }) if ( response . error ) { console . error ( response . error ) } else { console . log ( response . datas ) } } test () All functions new MyAnimeList() Parameter Type Description client_id string Required . Your MAL Client ID getAnimeInfo() Parameter Type Description name string Required . fields [array] Optional. More information in the "Available fields" section. limit number Optional. Number of items in the response. (Maximum of 100) offset number Optional. Default : 0 nsfw boolean Optional. Default: false getAnimeInfoByURL() Parameter Type Description api_url string Required . You must use any valid MyAnimeList API link. It also works with older responses via response.datas.paging.next and response.datas.paging.previous . getSpecificAnimeInfo() Parameter Type Description name string Required . fields [array] Optional. More information in the "Available fields" section. nsfw boolean Optional. Default: false getAnimeInfoByID() Parameter Type Description id string Required . fields [array] Optional. More information in the "Available fields" section. nsfw boolean Optional. Default: false getAnimeRanking() Parameter Type Description type string Optional. More information in the "Available ranking types" section. fields [array] Optional. More information in the "Available fields" section. limit number Optional. Number of items in the response. (Maximum of 500) offset number Optional. Default : 0 nsfw boolean Optional. Default: false getSeasonalAnime(

npm has introduced staged publishing for Node.js, requiring maintainer approval before a version is installable. Versions are queued and must pass a two-factor authentication challenge for release. This feature aims to enhance security amid rising supply chain threats. It is available in npm CLI 11.15.0+ and Node 22.14.0+, alongside new configurable permission flags. By Daniel Curtis

GitHub malware advisories no longer stop at npm. Here's how we wired OpenSSF's malicious-packages data into the Advisory Database, and why we built the pipeline paranoid. The post How we took malware advisories beyond npm appeared first on The GitHub Blog .

Every (or at least a lot of) project seems to have code like this somewhere: if (user.subscriptionEndsAt < new Date()) { // ... } There's nothing wrong with it... until you have to test it. Then you end up freezing time, mocking Date, enabling fake timers, remembering to restore them afterwards, and hoping another test didn't leave the clock in a weird state. While Jest's and Vitest's fake timers are great tools, they always felt like they were solving the problem from the outside by patching global APIs. I wanted to try something different. Time is a dependency When you think about it, the current time isn't much different from a database or an HTTP client. Your business logic depends on it, but it doesn't have to know where it comes from. Instead of writing this: const now = new Date(); what if we wrote this? const now = timeProvider.now(); Suddenly, testing becomes boring—in the best possible way. You don't need global fake timers anymore. You just pass a different implementation. .NET had the same idea While looking into this, I discovered that .NET 8 introduced a TimeProvider abstraction. Seeing that was reassuring. It suggested I wasn't the only one who felt that "current time" deserved to be treated as a real dependency. I didn't want to copy the .NET API, but I did like the underlying idea. So I started building a version that felt natural in the TypeScript ecosystem. It grew beyond a clock At first I only wanted to replace new Date(). Then I realized the same issue exists with setTimeout, setInterval, performance measurements, and a few other APIs. They all depend on the environment's notion of time. So the library slowly became an abstraction around all of those instead of just "what time is it?". Is this actually useful? That's the part I'm still curious about. In the projects I've worked on, I prefer injecting time over patching globals during tests. Maybe other teams have reached the same conclusion. Maybe everyone is perfectly happy with fake timers an

Hi everyone! I made an SSR web framework on NPM named Authtics Host (or HostJS ) About Based on tests, it starts the server in under 1 second. For a user to see the page, it takes 1-4 seconds. It also has a Developer Panel , which has controls to control the website (e.g., Restart, Shutdown and Pause Users) with DAT ( Developer Access Token ) authorization for the Developer Panel. The framework's Developer Panel has console and network tabs, where devs can see: what the page is receiving, sending or what logs it's placing in the console. Better than importing a package and setting it up on mobile. 3 Reasons why I made this Most frameworks start in 2-5+ seconds There isn't any console or network tab for mobile If there's a developer panel in another framework, it might not be mobile-friendly Package The NPM package is at: @bananacool467/authtics-host Code snippet For starting the server: (Backend script) import { App } from " @bananacool467/authtics-host " ; const app = new App (); (Bash script) node --experimental-strip-types index.ts How I got it to start in under 1 second What I did was make it do fast stuff, when it starts, it: Loads modules (node:fs, node:http, jiti) Then it loads the jiti config file Then it starts the server with the config

tinyNpm is a vs code extension that helps protect you from supply chain attacks, stale packages, and bloated code! I had been using package.json version keepers for quite some time but after the big supply chain attack i thought they would be the perfect place to add in some security. The idea is just to provide the latest package number x days old. This will help prevent most of the danger in supply in chain attacks. It will also remove the ^ if you have it so you can better control what version of a package your application is using. To be more security focused it gives general hints in the hover menu to help keep an eye on the packages you have installed. These hints include warnings for staleness, high dependency count, and number of downloads. Since all of this is something you can get through the npm api, I called it tinyNpm You can download it on the marketplace

Explore the changes we've shipped across npm and GitHub Actions over the past few months to disrupt supply chain attack techniques and limit their impact. The post Disrupting supply chain attacks on npm and GitHub Actions appeared first on The GitHub Blog .

The Problem If you’ve built a decent-sized NestJS application, you know the authorization dance. You start with basic Roles, then suddenly you need fine-grained permissions, then maybe some attribute-based access control (ABAC). Before you know it, your controllers are cluttered with @UseGuards(RolesGuard) , and your RolesGuard itself is a massive switch statement checking for every possible permission string. It's repetitive, hard to test, and honestly, a bit boring to maintain. The Solution: nestjs-permissions I got tired of reinventing this logic for every project, so I built nestjs-permissions . The goal was simple: Declarative, type-safe authorization that stays out of your way while keeping your code clean. Why use it? Decorator-Driven: No more complex metadata injection. Just wrap your routes. Type-Safe: Keep your permissions consistent across your frontend and backend. Framework-Native: It plays nicely with the standard NestJS Request lifecycle. Quick Start Getting started takes about 5 minutes. 1. Install it: npm install nestjs - permissions 2. Configure your module: import { Module } from ' @nestjs/common ' ; import { PermissionsModule } from ' nestjs-permissions ' ; @ Module ({ imports : [ PermissionsModule . register ({ // Your config here }) ], }) export class AppModule {} 3. Protect your routes: import { Get , Controller } from ' @nestjs/common ' ; import { RequirePermissions } from ' nestjs-permissions ' ; @ Controller ( ' dashboard ' ) export class DashboardController { @ Get ( ' admin ' ) @ RequirePermissions ( ' admin.read ' ) async getDashboard () { return ' Secret Admin Data ' ; } } What’s Under the Hood? Under the hood, nestjs-permissions leverages the NestJS Reflector to cleanly extract metadata from your route handlers. It automatically taps into the execution context, checking the incoming request against the required permissions without forcing you to write boilerplate guards for every module. When NOT to use it If you need hyper-complex, at

I run EstimatorSuite.com — we review construction estimating software for US contractors (HVAC, electrical, plumbing, roofing, landscaping). We just open-sourced our entire calculator suite: 42 construction calculators under MIT license. React + TypeScript + Tailwind. 🔗 Repo 🔗 Live Demo 🔗 npm What's included: • 36 material calculators (concrete volume, roofing squares, drywall, paint, flooring, etc.) • 6 trade estimators (HVAC load, electrical conduit fill, plumbing pipe sizing) Two entry points: → React components — drop into any project → Pure calculation functions — zero UI dependency, works in Node.js, Vite, Next.js, anywhere Why we built this: Construction software is expensive. Contractors told us they needed free tools that actually work — not ad-filled spreadsheets. So we built them, and we open-sourced them. Full story →

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 speci

We have all been there. You are staring at your screen late at night, trying to optimize a bundle size, or debugging an enterprise pipeline that has been failing for three hours straight. The mainstream development community constantly tells us to only install packages that are high performance, audited for security, and strictly necessary for production. But where is the fun in a perfectly clean node_modules folder? Sometimes, the ultimate way to level up your engineering workflow is to inject some absolute chaos into your dependencies. Why spend hours writing robust logic when you can install a library that brings pure irony to your terminal? Let us dive into ten packages that might look completely useless on the surface but are actually the most important modules you will ever encounter in your developer journey. 1. emoji-poop This NPM package lets you use the poop emoji in your output. The emoji is well required in most of the websites as the real fun begins when the site crashes and you can use this poop emoji to showcase the errors with an emoji. This will help the clients get a bit calm after seeing the emoji and the errors. Think about it from a psychological perspective: traditional red stack traces cause immediate client panic, but a well-placed graphical poop emoji introduces a masterclass in modern error mitigation. javascript // npm i emoji-poop const emoji = require('emoji-poop'); console.log(emoji) // 💩 2. thanos-js Who doesn't love Marvel, and Thanos being the strongest villain in the MCU? This package lets you delete files in Thanos fashion. Once you install and run it, it deletes 50% of your files, reducing your stress and giving you less codebase to work with. Yes, it deletes the files for those who are confused about what this package does. It uses fs.unlinkSync to delete the files. Deleting random files from .git would be absolutely evil, and Thanos would love to do it. Exactly half of the files are deleted. Each file is given a chance at random

Imagine if there were a way for us to somehow ship a full-stack package that you could plug into your...

Your CI catches the npm vulnerability. Your developer is already three branches away and one standup behind. The package is installed, the lockfile regenerated, the import wired into a service, and the human who made that decision did it on a Tuesday afternoon with a tab open to Stack Overflow. Now the scanner is yelling. From the terminal, that is not security. That is grief counseling. That is the frame Sonu Kapoor lays out in a DevOps.com essay this week, and the engineering bones of it are correct. A scanner is not a gate. It is a status check. Kapoor's argument is about feedback loops. A developer installs, codes, commits, pushes. Only then does CI run. By the time the finding surfaces, the decision to add the package, and the context for why, has evaporated. So has the lockfile churn that caused it. What started as "is this package safe?" becomes "fix this in a different sprint." The scanner did its job. The fix is now a project. He backs it with a small case study from the NestJS repo: a scan of package-lock.json returned 1,626 resolved packages and 25 vulnerabilities. Of those, 12 were directly fixable. Thirteen were transitive, buried in upstream graphs, waiting on someone else's release. In a pipeline-first workflow, every dependency hop is a separate commit and a separate run. (Multiply by the number of services your team owns. Then by your runner-minutes budget. Send me the bill.) The arithmetic gets ugly quickly. A single lockfile with more than fifteen hundred resolved packages is not exotic for a working Node app, it is the default. The chance that the first time anyone looks at that graph is during a pipeline run, after the merge intent is already in the reviewer's queue, is the structural bug. Where the essay is right, and where it gets too tidy Concede the obvious. CI is not the problem. CI is fine. It runs uniformly, it cannot be skipped, and it is the right place to fail a build when an OSV record drops mid-week against a dependency that was clea