Q:

immutables typescript type definitions: why is concat operating on any?

I don't understand why the definition of concat in Collection<K, V> for instance uses any:
concat(...valuesOrCollections: Array<any>): Collection<any, any>;

why couldn't it be:
concat(...valuesOrCollections: Array<V>): Collection<K, V>;

?

A:

Ok so I've tried to modify the type definition in the source of immutables and run the tests, and I see now why they have the type definition they do.
They want to support basically everything, as in (obviously) the original JS api. For instance adding object properties:
  it('concats objects to keyed seq', () => {
    let a = Seq({a: 1, b: 2, c: 3});
    let b = {d: 4, e: 5, f: 6};
    expect(a.concat(b).toObject()).toEqual({a: 1, b: 2, c: 3, d: 4, e: 5, f: 6});
  });

adding multiple values directly as parameters:
  it('concats values', () => {
    let a = Seq.of(1, 2, 3);
    expect(a.concat(4, 5, 6).size).toBe(6);
    expect(a.concat(4, 5, 6).toArray()).toEqual([1, 2, 3, 4, 5, 6]);
  });

or even adding multiple arrays in parameters:
  it('concats multiple arguments', () => {
    let a = Seq.of(1, 2, 3);
    let b = [4, 5, 6];
    let c = [7, 8, 9];
    expect(a.concat(b, c).size).toBe(9);
    expect(a.concat(b, c).toArray()).toEqual([1, 2, 3, 4, 5, 6, 7, 8, 9]);
  });

To get this in a type-safe way in typescript we'd need multiple overloads I guess (concatCollection, concatValues, concatProperties and so on).
PS: to be fair the parameter name in the original definition was a good hint: valuesOrCollections
Update: after i opened a small PR, the maintainer implemented an exhaustive fully type-safe solution.

