-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Flow type declarations test #878
Conversation
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>; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
Added some comments - otherwise looks nice. |
Thanks for the review. I would like to note that the test for |
ping @marudor |
Closing. Work on this will be continued here |
Also added flowconfig file to allow running the tests.
Fixes many errors in flow tests.
ea50739
to
d2fa889
Compare
28f7f80
to
b3ee572
Compare
3327572
to
a2ea1c6
Compare
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 |
|
||
env: | ||
global: | ||
- CXX=g++-4.9 | ||
- secure: "VDsxy30sE9ivdqoXkaKXo0czbS4brNpwKEIblu7f1gVLx7OD9pjTc78cdwrVbZDBYroSiYVYuUrLDjpVjH88lL/LxRrru3V0CIlAqqa+ssXcqycCaT/6ds+ZymuTTGRh+Mf12pIKO+yc8jTov2M7AzPJdpS+ORP5dImYyE3ex9s=" | ||
|
||
script: ./test_type_defs.sh |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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\\(([^)]*)\\)?$ |
There was a problem hiding this comment.
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?
There was a problem hiding this 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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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> |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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
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 |
thanks for the review - I broke CI and didn't know about it. The little things you mentioned should be fixed now. |
Does |
Good point! It does fail. |
YOLO |
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
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
I'm using
Flow
withImmutable
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:Iterable
andSeq
are not implemented yetmerge
on maps ignores types when given aESIterable
. It only infers types from plain objects.Map()
) and setting a value on empty object it doesn't correctly infer typesThis might be a flaw of Flow so feel free to point it here.
In f31e5c2 I copied the definition of
$Iterable
toimmutable-js
. I did it for two reasons:$Iterable
is privateTests for
Iterable
andSeq
are not implemented yet. I had some problems implementing tests forIterable
. 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:
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
?