I see the same error. Also happens on Immutable 4.0.0-beta.2

Flow 0.47.0 shipped with experimental.strict_call_arity on per default and no option to disable it.

Hit this as well. The solution is to not use the new keyword when constructing immutable objects (which surprised me as well). The documentation doesn't indicate that constructing these objects with new is supported.

If new is intended to be supported, then the correct solution is to duplicate definitions for the nameless static methods with constructor as their names.

thanks for that. I might open a PR with that as the fix (unless you want to), solely because my linter doesn't like upper-first methods without the new keyword.

Seems weird that immutable doesn't allow this, or use it more in the docs. Is there any reason not to use it?

Yeah, not too sure about the why. The only place that I could see it being confusing is for Records, which have new explicitly documented and a typedef.

I'd say a PR is probably a good way to get a discussion going here or at least get an answer. I had one started but abandoned it once I realized none of the tests used new.

ahhh okay. fair enough. It just seems weird because then, if I'm not mistaken,

import { List } from 'immutable';

const x = new List([]);
const y = List([]);

console.log(x instanceof List); // true
console.log(y instanceof List); // false

unless the function calls the constructor if it's not explicitly called.

EDIT:

looks like they're calling the constructor if it's not called.

This is the output I expected:

So @deecewan, is the solution simply to drop the new keyword in order to stop flow from complaining?

That is correct, although I'm not super happy with that as a solution. It seems the solution would be to fix the type definitions. It feels wrong instantiating a new object of a certain type without the new keyword.

I agree, I am not fixing it in my project and would wait for an update to the type definitions.

Has anyone found a way to change the typedefs so flow doesn't error any more?

Is there any progress with this?

@MSch to do this, you'd need to add a constructor that matched the static method of each class.

For Map, for example, duplicating lines 686 & 687, and replacing static with constructor would work, I believe.

It should look like

static <K, V>(obj?: {[key: K]: V}): Map<K, V>;
static <K, V>(collection: Iterable<[K, V]>): Map<K, V>;
constructor <K, V>(obj?: {[key: K]: V}): Map<K, V>;
constructor <K, V>(collection: Iterable<[K, V]>): Map<K, V>;

That being said, I haven't tested this, and there would need to be a bunch of new tests written to ensure the libdefs were correct.

You can disable strict function call arity by adding the following to your .flowconfig

experimental.strict_call_arity=false

See https://flow.org/blog/2017/05/07/Strict-Function-Call-Arity/

Flow v0.47.0 will ship with strict function call arity turned on and the experimental.strict_call_arity flag will be removed.

@arv looks like its still there. https://github.com/facebook/flow/blob/v0.52.0/src/commands/config/flowConfig.ml#L804

Thanks for the report - in general using new is discouraged with Immutable factory functions. They are similar to the String() or Number() factories.

Looks like we have these flow errors fixed in what will be the next release.