Did you find or create something cool this week in javascript?

Show us here!

- Declarative API

- Flex Layout & CSS Grid

- Multi-Page PDF — automatic page breaking, repeating headers & footers, margins

- Rich Text — spans, justification, tab stops, tab leaders, text orientation (0°/90°/180°/270°)

- Bidirectional text — RTL support for Arabic, Hebrew, and mixed LTR/RTL paragraphs

- Syntax Highlighting — via `sone/shiki` (Shiki integration)

- Lists, Tables, Photos, SVG Paths, QR Codes

- Squircle, ClipGroup

- Custom font loading — any language or script

- Output as SVG, PDF, PNG, JPG, WebP

- Fully Typed

- Metadata API — access per-node layout, text segment bboxes, and `.tag()` labels

- YOLO / COCO Dataset Export — generate bounding-box datasets for document layout analysis

- All features from [skia-canvas](https://skia-canvas.org/)

The idea is to have a single, clean, secure, and well-maintained registry that starts with **complete NPM** and then expands to PyPI, Cargo, Maven, Go, Docker/OCI, etc. Clean architecture, pluggable storage, modern authentication (OIDC/SSO/2FA), and built to last 10–20 years.

Today is Day 2, right at the beginning.

I'd like your honest feedback.

just dropped v0.8.0 of UQL, with one of the most requested features: Decorator-Free Entity Definitions. So not everyone wants (or can) use experimentalDecorators in their tsconfig.json. This is common in certain edge runtimes, specific build pipelines, or simply for developers who prefer a more functional or imperative style.

With the new defineEntity API, you can now register your database entities entirely through code. This new approach is 100% compatible with envs where decorators are disabled or unsupported.

Check out the new syntax:

import { defineEntity } from 'uql-orm';

// No decorators, no tsconfig magic required!
class User {}

defineEntity(User, {
  name: 'users',
  fields: {
    id: { type: 'uuid', isId: true },
    name: { type: String },
    email: { type: String },
  },
  indexes: [
    { columns: ['name'] },
    { columns: ['email'], unique: true },
  ],
});

Over the past few weeks, I've been building a platform where users can connect their social accounts and automate content posting.

So I built Chronex, an open-source alternative to paid content schedulers.

Tech Stack

• Web/Platform: Next.js, tRPC, Drizzle, Better Auth
• Media Storage: Backblaze B2
• Scheduling & Posting: Cloudflare Workers & Queues

GitHub

Live

I've been building a scanner that monitors new npm packages and it flagged something I haven't seen before.

A package called "openmatrix" uses a postinstall hook to copy 13 markdown files into ~/.claude/commands/om/. These files are Claude Code "skills" that load automatically in every session.

One of them contains instructions that tell Claude to auto-approve all bash commands and file operations without asking the user. The files are marked as always_load: true with priority: critical, so they activate in every session.

npm uninstall doesn't clean them up. There's no preuninstall script. The files stay in your home directory until you manually delete them.

The package does have real functionality (task orchestration for AI coding), so I'm not saying it's malware. But the undisclosed permission bypass and the lack of cleanup seemed worth sharing.

If you installed it:

rm -rf ~/.claude/commands/om/

rm -rf ~/.config/opencode/commands/om/

I wrote up a full report with the technical details if anyone wants to check it out. Happy to drop the link in the comments.

Yesterday I posted about an npm package injecting prompt injection files into Claude Code. I kept the scanner running overnight and it found a lot more.

21 malicious packages across 11 campaigns in ~2000 recent npm changes. The four that stood out:

1. makecoder hijacks your Claude Code config on npm install and routes all API calls through their server. Every conversation with Claude, including your code and prompts, passes through makecoder.com. Man-in-the-middle at the application layer.

2. skillvault fetches encrypted payloads from a remote API and installs them as Claude Code skills. The payloads can't be inspected and the server can change them anytime without an npm update.

3. keystonewm and tsunami-code are RATs disguised as AI coding assistant CLIs. Polished terminal UI, but everything goes through an attacker's ngrok tunnel. You think you're using an AI tool but the attacker controls both sides.

4. Six fake Strapi plugins by the same attacker, all published within hours. The postinstall exploits Redis to write files across the host, opens a reverse shell, and reads raw disk with dd to steal SSH keys and crypto wallets.

Also found a dependency confusion attack targeting Verisign, a credential stealer behind fake React components, and an obfuscated package under ByteDance's u/volcengine scope.

None were flagged by any public scanner at time of discovery.

Full reports on my site, link in the comments.

For UI flows that are not strictly linear (onboarding, checkouts, eligibility flows, etc.), I often see logic distributed across multiple places:

• conditionals in components

• flags in state

• effects triggering navigation

• validation logic duplicated per step

State machines provide a formal model, but in practice they can feel heavy for teams that mainly need to describe a flow graph.

I’m curious what abstractions people are using in real projects.

For example:

• multi-path onboarding

• flows with loops (retry / corrections)

• resumable progress

• feature-dependent steps

• flows spanning multiple screens

Are amost teams:

• relying on router logic?

• building custom hooks?

• using state machines?

• something else?

Interested in hearing what has worked well in production.

i've been building an embeddable chat widget that gets dropped on customer sites via a script tag. spent a while thinking through the framework choice and wanted to share what i landed on since most widget guides default to react without questioning it.

the core constraint with embeddable widgets is you're a guest on someone else's page. if your script makes their site slower they'll remove it before checking if it works. so bundle size isn't a nice-to-have, it's the whole game.

the loader script that customers paste on their site is about 2KB. it creates an iframe and loads the full widget inside it. the widget JS is around 109KB total which includes preact, markdown rendering, html sanitization, and the entire chat UI. with react + react-dom you're starting at 40-50KB gzipped before writing a single line of your own code. preact core is about 3KB.

i went with iframe isolation instead of shadow DOM. i know shadow DOM is the "correct" answer for widget encapsulation but iframes give you true isolation without the edge cases. host page CSS can't touch you, your CSS can't leak out, and you don't have to fight z-index wars or deal with styled-components injecting styles into document.head instead of your shadow root. the tradeoff is postMessage for communication but for a chat widget that's fine.

the build setup is dead simple. preact/preset-vite handles the jsx transform, the loader builds separately as an IIFE into a single file, and the main widget builds normally into the iframe's assets. two vite configs, one build command.

one thing that surprised me - the preact compat layer barely costs anything. i use a couple of react-ecosystem libraries and the compat shim adds maybe 2KB. so you're not giving up the react ecosystem, you're just shipping less code for the same result.

some things i'd think about if you're making this decision. if your widget is simple (a button, a badge, a small form) skip the framework entirely. vanilla JS or lit will do. i needed preact because a chat interface has enough state and interactivity that managing it without a framework would've been painful.

if your widget needs to share state with a react host app, preact in an iframe won't work. you need to be in the same DOM tree. but if you're building a standalone embed that lives on third party sites, isolation matters more than integration.

the postMessage layer hasn't gotten complex so far but i only have a few message types (resize, theme detection, error reporting). i could see it getting messy if the widget needed deep interaction with the host page.

anyone else shipping embeddable widgets? curious what stack you landed on and whether shadow DOM or iframe worked better.

Built this to stop manually wiring mkcert into every project. One command
handles detection, cert generation, and config injection for:

Next.js, Vite, Astro, SvelteKit, Nuxt, Remix, Express, Fastify, NestJS

Also includes sync for teammates and doctor for diagnostics.

npm: https://www.npmjs.com/package/trustlocal

Curious if this solves a problem you've had too.

Two versions of axios were published today through what appears to be a compromised maintainer account. No GitHub tag exists for either version. SLSA provenance attestations present in 1.14.0 are completely absent. Publisher email switched from the CI-linked address to a Proton Mail account( classic account takeover signal).

If your project floats on ^1.14.0 or ^0.30.0 you've likely already pulled this.

IoCs, payload analysis and full breakdown is in the blog.

I'm excited to introduce Zerobox, a cross-platform, single binary process sandboxing CLI written in Rust. It uses the sandboxing crates from the OpenAI Codex repo and adds additional functionalities like secret injection, TypeScript SDK, etc.

Zerobox follows the same sandboxing policy as Deno which is deny by default. The only operation that the command can run is reading files, all writes and network I/O are blocked by default. No VMs, no Docker, no remote servers.

Want to block reads to /etc?

$ zerobox --deny-read=/etc -- cat /etc/passwd
cat: /etc/passwd: Operation not permitted

Or with the TypeScript SDK:

import { Sandbox } from "zerobox";
const sandbox = Sandbox.create({
  denyRead: ["/etc"]
});
await sandbox.sh`cat /etc/passwd`.output();

How it works:

Zerobox wraps any commands/programs, runs an MITM proxy and uses the native sandboxing solutions on each operating system (e.g BubbleWrap on Linux) to run the given process in a sandbox. The MITM proxy has two jobs: blocking network calls and injecting credentials at the network level.

Think of it this way, I want to inject "Bearer OPENAI_API_KEY" but I don't want my sandboxed command to know about it, Zerobox does that by replacing "OPENAI_API_KEY" with a placeholder, then replaces it when the actual outbound network call is made, see this example:

$ zerobox --secret OPENAI_API_KEY=$OPENAI_API_KEY --secret-host OPENAI_API_KEY=api.openai.com -- bun agent.ts

Or with the TypeScript SDK:

import { Sandbox } from "zerobox";

const sandbox = Sandbox.create({
  secrets: {
    OPENAI_API_KEY: {
      value: process.env.OPENAI_API_KEY,
      hosts: ["api.openai.com"],
    }
  },
});

await sandbox.sh`node agent.js`.text();

Zerobox is different than other sandboxing solutions in the sense that it would allow you to easily sandbox any commands locally and it works the same on all platforms. I've been exploring different sandboxing solutions, including Firecracker VMs locally, and this is the closest I was able to get when it comes to sandboxing commands locally.

I'd love to hear your feedback, especially if you are running AI Agents (e.g. OpenClaw), MCPs, AI Tools locally.

Hey everyone,

I’m looking for a good lightweight IDE/editor for working with JavaScript, TypeScript, React, and React Native.

Right now I feel like my current setup is a bit heavy/slow, so I’m hoping to find something that’s:

• Fast and responsive (low resource usage)
• Good TypeScript support
• Solid React/React Native tooling (linting, autocomplete, debugging, etc.)
• Easy to customize (extensions/plugins are a plus)

I don’t necessarily need a full-blown IDE—open to editors too as long as the dev experience is smooth.

What are you all using, and what would you recommend?

Thanks!

Last night I've just released my first NestJS library ever to handle complex state management logic called NestflowJS.

NestflowJS is a decorator-based state machine library for NestJS. Acting as AWS Step Functions alternative but no cloud vendor-lock: define workflows, handle events, and let the orchestrator drive state transitions automatically.

Features:

1. Tech-stack agnostic: choose your storage, schema validation by extendable builtin class.

2. No extra library state: only care about your business state and its transition.

3. Flexible infra: zero runtime dependencies, this can run in any architecture style you can think of thanks to customizable adapter system:

• Want a strong state machine with no infra overhead? Deploy using Lambda Durable function with prebuilt adapter DurableLambdaEventHandler.

• Want a high-volume data processing system with full customization of message delivery configs? Create your own Kafka adapter. (Prebuilt adapter coming soon).

-.....A lot more you can think of.

Code example:

```typescript import { Workflow, OnEvent, Entity, Payload } from 'nestflow-js/core';

@Workflow({ name: 'OrderWorkflow', states: { finals: ['delivered', 'cancelled'], idles: ['pending_payment'], failed: 'cancelled', }, transitions: [ { event: 'PAYMENT_RECEIVED', from: ['pending_payment'], to: 'processing' }, { event: 'SHIP_ORDER', from: ['processing'], to: 'shipped' }, { event: 'CONFIRM_DELIVERY', from: ['shipped'], to: 'delivered' }, { event: 'CANCEL', from: ['pending_payment', 'processing'], to: 'cancelled' }, ], entityService: 'entity.order', }) export class OrderWorkflow { @OnEvent('PAYMENT_RECEIVED') async onPayment(@Entity() order, @Payload() payload) { order.paidAt = new Date(); return order; } } ```

Give me a star if you find this helpful!

After the Anthropic/Claude Code .map file leak and the axios supply chain attack last week, I built acrionix-shield — a single CLI that scans for leaked

secrets, compromised packages, Docker misconfigs, and git history secrets.

Supports: JavaScript, Python, Java, C#, Ruby, Go, Docker

9 scanners. 56 tests. Zero dependencies.

npx acrionix-shield check

GitHub: https://github.com/andrei-gogo/acrionix-shield

Would love feedback from the community.

Saw a case today where a .map file in a published npm package ended up exposing the original source because it included embedded sources (sourcesContent).

It didn’t look like a breach, just a build artifact making it into production, which makes it more interesting from a JS tooling perspective.

In most setups, this comes down to how bundlers are configured and whether final build outputs are actually inspected before publishing. Since npm packages ship whatever ends up in the output (unless explicitly excluded), it’s easy for something like this to slip through.

Curious how people approach this in practice, especially in production builds and published packages.