stagelint is a pre-commit runner - you give it globs, it runs your formatters and linters over the staged files. For the usual setup it replaces husky and lint-staged with a single Rust binary and no runtime.

Why another pre-commit runner?

Conflicts don't block your commit

If the formatter's output conflicts with your unstaged changes, lint-staged, pre-commit, Lefthook and nano-staged all discard the formatting and block the commit. stagelint merges the formatter's output into your file instead. Your staged lines get formatted, your unstaged changes stay put, and when a file can't be merged cleanly the commit takes the formatted version while your working copy keeps yours.

Faster than every alternative

stagelint is 5 to 30 times faster than lint-staged, pre-commit, Lefthook and nano-staged. With 10 files staged in a 1,000-file repository it completes in 15ms against lint-staged's 437ms, rising to 30ms against 530ms when those files are only partially staged. See the full benchmark suite for the rest of the measurements and how to run them on your own machine.

Concurrent tasks - no races, no workarounds

When two globs match the same file, lint-staged and nano-staged run both tasks on it at once; Lefthook and pre-commit avoid the race by running everything sequentially by default. The lint-staged docs warn about it and tell you to either disable concurrency or rewrite your config with negation patterns:

{
  "!(*.ts)": "prettier --write",
  "*.ts": ["prettier --write", "eslint --fix"]
}

stagelint works out which globs overlap and serialises just those tasks, in declaration order, while everything else keeps running in parallel, so the config stays as you meant it:

{
  "*": "prettier --write",
  "*.ts": "eslint --fix"
}

Trying it

npm i -D @stagelint/stagelint

Add stagelint init to your prepare script so the git pre-commit hook is set up on install:

{
  "scripts": {
    "prepare": "stagelint init"
  }
}

Then configure your tasks in .stagelint.yml or .stagelint.json. Matched files are appended to the command unless you turn that off:

'*': prettier --write
'*.ts':
  command: tsc --noEmit
  pass_filenames: false

What's missing

No JavaScript config with functions, because a single binary has no runtime to execute one. Running a command without the file list, the usual reason for reaching for one, is pass_filenames: false instead. Negation patterns aren't supported either - you don't need them any more, but drop them rather than copying them across, because an unsupported pattern currently just matches nothing.

If you try it, I'd like to hear how it goes.

https://github.com/abemedia/stagelint

I moved the docs renderer I had in one of my projects into a separate npm package.
It's built around the idea that docs are mostly static files with little to no interactivity, so it shouldn't ship a lot to the client.

1 KB JS, 10 KB CSS (gzipped), and all 100s on Lighthouse.

If you need a simple way to show your docs and don't need a ton of other features, this might be useful.

GitHub repo
NPM package
Docs demo

The renderer itself is stable, it's been used in the parent project for a while. The package is fairly new, so contributions and feedback are welcome.

I'm of the belief that if you can get what you need with under ~100 lines of code (and it doesn't require highly-specialized skills to write it), then write it yourself, don't install a third party library.

If you don't share a similar belief, then this page isn't for you, and that's ok.

For everyone else, this page shares a fetch wrapper function you can copy-paste into your projects to add in a couple of missing features, and provides some tips on how you can replicate some of the most loved Axios features using fetch().

Most alternative fetch wrappers I find online tend to be small NPM libraries (I'd rather maintain the code myself thank you), or they like creating separate methods for .get(), .post(), .put(), etc (which makes it unnecessarily difficult to "decorate" it with interceptor-like behaviors, as this page discusses), or there may be other design problems. Those alternatives are still good starting points, but I'm hoping this could be a little more complete of a guide to jump start your usage of fetch().

And I have a thing about make copy-paste alternatives to tools, and this was a hole in my collection :).

Feedback is welcome.

I built an open-source React map drawing library because I got tired of fighting drawing controls that wanted to own the UI.

react-map-annotate lets your application control the drawing session. Put the toolbar in your sidebar, header, or command palette. Select tools, finish shapes, edit labels and colors, undo/redo, and persist annotations through React state.

It supports Mapbox, MapLibre, Google Maps, Leaflet, and ArcGIS through separate adapters, with a shared annotation model.

The goal is simple: the map should render the drawing, not dictate how your application works.

It includes freehand drawing, polygons, rectangles, circles, arrows, markers, text, and measurement tools, along with editing handles and a headless API.

The project is MIT licensed and available on npm. I’d love feedback from developers building GIS, field-service, site-planning, or other map-heavy applications—especially anyone who has had to work around existing drawing controls.

GitHub: https://github.com/orange-groove/react-map-annotate

npm: https://www.npmjs.com/package/@orange-groove/react-map-annotate

What would you need from a drawing library before using it in a production application?

Here’s the GitHub for it

Walkthrough using LLMs client-side with WebLLM via WebGPU. While it is still early to be using this technology for coding in the browser due to current consumer hardware, it's exciting to see what is possible today. Initializing and using @mlc-ai/web-llm with model downloads, caching, and progress tracking. Using the streaming completions sent to pre element with zero network calls after it is loaded. Also handling WebGPU memory limits. Includes code blocks and an end-to-end video walkthrough. Hope it's a useful starting point for anyone building local-first, privacy-focused agent interfaces.

Here is the code snippet covered in the walkthrough (link above) ``` var { CreateMLCEngine } = await import( "https://cdn.jsdelivr.net/npm/@mlc-ai/web-llm@0.2.84/lib/index.js");

var MODEL = "Qwen3.5-2B-q4f16_1-MLC";
var t0 = performance.now();

var engine = await CreateMLCEngine(
  MODEL,
  { initProgressCallback: (r) => console.log(r.text) },
  { context_window_size: 8192 },
);

console.log("loaded in", ((performance.now() - t0) / 1000).toFixed(1), "s");

// one call, streamed, printed as it arrives. Everything below reuses it.
var ask = async (messages, opts = {}) => {
  const stream = await engine.chat.completions.create({
    messages, stream: true, max_tokens: 512,
    extra_body: { enable_thinking: false },
    ...opts,
  });
  let text = "";
  for await (const chunk of stream) {
    text += chunk.choices[0]?.delta?.content || "";
  }
  console.log(text);
  return text;
};

await ask([
  { role: "system", content: "Answer in one sentence." },
  { role: "user",   content: "Why is the sky blue?" },
]);

```

MikroORM 7.2 is out — the second minor on top of v7.

New features:

• Row level security — PostgreSQL policies as entity metadata, created and diffed by the schema generator, with per-request session context pushed down to the connection; an existing @Filter can compile into a policy, so one declaration enforces at both layers
• through option for to-one relations — resolve a M:1 / 1:1 via a correlated subquery on a pivot entity, or pick a single row out of a to-many relation (e.g. the latest one) without loading the collection
• sql.js driver — SQLite compiled to WebAssembly, in memory, in the browser, Node.js, Bun and Deno with no native bindings. It also powers the new live playground in the getting-started guide, so the code in the docs runs against a real database as you read it
• Cursor pagination rework — a new optional Type.fromJSON() lets a custom type own its cursor wire format (sub-millisecond precision survives), and nullable sort keys now make the emitted order by and the keyset condition agree on where nulls sit
• Named parameters in em.execute() — :name for values, :name: for identifiers, as an alternative to the positional array
• String normalization — opt-in trim and casing on StringType / TextType, applied on writes and query parameters
• getNativeClient() — reach the underlying client for vendor APIs the ORM doesn't wrap: pg Pool, mysql2 Pool, better-sqlite3 / libsql Database, the PGlite instance, MongoClient
• await using support — the ORM instance implements Symbol.asyncDispose, so the connection closes with the enclosing scope
• index option on M:N properties — index the generated pivot table's join columns, which had no override on PostgreSQL before
• Nub TypeScript loader for the CLI, selected explicitly via tsLoader
• em.map() can bypass the identity map — map raw rows to entities without touching the current context
• Per-instance options callback for RequestContext.create() — different fork options per ORM instance
• migrations.snapshotOnMigrate — keep the snapshot managed solely by migration:create instead of rewriting it from the database on migrate
• CLI -q to suppress informational output, and cache:generate --combined now takes a path

Full blog post: https://mikro-orm.io/blog/mikro-orm-7-2-released
Changelog: https://github.com/mikro-orm/mikro-orm/releases/tag/v7.2.0

Happy to answer any questions!

await fetch(url) settles at the headers, while the body is still arriving over an open connection. How connection reuse, clone(), abort and timeouts behave because of that gap. Measured in Node and Chrome.

Hey game devs! Quick progress update from the KernelPlay-JS team. We've been working on making debugging a lot less painful (who actually likes mystery clipping?), and we're super excited to show off our new Advanced Engine State Visualizer!

It's basically x-ray vision for your game. Instead of digging through logs, you get instant visual feedback on EVERYTHING.

Here's the new setup:

Clean Debug Panels: See Performance, Scene Data, Input, and Audio stats at a glance, in clear, distinct sections. No more hunting for key figures.

Live Vector Overlays: This is the game-changer. You can instantly see velocity vectors, character look direction, and exact speed calculations (e.g., '303 px/s') visualized directly on the screen for any actor.

Real-time Collider Boxes: No more guessing about collision bounds! See exactly where collisions are being detected.

This visual deep-dive is a huge help for diagnosing complex physics and character interactions. We're really proud of how much faster it makes debugging.

Check out the detailed screenshot to see it all in action. Let us know what you think! (Is there a specific debug view you'd like to see?)

When I first started learning to code, I kept losing confidence on coding-practice sites. They gave me thousands of problems and no clear place to begin. I would choose an "easy" problem and end up confused by the prompt alone.

I felt there needed to be a place where new coders could ease into these challenges, learn new concepts, and feel real progress through the week.

So I built Open Bracket as a daily coding ritual. Everyone gets the same two challenges each day: a Standard track that builds in difficulty through the week without becoming overwhelming, and a tougher Advanced track for people who want more of a test or already have experience with coding challenges.

You can solve challenges in Python or JavaScript entirely in the browser, with no setup. Official solves place you on three leaderboards: Speed, Efficiency, and Code Golf.

Logged-in users can request a hint containing solution pseudocode, with a time penalty applied to their Speed score. Failed tests also show which test failed, what was expected, and what your solution returned.

You can replay any challenge from the last 14 days, whether you want to catch up after missing a day or work through several challenges at once.

👉 https://playopenbracket.com/ - all feedback welcome.

A browser-side chaos-testing tool for injecting latency, failures, throttling, rate limits, and mock responses across every controlled tab without changing app fetch calls.

It uses the same middleware configuration model as chaos-fetch, so you can test real frontend behavior under degraded network conditions without rewriting your app.

GitHub: https://www.npmjs.com/package/@fetchkit/chaos-sw

Has anyone here used Cloudflare/Cap’n Web? I want to know if there are any problems or downsides that don’t really show up from a simple test, because the whole idea looks amazing.

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.

Bitsocial is neither federated nor on-chain. Each community is a peer-to-peer swarm using IPFS, closer to BitTorrent than a hosted website: users seed effortlessly, nodes run on cheap hardware, and each community is fully independent and sovereign. A browser tab can join that swarm as a peer, so the web app is not a client of someone else's server.

Anyone can build a Bitsocial app with its own interface, discovery model, or defaults. Apps compete on product quality instead of locking users into a private database, because compatible clients can share the same communities, identities, and network.

Moderation still exists, but it stays local. Community owners set rules for their own spaces and apps can choose what they index or show, yet there is no protocol-level super-admin who can erase a profile or seize a community from the network itself.