Would you use an actively maintained, compatibility-first successor to Normalizr?

[davideagosti-dev]

Hi everyone,

I've been looking at the current state of Normalizr and the discussion around its future, and I'd be willing to take responsibility for building and maintaining a modern, compatibility-first successor.

My intention would not be to create another short-lived fork or redesign the library unnecessarily.

The goal would be to preserve the existing Normalizr API as closely as reasonably possible, while modernizing the project around current JavaScript/TypeScript and Node.js tooling, addressing outstanding bugs, improving the type system, testing and CI, and maintaining it long-term.

Because this would initially need to be published as a separate npm package, existing users would at minimum need to change their dependency and imports:

"normalizr"

→

""

Where possible, I would like the rest of the migration to require little or no application-level rewriting.

Before starting the implementation, I'd like to understand how many developers are still using Normalizr in real applications and whether a compatibility-first maintained successor would actually be useful.

If you're currently using Normalizr:

1. Would you migrate to an actively maintained successor if the primary migration were changing the npm dependency/import?
2. Which Normalizr APIs are essential to your application?
3. Are you currently maintaining patches or workarounds?
4. Are there bugs, TypeScript limitations, ESM/Node compatibility issues, or missing capabilities affecting you today?
5. Would you be willing to test an early release against an existing application?

If there is genuine interest, I'm willing to treat this as a long-term open-source maintenance project rather than simply publishing another temporary fork.

And if the project proves stable, well-maintained and compatible over time, I'd also be open to discussing whether contributing that work back upstream or taking on maintenance of Normalizr itself would make sense.

I'd particularly like to hear from teams that still have Normalizr in production today.

[markerikson]

Transferred the discussion to the RTK repo.

Tbh I don't know who is using Normalizr, but I'd certainly be happy to see someone pick it up or provide a modern option.

[davideagosti-dev]

Thanks for transferring it, I appreciate it.

That's exactly what I'm trying to establish before starting the implementation: whether there are still teams actively using Normalizr that would benefit from a compatibility-first modern successor.

I'm happy to take on the engineering and long-term maintenance if there is genuine demand. Ideally, I'd like to hear from a few current production users first, understand what they rely on today, and make sure a successor solves their actual problems rather than simply modernizing the codebase for its own sake.

Hopefully moving the discussion here will help reach some of those users.