Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The road to 4.0 #1494

Open
leidegre opened this issue Mar 19, 2018 · 30 comments

Comments

@leidegre
Copy link
Contributor

commented Mar 19, 2018

So, not much has been happening since October, yet a lot of breaking changes have gone into the 4.x branch, some of these with respect to improved Records, like better typing and performance.

I get that people are crazy busy but I really think we should try and get a 4.0 release done. How can we help?

@donkeybonks

This comment has been minimized.

Copy link

commented Mar 20, 2018

It would be great to merge #1464 before 4.0

@vytautas-pranskunas-

This comment has been minimized.

Copy link

commented Mar 20, 2018

4.0 is totally MUST

@leidegre

This comment has been minimized.

Copy link
Contributor Author

commented Mar 22, 2018

@leebyron is aware https://twitter.com/leeb/status/976862384794095616 I'm confident it will happen but we'll have to hang tight for a while.

@joshvito

This comment has been minimized.

Copy link

commented Apr 20, 2018

+1 to wishing and hoping for a release date for v.4.0

@donkeybonks

This comment has been minimized.

Copy link

commented Apr 20, 2018

Flow typings are still mostly completely broken though, 4.0 can not release in this state :(

We have been using the rc for 2 months and have about 50 // $FlowFixMes accumulated in our code.

@acusti acusti referenced this issue May 2, 2018
@acusti

This comment has been minimized.

Copy link
Contributor

commented May 3, 2018

@donkeybonks Here’s hoping that many of your issues will be resolved by #1464. We’ve also been using rc.9 for a few months in production, and while we’ve run into some annoying type bugs that required adding $FlowFixMes, the significant improvement in type coverage and detail has felt very much worth it.

@leebyron Looking through the GitHub issues, I found 6 remaining non-type-definition and non-documentation related issues for the v4.0 RCs in approximate order of importance:

  • #1438: bug with toJS behavior — fixed by #1520
  • #1490: bug where Record with a size key fails when used with .merge() — fixed by #1521
  • #1475: deepMerge of List with Map at same key generates a native JS array
  • #1453: reports 2x slower toJS performance in rc.8+, as compared to rc.7
  • #1456: bug with fromJS behavior
  • #1446: overriding Record’s toJS no longer workings in rc.8+ (not sure if this is intentional)

There are also a couple issues related to improving support for Record sub-typing, which might be candidates for a follow-on release:

  • #1495: Public instance fields of extended Record classes (i.e. subclasses) get overwritten after using .set() (babel specific?)
  • #1454: Can’t type extended Record classes with Flow

The rest of the issues have to do with types or with documentation, and at least for the type definition issues, seems like a good portion of them could be resolved by #1464.

Type definition issues:

  • #1465: Flow errors from Record’s withMutations with RecordOf type — fixed by #1464
  • #1442: Flow Record setIn errors — maybe fixed by #1464
  • #1484: OrderedMap + updateIn Flow type errors — maybe fixed by #1464 (update: no one can verify or reproduce this issue)
  • #1409: keyPath types of unspecified length generate errors when used with getIn
  • #1421: using new operator to create collections results in Flow errors
  • #1507: Make Record constructor use $ReadOnly type; includes suggested type def change

Documentation issues:

  • #1437: need to document breaking change in handling of equal Node buffers
  • #1504: a request for reconsideration, or at least a large emphasis in documentation, of the breaking changes to Map’s toArray method

Those are all the relevant issues I found looking at the first 4 pages of issues in GitHub pertaining to the 4.0 release.

@leebyron On a related note, there are a huge number of us relying heavily on Immutable.js in our work who would be very happy to contribute to the project. If nothing else, you can most likely find knowledgable and passionate people willing to help manage issues and assist with documentation, as well as look into implementing useful workflow improvements like stale issue bots and the like. I know managing open source is really challenging and complex, particularly when you are already so involved in a much higher visibility project like graphql. But Immutable.js, though lower profile, is a very widely used workhorse that has become an essential tool for a lot of the modern functional-ish JS dev community, and I think you will be able to find useful help from that community.

@leidegre

This comment has been minimized.

Copy link
Contributor Author

commented May 4, 2018

@acusti should we just fork the repo and finish the 4.0 release, if everything goes well I think @leebyron would just merge everything back into an offical 4.0 release?

@acusti

This comment has been minimized.

Copy link
Contributor

commented May 4, 2018

@leidegre I think that could be useful. At least knock out some of the most important bugs and see if we can fix some types.

Then we can also publish builds as we go so others can just swap out their dependency string for "immutable" in package.json and we can get feedback from those who have posted issues on whether they are resolved. In other cases where I’ve had to use a fork, in order to avoid the overhead of npm publishing, I’ve also created a <repo name>-build repo that just has the built files. I then refer to that repo directly along with the short commit hash in the package.json, i.e. "react-dom": "github:brandcast/react-dom-built#e673e48"

@leidegre

This comment has been minimized.

Copy link
Contributor Author

commented May 6, 2018

@acusti can you manage this? I can commit about 1-2 hours on a weekly basis, no problem but that's about it.

@acusti

This comment has been minimized.

Copy link
Contributor

commented May 10, 2018

@leidegre I created a fork at brandcast/immutable-js, and am pushing up built versions of immutable with bug fixes to brandcast/immutable-js-built.

So far, I’ve fixed #1438 and #1490, and I merged #1464, which I’m hoping will help with flow issues mentioned by @donkeybonks and others. To try out the fixes, replace your immutable dependency string in package.json with:

    "immutable": "brandcast/immutable-js-built#aa94985",

Note that I needed to clear out my yarn.lock file and node_modules and install from scratch to get the proper version.

@petrbrzek

This comment has been minimized.

Copy link

commented May 15, 2018

@leebyron left facebook. So I would not expect v4 anytime soon. 😞

@leebyron

This comment has been minimized.

Copy link
Collaborator

commented May 15, 2018

Hey all - @robinhood is also a big user of Immutable.js and I still plan on releasing Immutable v4.

I'll be working on the next release candidate this week to establish remaining issues

@leebyron

This comment has been minimized.

Copy link
Collaborator

commented May 15, 2018

@acusti can you make sure any issues you've fixed on your fork are reflected in pull requests in this repo? You can mention them here as well to ensure they get the correct focus.

Thanks so much for building up a list of issues

@acusti

This comment has been minimized.

Copy link
Contributor

commented May 15, 2018

@leebyron Congrats on the change! That sounds exciting.

I made PRs for the fixes. The only thing that made it into the fork so far are the following PRs:

@leebyron

This comment has been minimized.

Copy link
Collaborator

commented May 17, 2018

Thanks! I've merged all three of those PRs and will keep working on the next release

@leebyron

This comment has been minimized.

Copy link
Collaborator

commented May 17, 2018

I also just added all the issues you tracked into the v4.0 milestone https://github.com/facebook/immutable-js/milestone/1

@Brantron

This comment has been minimized.

Copy link

commented Jun 27, 2018

@leebyron 3 more PRs open for 4.0

#1549
#1544
#1543

@bryanrideshark

This comment has been minimized.

Copy link

commented Jul 19, 2018

Is there any way a non-involved person like myself could help getting this released? Our team would like to transition to ImmutableJS but the problems with typing in 3.x are preventing us from making the leap.

I'd be very willing to work on low-hanging fruit if it can help get 4.x out the door.

@polgfred

This comment has been minimized.

Copy link

commented Jul 20, 2018

Same here. Things seem to have stalled, and I'd love to help.

@Brantron

This comment has been minimized.

Copy link

commented Jul 20, 2018

I would also love to lend a hand. I think a lot of folks would love to start using 4.x

@glenjamin

This comment has been minimized.

Copy link
Contributor

commented Jul 21, 2018

Is there a milestone for what is blocking a 4.0 release? Presumably anything that's not breaking can wait until after a 4.0 is cut and go into a follow-up minor or patch release.

Edit: duh - I didn't actually read the issue very well, milestone is here: https://github.com/facebook/immutable-js/milestone/1

@lukaswelinder

This comment has been minimized.

Copy link

commented Aug 15, 2018

What's the status on reaching 4.0? It's been nearly a year since @leebyron posted the following

Closing this issue since the next release is coming imminently.

Looking at the 4.0 milestone; the last PR to be merged was well over a year ago; the most recently closed issue was a discussion about breaking changes which was close several months ago. I am concerned by this lack of engagement and transparency of precess.

It's clear that the community wants to see this happen and is willing to put in the time and effort to get there, so it would be nice to see those aspirations and efforts come to fruition.

@inakianduaga

This comment has been minimized.

Copy link

commented Aug 27, 2018

It's clear there is currently no official maintainer. Which for a project backed by Facebook is a bit shocking. We are currently using immutableJS in one of our projects but I would definitely not recommend it for starting something new.

@erkez

This comment has been minimized.

Copy link

commented Aug 27, 2018

ImmutableJS is a great library, but you are right, there are probably no maintainers at the moment. It seems like Lee Byron has moved to another company, and by looking at the repo statistics, he was pretty much the only maintainer.

I've been using version 4 quite extensively in my projects for a very long time and haven't noticed any problems, though it would be nice to see it moving out of alpha.

@Brantron

This comment has been minimized.

Copy link

commented Aug 27, 2018

@sophiebits can a new maintainer be selected so the community can keep this project going? We love using it and have put in a fair amount of work to try to get v4 out of RC.

@majelbstoat

This comment has been minimized.

Copy link

commented Aug 27, 2018

Alternatively, would facebook consider allowing this to move to its own organisation? Something like: https://github.com/immutable-js/immutable-js? I know the license means it could just be forked unilaterally by the community, but npm naming would be an issue, and it would be great to avoid fragmentation if possible (and reading the comments, I believe @leebyron would prefer to avoid that fragmentation too).

@conartist6

This comment has been minimized.

Copy link
Contributor

commented Sep 8, 2018

I'm not certain I have enough time, but I could be a potential maintainer. I don't have a track record of contributions here but I'm currently working on developing Sequins, which is an implementation of Immutable's API for mutable data structures. My project's success hinges on the continued popularity (and maintenance) of Immutable.

@dieseldeesh

This comment has been minimized.

Copy link

commented Dec 4, 2018

@leebyron Thanks for cutting rc-12. As we eagerly await 4.x, would it be possible for you to add assignees (which may be yourself) and due dates for the remaining issues that are blocking the major version release?

Several ICs have offered a helping hand in seeing this over the line. Would it be possible to crowdsource the effort to get 4.x stable release (with you being the ultimate reviewer of course).

@acusti

This comment has been minimized.

Copy link
Contributor

commented Sep 16, 2019

@leebyron you mentioned working on a plan for the future of immutable.js development in #1689 (comment) back in february. is there any way any of us can help even just with fleshing out that plan for the future?

immutable.js v4 includes enough major improvements that it is a shame that consumers who npm / yarn install immutable to get the latest version won’t get those improvements. i think just getting a 4.0 out the door with the stable tag would be a tremendously valuable accomplishment for the community at large.

i did some more issue triage on new issues in the last year, and found:

  • #1701, which covers a bug in repeated use of the new .deleteAll method with OrderedMap
  • #1715, which describes unexpected behavior when using mergeIn along with a key pointing to an empty collection

there’s also an ie11 bug that i wasn’t able to confirm (no ie11 access), #1711, but i’m not sure what the required browser compatibility is for immutable 4.

the 4.0 milestone currently includes

  • #1409, which is an issue with the flow types for *In key path arguments that doesn’t need to block a 4.0 stable release
  • #1484, which is another flow type issue that should be closed because no one can reproduce it
  • #1475, which describes some unexpected behavior when doing a deepMerge on two collections with a conflict at the same key where one has a List and one has a Map; it would be nice to fix, but i’m not sure it should block a stable release

in my opinion, the only one of those issues that really needs to be fixed before a 4.0 stable release is #1701. it would nice to fix #1715 and #1475 also, but i don’t think it would be worth holding up a stable release for them.

@conartist6

This comment has been minimized.

Copy link
Contributor

commented Sep 16, 2019

Also given that it's a breaking change, I'd like to beg that long overdue support for Imm.Map(new window.Map(...data)) be added.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.