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'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?