Type checking task

[markwylde]

Really nice project.

One of the main benefits to having types in code is that during compile time (or during your transpiling process) you can be warned of places where you have set the wrong type or called using the wrong type.

Typescript for example will warn you if you do something like:

Point({x: "1", y: 1});

The above will output an error explaining you have used a string instead of number type.

Would building a task to check the codes type safety be within the scope of this project?

Maybe using esprima and the parsing down the tree?

It's something I might try and help with if you feel it's within the scope, but thought I would ask as it would be good to get your opinions on this before starting extra work on this.

[Gozala]

Thanks for your interest @markwylde and I totally agree that type checking is better done at compile time as at runtime it's far less useful. That being said I don't think there is much value in implementing a custom type checker just for this library. Instead I think it would be more beneficial to leverage & invest in good integration with existing type checkers.

I personally have being looking into http://flowtype.org as it's gives you algebraic data type system that is more or less what this library is trying to provide at runtime. Unfortunately there are still gaps that prevents me from making typed-immutable and projects using it type checkable.

If you'd like to help with compile time type checking there are two areas you could really help:

1. Try to fill out the missing gaps in flow (I think it's manageable to get there if we just had first one, although other two would two would really help)
2. Add type constructs required to support Immutable.js Records facebook/flow#839
3. flow ignores .flowconfig of dependencies facebook/flow#876
4. Function argument types facebook/flow#854
5. You could help with updating current code by adding annotations and making it type check. I think it's will be tricky without filling gaps mentioned above, but I could be wrong as I have not actually tried doing it. I did integrate flow type checker into my other library though and I hit those limitations.
6. Instead of updating code to add type hints you could provide type annotations via interface definitions. You can read more about it here: http://flowtype.org/docs/third-party.html Although from my experience documentation does not provide nearly enough info on this subject it's being more helpful to look at the existing annotations https://github.com/facebook/flow/tree/master/lib (especially react.js type annotations)

Let me know if this sounds like a right direction & if it sounds something you'd be interested in helping out with.

Thanks

[Gozala]

Unfortunately I am no longer able to maintain this project, I apologize. If someone wishes to step up and take leadership of this project please respond to #21