Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flow type declarations test #878

Merged
merged 10 commits into from
Dec 6, 2016

Conversation

wokalski
Copy link
Contributor

@wokalski wokalski commented May 18, 2016

I'm using Flow with Immutable but I found numerous false positives when I was working with it.
By false positives I mean cases where types were ignored. Most of the time it resulted in types dropping their generic definition (from T<K,V> -> T).

This is WIP because:

  • tests for Iterable and Seq are not implemented yet
  • merge on maps ignores types when given a ESIterable. It only infers types from plain objects.
  • after initialization without type (for instance by calling Map()) and setting a value on empty object it doesn't correctly infer types
var map: Map<number, string> = Map().set(1, '')

This might be a flaw of Flow so feel free to point it here.


In f31e5c2 I copied the definition of $Iterable to immutable-js. I did it for two reasons:

  1. It didn't work
  2. $Iterable is private

Tests for Iterable and Seq are not implemented yet. I had some problems implementing tests for Iterable. Ideally I would like to cast some concrete type to it, but I'm not sure how to do it.

Is the type of Map<K,V> Iterable<K,V,void,void,void>?


Next steps:

  • If tests receive a 👍🏻 I'm going to implement tests for other types.
  • I believe I found a bug in Flow. Namely argument of union type is not correctly resolved. I am not sure how to phrase it in order to file a bug in flow. An instance of this problem can be seen here. ESIterable is casted to { [key: string]: T }. How do I name this, casting?

@ghost ghost added the CLA Signed label May 18, 2016
@wokalski
Copy link
Contributor Author

pinging @marudor as a major contributor to this

@@ -464,7 +485,7 @@ declare class List<T> extends IndexedCollection<T> {
}

declare class Map<K,V> extends KeyedCollection<K,V> {
static <K, V>(): Map<K, V>;
static <K,V>(_: void): Map<K,V>;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whats the purpose of this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Type inference didn't work on objects without it. It looked like flow somehow ignores the object type, falling back to the constructor without named parameters. Since parameters in both constructors are optional, I thought that simply removing the empty constructor would solve the problem but it didn't. I added this one, and honestly I copied it from here. It's hard for me to give further insight since I'm new to both js and flow.

I encourage to run the test without the patches first (to check out at d7ee48c) and then check out subsequent commits.

@marudor
Copy link
Contributor

marudor commented May 20, 2016

Added some comments - otherwise looks nice.

@wokalski
Copy link
Contributor Author

wokalski commented May 20, 2016

Thanks for the review. I would like to note that the test for Map.merge doesn't pass because types are ignored. I would love to get some help fixing this.

@wokalski
Copy link
Contributor Author

wokalski commented Jun 7, 2016

ping @marudor

@ghost ghost added the CLA Signed label Jul 12, 2016
@wokalski
Copy link
Contributor Author

Closing. Work on this will be continued here

@wokalski wokalski reopened this Dec 4, 2016
@wokalski wokalski force-pushed the feature/flow-declarations-test branch from ea50739 to d2fa889 Compare December 4, 2016 20:14
@wokalski wokalski force-pushed the feature/flow-declarations-test branch 2 times, most recently from 28f7f80 to b3ee572 Compare December 5, 2016 08:35
@wokalski wokalski force-pushed the feature/flow-declarations-test branch 2 times, most recently from 3327572 to a2ea1c6 Compare December 5, 2016 08:43
@wokalski
Copy link
Contributor Author

wokalski commented Dec 5, 2016

I'm on a pretty epic bug. I wanted to fix imports according to this comment. The problem is that when I wrap everything in declare module everything is exported correctly, except for List. The funny thing is that if I rename List to Lista or really anything, it works.

@wokalski wokalski changed the title WIP: Flow type declarations test Flow type declarations test Dec 5, 2016
@lacker lacker self-assigned this Dec 5, 2016

env:
global:
- CXX=g++-4.9
- secure: "VDsxy30sE9ivdqoXkaKXo0czbS4brNpwKEIblu7f1gVLx7OD9pjTc78cdwrVbZDBYroSiYVYuUrLDjpVjH88lL/LxRrru3V0CIlAqqa+ssXcqycCaT/6ds+ZymuTTGRh+Mf12pIKO+yc8jTov2M7AzPJdpS+ORP5dImYyE3ex9s="

script: ./test_type_defs.sh
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm probably missing something about Travis here, but what is this replacing? Like what was the test script entry point before script was set here? Just want to make sure we aren't omitting something now.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's the first time I use node on travis and I felt that something was wrong, too. Thankfully @leebyron pointed out that npm install and then npm test is automatically ran by travis. There's no need to specify a script.

.*/node_modules/.*

[options]
suppress_comment=^\\( \\|\n\\)*\\$ExpectError\\(([^)]*)\\)?$
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is this line doing? Is there a way to comment the .flowconfig to explain this?

Copy link
Collaborator

@leebyron leebyron left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps update package.json to:

scripts: {
  "test": "everything-that-was-there && npm run type-check",
  "type-check": "flow check"
}


env:
global:
- CXX=g++-4.9
- secure: "VDsxy30sE9ivdqoXkaKXo0czbS4brNpwKEIblu7f1gVLx7OD9pjTc78cdwrVbZDBYroSiYVYuUrLDjpVjH88lL/LxRrru3V0CIlAqqa+ssXcqycCaT/6ds+ZymuTTGRh+Mf12pIKO+yc8jTov2M7AzPJdpS+ORP5dImYyE3ex9s="

script: ./test_type_defs.sh
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this would over-write the existing default script npm test - can we instead add the flow cli run to package.json scripts?


npm install
cd type-definitions/tests
../../node_modules/flow-bin/cli.js
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also - when called from the context of npm scripts, node modules are added to PATH, so you could just write flow there.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TIL - thanks

* @flow
*/

// Some tests look like they are repeated but it's not actually the case; It is very likely to have a false positivie because Flow might not complain about an instance of (what it thinks is) T to be assigned to T<K, V>
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"positive"

could you break this line up to keep to 80 char max or so

declare function Repeat<T>(value: T, times?: number): IndexedSeq<T>;

//TODO: Once flow can extend normal Objects we can change this back to actually reflect Record behavior.
// For now fallback to any to not break existing Code
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code -> code

yea i know nitpicky

@lacker
Copy link

lacker commented Dec 6, 2016

I just wanted to say that overall having flow type tests in this repo will make it a lot better, because it'll be a lot easier for us to accept a lot of the type-bug-fixes that have been submitted, so you are a hero for putting this PR together @wokalski

@lacker lacker added the flow label Dec 6, 2016
@wokalski
Copy link
Contributor Author

wokalski commented Dec 6, 2016

thanks for the review - I broke CI and didn't know about it. The little things you mentioned should be fixed now.

@lacker
Copy link

lacker commented Dec 6, 2016

Does $ExpectError actually fail if there is no error there or does it just allow an error on the subsequent line?

@wokalski
Copy link
Contributor Author

wokalski commented Dec 6, 2016

Good point! It does fail.

@lacker
Copy link

lacker commented Dec 6, 2016

YOLO

@lacker lacker merged commit 0155f1c into immutable-js:master Dec 6, 2016
@wokalski wokalski deleted the feature/flow-declarations-test branch December 6, 2016 18:32
leebyron added a commit that referenced this pull request Mar 1, 2017
The flow type definition tests added in #878 relied on declaring a module, which required .flowconfig to explicitly include the flow definition files, and made exports unclear. This reverts some of the structural changes to the immutable.js.flow from that PR and simplifies the .flowconfig test file to ensure tests are against the *local* copy of immutable. This uncovered a few issues with tests including a mistaken sense that types were exportes as classes and that Set intersections were causing issues.

Fixes #961
leebyron added a commit that referenced this pull request Mar 1, 2017
The flow type definition tests added in #878 relied on declaring a module, which required .flowconfig to explicitly include the flow definition files, and made exports unclear. This reverts some of the structural changes to the immutable.js.flow from that PR and simplifies the .flowconfig test file to ensure tests are against the *local* copy of immutable. This uncovered a few issues with tests including a mistaken sense that types were exportes as classes and that Set intersections were causing issues.

Fixes #961
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants