(note: I've asked a stackoverflow question on the issue)

My issue with the current type signature for concat is that while it catches all the scenarios supported by the JS API, it's completely type-unsafe, including in its return type. The return type is the one that bit me, since it returns Collection<any,any>, if you don't cast after that, anything you'll do in a chaining call will compile without warnings, even if you use noImplicitAny.

The typescript compiler actually supports overloads and from my tests it actually picks up the more precise overload in my project and therefore gives me the precise return type of Collection<K,V>, giving me more type-safety.

I had also prepared another patch, with an extra overload:

concat(...values: { [key: string]: V }[]): Collection<any, V>;

with that extra overload (not really sure whether its definition is actually correct), and if you remove the original catch-all version, all the immutables tests actually pass, only one thing doesn't build:

let v2 = v1.concat(4, List.of(5, 6), [7, 8], Seq({a: 9, b: 10}), Set.of(11, 12), null);

and clearly no way to make that use-case type-safe. For the typescript bindings, it might actually make sense to enforce type-safety, and reject completely such scenarios. But if that's not an option, this PR already improves the situation at least on the return type, if not on type check of the parameters.