I like the idea; I think this could be cleaner and more powerful if it made use of the TS 4.x improvements to Tuples, variadic types, and generic types. Been meaning to take a crack at doing this to Map for a while; I prefer HM-style types, so recursion and type-algebraic shenanigans feel a little more natural. 🤷

yeah, this solution worked well and fixed my problems for type inference, but there is problems in this implementation, the first one is that the getIn type inference only works with a maximum of 4 properties and to make it work for more we need to keep repeating getIn function with more arguments, other problem is that this implementation doesn't implement the types for all the functions that Map provides, and the last one is more complicated, sometimes it's hard to know if something is in a Immutable way or not, for an example, Records doesn't apply deep conversion, so the first object is in a Immutable way and the second one isn't, but when we use the fromJS it does, so know when something is immutable or not is complicated

I think there is a huge problem with the actual Map interface.
The actual definition of the interface is :

interface Map<K, V> extends Collection.Keyed<K, V>

That is blocking a lot of things as it dissociate the keys and the values. It is useful as a Map is a Collection.Keyed<K, V>, and it does make sense with the internal implementation, but it is not flexible enough for the real use cases.

I started working on a different implementation for Map that are objects that might address these issues (still work in progress)

  interface ObjectLikeMap<R extends {[key in string|number]: unknown}, K extends keyof R, V extends R[K]> extends Map<K, V> {
    get(index: K, notSetValue: never): R[K];
    get(index: K): R[K];
  }

@jdeniau so, there is a problem on your implementation, as I said, it will not work for deep nested objects, for and example, if for some reason you have

const user = { name: 'name', profile: { role: 'user' } };

and a interface like this

interface User {
  name: string;
  profile: { role: string };
}

so what will happens when you put it into a fromJS?
it will deep convert all your objects into a Map and arrays as List, but the problem is that it will not infer the profile is a Map also, so we will need to change all our interfaces hardcoding types because it's not inferred properly (or keeping everything as any), and there is a huge problem if was not us that made that interface, we will need to override the types of other libraries or re-create it by hand which is bad, that's why I'm using that ImmutableMap type to infer everything properly and it's working good so far

@EduardoAraujoB Yes, fromJS is from far the hardest part ! 🤯

We are working on Map in #1841
fromJS upgrade won't probably be included in 4.0 though, as there is a lot to do with Map before.
If you are good in TypeScript and if you want to contribute, every help would be great ! 😃

thanks a lot @jdeniau I will check it out the progress and see if I can help

Immutable js types have many flows (I mentioned one of them at #1884 ). Overall using immutable.js in typescript is a nightmare because of constant type issues that are not always consistent between nodejs and browser based typescripts! I am considering moving away from it unless types will be improved.

@jdeniau do you have progress at your Map implementation? The fast that I cannot convert { [p: string]: number }[] to Immutable.Map or Immutable.OrderedMap (opened an issue #1885 ) is very annoying

@antonkulaga you can just read the last two comments and you may find an open PR that tries to solve some issues with Map in TS...

You already opened two issues about TS. No need to be pushy with two comments on another issue mentioning yours.

immutable-js is open source work. All the maintainers take on their free time to work on this (for example it's Sunday morning and I'm replying to you).
This is typically this kind of comportement that makes open source maintainer having burnout.

About the "threat" about not using immutable anymore: we don't owe you anything, so if you are not helping or enjoying immutable, please do use another alternative.

If you want to help though, you can :

• makes your issues the more easy to debug for us by at least post useful example,
• accept the fact that issues will be addressed whenever possible, and find an alternative in the meantime,
• get your hands in the code and open PRs

Thank you

Personally I found immutable unusable due to the inability to narrow unions of Map types but I think this is more a limitation of both typescript and javascript art this time.
I wanted to have a type like:

type Field = "String"|"Number"|{List:Field}|{Choice:Set<Field>}

```But converting this to immutible required the use of Map which couldn't be effectively discriminated against for the List and Choice variants.
This type was coming from auto generated API schemas so couldn't really be changed unfortunately.
If anyone knows how to do this without a bunch of flaky and case specific guard types I'm happy to implement it.
Proxies could maybe do it but given they're not being used already I assume the project has good reason to avoid them?

@Isaac-Leonard can you try the v5 RC? A lot of change has been made to the Map typescript.

Running 6pm install immutable gives me the v5 beta.4, I assume that's the most recent release?
My issue is shown in the code below:

export type Field =
  | "String"
  | "Number"
  | { List: Field }
  | { Choice: Set<Field> };

type P = FromJS<Field>;
let x: P = "String" as P;
if (typeof x !== "string") {
  x.has();
}

The call to .has doesn't work as it is the argument is typed as Never because of the union of the two map types.
I could write hacky type guards to get around that but would rather not.
Do you have any solutions?

Another issue is that the get method can return undefined even if the original objects properties are not typed as undefined.

Running 6pm install immutable gives me the v5 beta.4, I assume that's the most recent release?
My issue is shown in the code below:

export type Field =
  | "String"
  | "Number"
  | { List: Field }
  | { Choice: Set<Field> };

type P = FromJS<Field>;
let x: P = "String" as P;
if (typeof x !== "string") {
  x.has();
}

The call to .has doesn't work as it is the argument is typed as Never because of the union of the two map types.
I could write hacky type guards to get around that but would rather not.
Do you have any solutions?

I think that the FromJS of a union lost TS here. Immutable 5 latest change improve the Map type and introduced MapOf type.

I see you do export this type but I think I would have done this :

type P =
   | "String"
   | "Number"
   | MapOf<{ List: Field }>
   | MapOf<{ Choice: Set<Field> }>;

This way your if should know that this a Map or a Map and that has should work.

I can't seem to make it work properly.

type ImmutableField =
  | "String"
  | "Number"
  | MapOf<{ List: ImmutableField }>
  | { Choice: Set<ImmutableField> };

Works fine but assigning a value from fromJs() to a variable of type Immutable field doesn't work due to the differences between MapOf and Map.

I also can't get any methods to work on it:

const test2 = "String" as ImmutableField;
if (typeof test2 !== "string") {
  test2.has("List");
}

Just gives a error about has not being a field on test2 and it seems as though test2 has no fields or methods.

@Isaac-Leonard it's because you did not type { Choice: Set<ImmutableField> } as an immutable type here.

See the error message :

The if does work fine and exclude "String" and "Number" of your union, it does keep MapOf<{ List: ImmutableField }> and { Choice: Set<ImmutableField> } (a simple JS object). MapOf does contain has, but not a javascript object.

But you are right, pushing this forward (ts playgroud link), there is a issue of the union of MapOf because it does try to find a valid intersection between the keys "List" and "Choices" here 😒

I'm keeping that in mind if I have a fix in the future.