It no longer seems reasonable to expect @leebyron to be able to do it. He has many open source projects to care for in addition to what is probably more than a full time job at a startup and, I hope, a life of some kind.

I also no longer feel confident that the facebook/ in front of the name is helping the repository so much. FB OSS consists primarily of facebook exporting code developed internally, and they do not appear to have put forwards any new maintainers. Perhaps they plan eventually to hire someone to fill the position, but they have not stated such an intention, and it is not possible to ask (directly).

Logically then, I think the community should consider making an OSS fork in its own Github organization. If I am right and the OSS library races ahead of this repo in terms of needed fixes and improvements, it should not be long before we create the pressure needed to merge the forks, or simply cause people to switch. I already have quite a lot of work that I could contribute to an OSS fork, modernizing it ways that currently seem unlikely to happen here.

If such a fork were to happen, how many people would be interested in participating as maintainers?

If such a fork were to happen, how many people would be interested in participating as maintainers?

I'd be cautiously interested; my availability is very irregular so I wouldn't be able to carry the project on my own, but I'd be happy to deal with maintainer work when I'm able to.

I don't know whether this project internally uses Flow anywhere, but if it does, it should be noted that Flow is in a similar state where the repository is pretty much just a periodic dump of FB-internal code with no community interaction. I suspect the same will end up being true for many other Facebook repositories.

Hey yall, thanks for your patience. I've been working on a plan for some time. I'm really sorry for the radio silence, but I expect to have a plan forward soon.

What exactly is your idea of soon? 😛

@leebyron Should we abandon all hope at this point? 😢

We've been running on 3.8.2 in production for so long because updating our code wasn't worth it for a package that may never see a stable 4.0

@TheMoonDawg for what it’s worth, we’ve upgraded to 4.0 early in the year without any hiccups. It’s very stable and totally worth the effort.

We did upgraded to 4, but we have some issues with iterating on List for lists bigger than 32 items

it starts iterating 0 32 1 33 2 34 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

so I need to .toJS() the list tp array first to get consistent behavior.

My guess is the error is on your side, a link with a reproductible issue could help. I have been using 4.0 rc for nearly 2 years and never had such problem.

sorry, I do not have time for reproduction, since then we moved on to immer.js

@leebyron Is it safe to assume that since soon has turned in to four months that you were not able to come up with such a plan? It's also been 4 months since the last commit to the library.

I figured the hangup would be getting the library released from the facebook organization, though that's done already. It even seems to be free of the FB CLA now.

The only question unanswered is: are there going to be other maintainers?

Looking forward to hearing how we can all help. If this project gets revived I'll get involved again.

@leebyron @rgbkrk If project will be revived, how about porting in to TypeScript? a lot of people struggling with using immutable.js with TS, including me. Currently I do not know any other library, which provides persistence with immutability. Immer clearly doesn't provide persistence.

How about just fork the project and publish it under immutable-ts name?

@JustFly1984 It would be much, much better not to fork the project if we can avoid it. And you're not really pointing out a distinguishing factor: the existing Immutable already supports TS in all the ways that are important to a consumer of the library.

@conartist6

the existing Immutable already supports TS in all the ways that are important to a consumer of the library.

It would be great if we could get some basic fixes to the types merged though...

@leebyron ping.

Any change on maintenance status of this library? I guess there are some people like me out there who are worried about immutable.js effectively having no maintenance...

@leebyron

Hey yall, thanks for your patience. I've been working on a plan for some time. I'm really sorry for the radio silence, but I expect to have a plan forward soon.

This quote is more than 6 months old...

We have started migrating a pretty large react-redux codebase to https://github.com/immerjs/immer, very much due to the uncertain maintenance status of this project. It's a shame because Immutable is an excellent project.

@csvan You might be interested in iter-tools -- it can help you fill in all the missing functionality that Immutable had for transforming data in structures. One of the reasons I haven't rushed out to fork immutable is that in the future I think that the things it does will no longer all be stuck together in one big project.

Can someone weigh in on the differences between this library and immer and the pros and cons of each?

I mean the differences are... everything.

The drawback of Immutable's every-thing-but-the-kitchen sink approach is that it's difficult to maintain such a big library which is both an Trie-based data structures library, a collection of utilities a la lodash, and a complex collection of browser compatibility hacks. It also means that you end up pulling all of Immutable into your project, which is a big hit to bundle size especially for anything that's meant to be small. What I've seen in my work is that many companies are just now moving from monoliths towards what OSS has embraced for a long time: many separate, small, focused packages that depend on each other. For such lightweight packages, importing all of immutable is simply an unacceptable cost.

The drawback of Immer is that it only works seamlessly with Objects and Arrays, and new javascript development is likely to move towards storing data in Maps and Sets.

I'm trying to work towards a third solution, where all the transforms and methods Immutable offers are functions over iterables exposed in a separate library (making them easy to tree shake), which would leave Immutable free to focus on its core proposition of Trie-based implementations of Map, Set, and List.

@opr For me, the essential difference is that every Immutable.js collection is actually immutable. Native object literals and arrays are mutable, and must be deep frozen to make them immutable. As a result of the Immutable.js team’s decision to implement all of their own collection types, Immutable.js also offers a broader range of collection types, including very useful types like OrderedMap, Set/OrderedSet, and Seq. Speaking of Seq and lazy evaluation: as a result of having its own collection types, Immutable.js doesn’t feel like magic, making it easier for me to reason about the performance implications of the code I write. If I want to leverage lazy evaluation via toSeq, I can do so knowing what is happening behind the scenes. Immer feels like magic, which is really cool, but means I don’t know how to reason about performance. Also, going full Immutable.js from beginning to end with my store data (no fromJS in my plain actions or reducers) means I get much better performance on general data operations and manipulations. Reference on that last one (from the Immer docs):

I can understand that people build cool stuff and after a while do not have the time anymore to maintain it.

But what is terrible, when a widely used project like this fails to name a successor or nominate a new maintainer. How are we supposed to find an active fork with recent bugfixes in a list of 1.7k random forks?
Heck, there are enough paid devs that would actively contribute, it's just that their initiative is ignored or gets lost in the noise.
All that @leebyron would have to do is ask for maintainers and permit some to accept merge requests.

Hey yall, thanks for your patience. I've been working on a plan for some time. I'm really sorry for the radio silence, but I expect to have a plan forward soon.

Another year has passed...

I would certainly also recommend @Methuselah96 as the next core maintainer. I don't think we ever want just one person to have full admin privs, but with Lee that would still be two which is OK. The bigger discussion is how to trust individuals who make good-faith effort (by granting them some privs) while also retaining quality code review and auditing to allow us to detect abuses. Immutable makes a great target for the kinds of people who want to slip malicious code into packages.

We talked quite a bit on slack about code and stuff, I certainly think both @Methuselah96 AND @conartist6 are capable guys and should be maintainers. I feel like it's always good to have 2 active maintainers, if that's possible. You two certainly have my vote for that

EDIT: Talk = discussing and actually adding, fixing and merging code, not just hot air ;)

@leebyron I would also recommend adding @conartist6 as a maintainer and agree that we should have two active maintainers.

Thanks for the updates here and on the slack channel.
I hope to contribute soon.

@leebyron Bump because you probably forgot: Please add the two to the list of maintainers.
The final R4.0 is close to being ready!

This sounds great!
I have started to prepare a migration from Immutable. One reason is the non-maintained state of the project. If I can postpone or maybe ditch the migration, I'd be happy.

Please keep up the good work.

@Methuselah96 @conartist6 I'm tagging you because you seem to be most involved with development of OSS fork.

What is going on anyway? Is @leebyron very busy? Would changing maintainers of this repo mean the work in OSS fork would be merged here?

@comatory who knows what's up with lee, promoting the two to maintainers should not be difficult to do.
If it ever happens, I guess we would merged back to the main repo. It's not just the repo, it's also the npm package

Worst case release 4.0 has to go public under a new name. Which is just plain sad.

Worst case release 4.0 has to go public under a new name. Which is just plain sad.

Yeah definitely not best situation. But if I have to pick between the library not being maintained and developed under a new name, I'd go with new name.

@leebyron bump
Any update on giving maintainers access to this project?

Wow, it's astonishing that an OSS project of this importance is still at this impasse.
Bringing it back to (new) life with new maintainers is just a click away and yet @leebyron ignores the community requests for almost a year now.

As a huge fan of the project, I find this extremely sad and not in line with what OSS should be. The whole community would benefit from the dozens of maintainers wanting to make it better, but instead, their efforts are just going to waste 🤷🏻

Yeah, I think the best course of action is to fork and rename the library at this point. Lee is either too busy or just doesn't care about the library anymore.

@TheMoonDawg I believe this has been done here https://github.com/immutable-js-oss/immutable-js

I just set up the @immutable-js/maintainers team and added the core contributors of the healthy fork. I’ll be giving access to NPM shortly as well.

I owe everyone here a huge apology. I don’t think any excuse accounts for the delay I’ve put on the process of breathing life back into this project. I’m sincerely sorry for the frustration I’ve caused and the drag force on this project and the huge community of people who have come to rely on it.

I’m truly grateful for all of the support for Immutable.js from this community and the massive amount of work that @Methuselah96, @conartist6, and others have put into maintaining a fork so that work can continue despite my absence.

Needless to say, I’ve not been able to give this project the focus it deserves for the last few years. My career has taken a different focus, I have a growing family at home, and have had some maintainer burnout that has taken a hit on my mental health. While the amount of work to get the fork merged is not that large, it’s become a trigger for and reminder of that burnout and created a mental block. Again, none of this is a worthy excuse, and I hope that (very) late is better than never.

At least one critical advancement has happened for this project in the last year or so, which had been blocking the addition of new maintainers. I met with a few of the fine people working on Facebook’s open source team and had the project re-licensed as MIT and transferred from their custody. This is why you may have noticed the project move from facebook/ to immutable-js/. I’ve also secured the immutable-js.com domain name which I’m donating to this project to host documentation.

I hope this is the pivotal step necessary for this project to continue it’s life under healthy maintenance. Again, I’m sorry it’s taken me this long to bring this to fruition.

Thank you @leebyron for all your hard work so far on this project. I hope that the maintainer burnout you suffered doesn't stop you from feeling positive about your massive contribution here. I am glad to see this project can continue to live a full life without draining a single person's energy.

@leebyron Thanks for taking the time to get this project back up and running! Maintaining open-source is hard and unrewarding work and we appreciate the work you've put into this project to get it to where it is today.

I've started working on cleaning up the issues and PRs and created a milestone for the regressions from 3.x to 4.x (we have fixes for almost all of them on the fork, we just need to get the work moved over here). I'm excited to get these changes merged in, but don't want to step on your toes. The Slack workspace is still active if you're interested in joining there so we can coordinate our efforts (alternatively we could start a Discord server or add a channel on Reactiflux since that seems popular among the OSS/JS dev community). Or if you're fine with me starting to merge PRs I can just start doing that. I wasn't sure if you had a set plan for how to get the work from the fork merged in, or if we should just recreate the PRs on this repo so they can be re-vetted for inclusion here.

Matrix could also be an interesting option for project chat; it's an accessible option that's also open-source and not dependent on the generosity and ongoing support of any one given chat company, it being an open network.

(It can also be bridged to Discord if desired, though I'm unsure of the implementation details of setting that up.)

While the amount of work to get the fork merged is not that large, it’s become a trigger for and reminder of that burnout and created a mental block. Again, none of this is a worthy excuse, and I hope that (very) late is better than never.

@leebyron I'll bet a lot of us have had to deal with feelings like that; I know I struggle with it all the time. ❤️ I think the fact so many people still use Immutable even through this stagnation is a testament to the quality and value of the existing and past work. Big thanks for all your work on this project, and for facilitating the hand-off.

@Methuselah96 @conartist6 And big thanks to you for picking up the torch! My team and I have been using Immutable for years; we're super excited to see some movement on it again. I have effectively zero experience doing open-source maintenance, but this is the sort of project I'd like to start contributing to. I'll try to hop onto the Slack channel soon to get the lay of the land; I recently found a couple small typos in the docs that might be a good baby's-first-pull-request.

Hi!
The 4.0.0-rc.14 version has been released! 🎉
We will try to make stable 4.0 version a reality, but we still have some issues to close until then.

Thanks to @leebyron for all the work he has done so far, and every member of this community that took some time to make the OSS fork a reality, @Methuselah96 and @conartist6 in particular who spent a lot of energy here!

Happy to see this project come alive again! Best of luck ❤️

I don't wish to re-open the ticket, but is the Slack workspace still active?

I tried to sign-up, but it said I didn't have an account for it.

Naturally, I know that, but I usually get asked to go through the sign-up process through Slack when I don't as opposed to it just telling me I don't have an account (unless it's a private server).

Try this link. The Slack workspace is still "active" in that people are there, but there's very little activity. We have reached stable v4 which was our main goal.

Ah! I see. So is Immutable.js not updated regularly, then? Is it at least maintained to patch up vulnerabilities and such?

Yes that's right. Since the 4.0 release there have been a couple bug fixes that we still need to release and of course any serious security patch we would release quickly. Luckily there are no runtime dependencies so the surface area that needs this kind of support is quite small.