@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:

toJS() converts plain JS objects with a length property, in an Immutable collection, to an array (v4) #1438: bug with toJS behavior — fixed by Make isArrayLike check more precise to avoid false positives #1520
Immutable.Record with a "size" key causes "merge" commands to fail #1490: bug where Record with a size key fails when used with .merge() — fixed by Fix collection size check in merge #1521
DeepMerge transforms Map to [key, value] Array in some conflicts #1475: deepMerge of List with Map at same key generates a native JS array
Performance problem with toJS function in Immutable 4.0.0-rc.8 #1453: reports 2x slower toJS performance in rc.8+, as compared to rc.7
merge breaks on objects with a 'next' key #1456: bug with fromJS behavior
Overriding Record toJS broke in 4.0.0-rc8+ #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:

Record(...) subclasses don't produce fully initialized instances #1495: Public instance fields of extended Record classes (i.e. subclasses) get overwritten after using .set() (babel specific?)
[v4.0.0-rc.9] Flowtyping subclass Records isn't working #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:

Record.withMutations not compatible with RecordOf type #1465: Flow errors from Record’s withMutations with RecordOf type — fixed by add "& T" to some places where it's missing in RecordInstance #1464
Strange Flow Error v4.0.0-rc.9 #1442: Flow Record setIn errors — maybe fixed by add "& T" to some places where it's missing in RecordInstance #1464
Typing for updateIn is broken if last node is an OrderedMap #1484: OrderedMap + updateIn Flow type errors — maybe fixed by add "& T" to some places where it's missing in RecordInstance #1464 (update: no one can verify or reproduce this issue)
Using flow, keyPath arrays of unspecified length for getIn generates errors (v4) #1409: keyPath types of unspecified length generate errors when used with getIn
4.0-rc9 flowtype: throws an error when trying to use new operator #1421: using new operator to create collections results in Flow errors
Read only types for Record #1507: Make Record constructor use $ReadOnly type; includes suggested type def change

Documentation issues:

Undocumented breaking change in v4: equal Node buffers no longer considered equal #1437: need to document breaking change in handling of equal Node buffers
Breaking change between 3.x and 4.x #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.

Uh oh!

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions