📣 🤝 Maintainer help wanted

[paularmstrong]

☠️ Important

Please see the update noting that Normalizr is no longer actively maintained.

History

Normalizr was originally written by Dan Abramov (@gaearon) and I took it over years ago while working at Twitter, as it became a critical piece of the web application's API/redux integration. I no longer work at Twitter and as far as I know, the team there is moving away from the current API/redux solution and diving into a Graphql solution using Relay.

Present

Since my time at Twitter, I have not once reached for Normalizr. There are many tools that make it somewhat obsolete, like Graphql (Apollo and Relay), as well as Redux Toolkit's rtk-query.

I also find myself increasingly without extra time to dedicate to routine maintenance on open source projects. Not being available is a disservice to the community and I feel like I'm letting you all down when I'm not able to help out. Not only that, but if something were to happen to me, no one else is able to publish the package.

Stability

Aside from a couple small open issues regarding typescript definitions, I consider Normalizr to be a stable and mature package. It does everything it needs to do and it does it well. For the most part, I don't think Normalizr requires much more.

Call for maintainers

Despite the stability, I would like to have two active maintainers on Normalizr outside of myself.

Current contributors: @ntucker & @unindented (not counting @gaearon, unless he'd like to come back), if either of you have interest, please respond and we can make the necessary arrangements. You would be my first choice as you've both shown high levels of ability and trust.

If you are an active user of Normalizr and would like to be considered to be a maintainer and publisher of Normalizr,

• Agree with the Long term vision below
• Have at least some experience maintaining an open source JavaScript module
• Are an active user of Normalizr
• Have time and patience to help others with Normalizr

Long term vision

• Be small
  • The published size of the library should strive to always be smaller and never grow unless absolutely necessary
• Be fast
  • Normalizing large JSON payloads should not become a bottleneck to an application
• Be simple
  • Do not add complex, one-off use-cases to the main library
  • Should not have any required production dependencies (see "Be small")
• Be stable
  • Breaking changes should be avoided unless necessary. This has happened once and it was not optimal, but was done for the greater good of increasing the speed of normalization and helpfulness of the library.

Things that should probably happen

Not a source of truth, but just some things I've been thinking about doing that would be nice, if I ever found the time.

• Remove the examples folder into a separate repository, or delete all-together. This folder is difficult to maintain and causes a lot of security vulnerability warnings on Github due to dependencies, despite the code not actually being used.
• Publish as a true esmodule and remove the commonjs, umd, amd, and iife builds.
• Drop node 10 support, if any
• Move away from travis-ci and onto github actions for CI on pull requests
• Rewrite as typescript. Attempting to maintain separate definitions files is cumbersome. (Also drop flowtype support)

How to become a maintainer

Read all of the above. If you'd like to take on a bit of open source responsibility, just respond here. Tell me where and how you're using Normalizr and any data you can share about that (how much data, how many users, whatever you think is interesting). And share other things about yourself: what have you written, published, maintained, enjoyed. And lastly, some way to contact you! Twitter DMs is an easy one. Email is not so bad. Any other way is a lot of effort :)

NOTE: I will try to over-communicate this via Twitter. Please share and recommend to others as well!

[markerikson]

I'm specifically not volunteering to help maintain this myself, but as a Redux maintainer I wanted to say thanks for your time and effort working on this package!

[paularmstrong]

🙏🏻 Thank you!

[jakeboone02]

I think I would like to help out. I haven’t used Normalizr a lot but I have a good use case for it at work. I can provide more info tomorrow about that (currently on mobile). As for other considerations, I took over maintenance of the react-querybuilder library a few years ago, converted it to Hooks and TypeScript, and modernized the codebase. I enjoy the interaction with users and can spare some time to contribute more to OSS. Twitter username is the same as here.

[paularmstrong]

Thanks Jake! I'm going to keep this open for some time and will reach out after enough people have had a chance to share interest.

[ntucker]

I'm curious about these two seemingly contradictory statements: "...make it somewhat obsolete" and "It does everything it needs to do and it does it well."

I like:

Be simple
Do not add complex, one-off use-cases to the main library
Should not have any required production dependencies (see "Be small")

But I'm curious what you think about non-one-off use cases that maybe those other libraries have a solution for that normalizr doesn't? I believe if such tools were provided as incremental adoption this should not disrupt those who with to continue using the smaller footprint - especially with ESmodules.

The reason I asked is because I previously forked normalizr to experiment with a TypeScript-first approach. However, I also integrated things like data validation, deletions and something I call results inferencing. The docs are here: https://resthooks.io/docs/api/Entity with built in playgrounds.

I believe there is a way to upstream these experiments while maintaining backwards compatibility, and we have CI to track performance on every PR on that repo.

@markerikson I think it could be interesting for you to adopt TypeScript standard endpoint definitions for the rtk-query library. It's a pretty simple way to enable people to publish their API interfaces (internally or on npm) and use in many cases - hooks, other javascript ui libraries or even as simple fetch functions. More interestingly it separates the API definition from usage, allowing easy reuse of the api definition across many components.

[paularmstrong]

But I'm curious what you think about non-one-off use cases that maybe those other libraries have a solution for that normalizr doesn't? I believe if such tools were provided as incremental adoption this should not disrupt those who with to continue using the smaller footprint - especially with ESmodules.

I definitely could have clarified here.

Do not add complex, one-off use-cases to the main library

This is more for cases where there's a special use-case that really only pertains to one application. eg, "I want the result of normalization to look different". Special case stuff like this is difficult to maintain all avenues–there are already a lot in Normalizr!

Should not have any required production dependencies (see "Be small")

When I talk about dependencies, I mean actual third-party libraries. Every dependency added creates a chain for potential issues, errors, security issues, and package bloat. esmodules don't solve everything and can I've seen them implemented incorrectly. My best advice is to just avoid dependencies. Even @rest-hooks/normalizr doesn't have any.

---

I hadn't even seen Rest Hooks before this. Looks really awesome!

[markerikson]

@ntucker : that sounds like a rather separate topic :) Could you file a discussion thread over in the RTK repo to bring that up?

[ntucker]

@paularmstrong I much prefer working with others than alone. I would love to work together on normalizr; however, as I'm sure you do as well I have limited time. With that I would love to explore the idea of being able to sort of re-merge my fork for rest hooks so I don't have additional work. Would you be down for a voice call this week? I much prefer that for complex communications than text back and forth. Plus, it's always nice to meet new people :) If so, I just followed you on twitter (I'm npinp there) and we can DM for details.

[nouman91]

Would you consider someone with no open source experience? If the answer is yes then I would love to help and can share details about myself and my work experience.

For starters I would like to mention, I love working with people and have worked with people from different countries/backgrounds in my professional career. I have also been a Normalizr user in the past, used it in one of the projects extensively.

I am also available on twitter (NoumanWaheed)

[broofa]

Would you consider someone with no open source experience?

As an outsider of sorts (I don't use normalizr, but I do know @paularmstrong) maybe you could start by working with Paul to tackle 2-3 of the existing issues. This would...

• Expose you to the codebase and the inner-workings of tests, workflows and such
• Demonstrate you have the time and energy necessary to maintain the project
• Establish your credibility with existing users of the project
• ... and most importantly, demonstrate to Paul that he'll be leaving the project in good hands

[nouman91]

Sounds good!

[anseal]

I'm not yet sure if I'm ready to commit to such duty. But I'm willing to consider this opportunity. So I'll leave this comment for now. If you find me worthy 😉 let me know.

I don't have any extensive experience with open source package support, but have a normalizr's fork that is used in a big and stable company, so at least I have an incentive to maintain. Of course, a company may have it's own agenda, but I won't put it before normalizr's backward compatiblity, because my image of a responsible maintainer is more valuable to me. Also, I don't plan to migrate normalizr to my fork, because I've sacrificed some features there (like Immutable's support). But some speedup, probably, will be added (that was the main reason for the fork to be made). Must say that those are tested on a project with hundreds of schemas... so you can imagine that I take backward compatiblity and performance seriously.

[sayjeyhi]

@paularmstrong I am not an active user of this repo but think I could do this, I have experience working on open source projects, publishing packages, and also we are
using normalizr on our current project

[scriptcoded]

I haven't used Normalizr in years, but I'm currently considering putting it at the core of our frontend for a smaller project at work, and that's actually how I found my way here. If I end up using it I'll most likely spend a lot of time with it, and then I might as well take the time to dig into the sources when I'm at it. For this specific project the user base won't be very large though.

I currently work as a fullstack developer at a small company, mostly fiddling with Node, TypeScript and Vue. Since we're just two developers I also happen to manage our CI/CD flows which all run on GitHub Actions.

As for open source work the only project I "actively maintain" is sql-highlight. There are a few dependabot PR's that should be taken care of, but as with this package I'm not actively using sql-highlight myself which sadly usually leaves those hanging for a while. simple-pdf is also an interesting one, but I'm currently working on a full on replacement for that library and since practically no one is using it it's dead. The rest of my funky packages, some in TypeScript, can be found on NPM, but I haven't touched most of those in years.

So let's put it this way. There are without a doubt developers better suited for the job out there, but if you're still left with one too few maintainers I'm all up for the task.

Here's my email and Keybase, any goes.
malcolm.nihlen@gmail.com
https://keybase.io/script_coded

Cheers,
Malcolm

[paularmstrong]

I've been sitting on this for a while. Sorry for the slow updates, as per usual 🤦🏻‍♂️

There have only been a couple of people here that have expressed interest. I honestly thought that there might be a little more community interest in keeping Normalizr running and up to date, so I'm a little uncertain about what to do. I really, truly, deeply, appreciate the interest to become a maintainer by @jakeboone02, @nouman91, @anseal, @sayjeyhi, and @scriptcoded. 🙏

If any of those mentioned, or anyone else, still has interest: I believe the best next steps would be to show me and everyone else that you have the interest and initiative to maintain Normalizr and help keep it and its community alive.

There are a few open PRs that could use reviews and feedback, as well as 20-some open issues that need triage, responses, or pull requests.

I hope this request doesn't come off as weird – it feels odd to me, like asking for "free work", but at the end of the day, Normalizr and any other useful open source package will need dedicated maintainers that can continue to push its vision and keep a sense of community involvement alive.

I really appreciate @broofa's idea of a "Maintainer covenant" and I will work through that when and if the time comes :)

[jimmywarting]

I'd be willing to take up maintainership for this project. My company is looking to use this project, I'm a core team member of the popular node-fetch package since the very first besinning and takes care of a number of other popular open source project.
I know a thing or two about open source and making sure it's harmful and well documented and safe

That being said, I have had a fascination of getting things modernized. My motivations are not to prioritize the needs of my company over the needs of the community. Looking through the issues, I think that I could help with answering the questions people have or looking into (and potentially fixing) the problems that are presented.

If it's alright with you then I would like to get full maintainership of npm package and that the github is transfered to my account along with all the issues/PR that comes with it

Just let me know 👍

[paularmstrong]

Thanks @jimmywarting, please see my previous comment: #493 (comment)

[broofa]

@paularmstrong : 'Just did a quick scroll through @jimmywarting's PRs on node-fetch. Looks like he's done good work there, with significant contributions. He's also worked with @LinusU on a fair number of those, who I know through his work on uuid.

(Not that I have a dog in this race, other than being generally interested in the process by which modules change hands.)

[paularmstrong]

Due to lack of follow through by any interested parties, I've decided to stop maintaining Normalizr and archive it on Github.

I've published a new release, 3.6.2 that only notes it is no longer maintained.

Thank you all who made Normalizr fun while it lasted.

FAQs

Should I still use Normalizr?

If you need it, yes. Normalizr is and has been at a stable release for a very long time, used by thousands of others without issue.

What should I do if I want other features or found a bug?

Fork Normalizr on Github and maintain a version yourself.

Can I contribute back to Normalizr?

There are no current plans to resurrect this origin of Normalizr. If a forked version becomes sufficiently maintained and popular, please reach out about merging the fork and changing maintainers.