The following breaks in Flow 0.1.6:
//Flow error: "Property not found in statics of Object"
Object.extend = Object.extend || function(o,srcObj) {
for (var i in srcObj) {
if (srcObj.hasOwnProperty(i)) {
o[i] = srcObj[i];
}
}
return o;
};
Another example, different error message:
//Flow error: "This type is incompatible with the following polymorphic type: function type"
Array.from = Array.from || function(arrayLikeObj) {
return Array.prototype.slice.call(arrayLikeObj);
};
Yeah, polyfilling has been a problem for us too. Our workaround up til now is just to add the methods to the Object definition (Object.assign for example), but the long term solution is for people to be able to extend the core library definitions from user land.
For Array.from I think we already have a definition and it's conflicting with yours. There seems to be a bug flowing a new function to that polymorphic type...we'll look into it.
A workaround for both situations could be something like
var ObjectAlias: any = Object;
ObjectAlias.extend = ObjectAlias.extend || ...;
By the way, I'm happy to take any PR for an ES6 function missing from a library.
@gabelevi that workaround looks like it works for declaring new properties, but not for using them.
Random example:
``` .js
var array: any = Array;
array.prototype.first = array.prototype.first || function() {
return this[0];
};
var a = [0,1,2];
var f = a.first(); // Error: call of method first Property not found in Array
```
I'm afraid all my workarounds are going to be somewhat janky. There are a bunch of things you can do, some of which are cleaner but more work and some of which are grosser but easier.
Of of the cleaner things one could do is to run flow with the --no-flowlib flag, and set up the .flowconfig to read your own version of the lib files. You can grab them from GitHub or from (I think) /tmp/flow_username/ after running flow normally. Then you can add whatever definitions you want.
One of the more gross things you could do is to have helper functions to convert between types. Like maybe something like
// Not 100% sure this intersection type usage would work
// Intersection types (typeA & typeB & ... & typeC) are still somewhat immature
type MyArray<T> = Array<T> & { first: () => T };
function myArray<T>(arr: Array<T>): MyArray<T> {
var ret: any = arr;
return ret;
}
But really I think we need a better way to merge things declared in the core libs and things declared in user libs.
Has there been any progress on this?
@gabelevi Customers might add a lot of plugins to the class prototype. I don't think this is a good solution to tackle such a problem.
Trying to add a subSet function as such: Set.prototype.subSet = … but getting:
[flow] Cannot assign function to Set.prototype.subSet because property subSet is missing in Set [1].