profile
viewpoint

cucapra/lambdalab 8

interactive λ-calculus for learning

dsainati1/maxflow 1

An implementation of Ford-Fulkerson/Edmonds-Karp in OCaml

apurvsethi/cs3152group3 0

CS 3152 (Spring 2016) Game

dsainati1/KAT 0

Implementation of an equality checker for two expressions in Kleene Algebra (Final Project for CS 6861)

dsainati1/oauth2orize 0

OAuth 2.0 authorization server toolkit for Node.js.

issue commentfacebook/flow

Type refinement stopped working in 0.125

Yea, the fix is quite complex. We are addressing it as part of a larger set of improvements, but I would not expect it to land soon, unfortunately.

frontendphil

comment created time in 19 days

issue commentfacebook/flow

Flow 0.127.0 broke $FlowFixMe

Apparently the docs have never included any info on this as far as I can tell, so I will work on writing something about errors and suppressions in general.

strager

comment created time in 19 days

issue commentfacebook/flow

Unable to access module with well_formed_exports

@panagosg7 is there a way to allow module access and still be compatible with types first?

charlag

comment created time in 21 days

issue closedflowtype/flow-bin

$FlowFixMe not taken into account anymore in some situations with 0.129.0

Version 0.129.0 reports errors despite $FlowFixMe

For instance:

// $FlowFixMe
delete this._isPlayBack;

reports:

Cannot delete `this._isPlayBack` because  undefined [1] is incompatible with  boolean [2]. Flow(incompatible-type)
myfile.js[864, 3]: [1] undefined
myfile.js[144, 29]: [2] boolean

I have dozens of errors like that on code that was clean since I upgraded to 0.129.0. Am I missing something?

closed time in 21 days

ea167

issue commentflowtype/flow-bin

$FlowFixMe not taken into account anymore in some situations with 0.129.0

Ah I see. This is a deliberate change. Flow added support for error codes in a recent release, and in order to make this possible we had to standardize some of the ways that suppression comments work.

They must be on the line before the error, so having them on the end of the same line doesn't work. The first example also doesn't work because they must be the only comment on their line, and the comment must begin with the $FlowFixMe or $FlowIgnore

ea167

comment created time in 21 days

issue commentflowtype/flow-bin

$FlowFixMe not taken into account anymore in some situations with 0.129.0

Yea the changes were made in the versions between there.

ea167

comment created time in 21 days

issue commentflowtype/flow-bin

$FlowFixMe not taken into account anymore in some situations with 0.129.0

Can you give a specific repro?

ea167

comment created time in 21 days

issue commentfacebook/flow

Generic type not scoped as expected in closure.

This is not exactly a bug, but neither is it the desired behavior. @mvitousek is almost done with a set of changes that should improve the behavior here to be more in line with what you expect. So a "fix" is in the works.

I closed the issue because there is a work-around in the mean time.

jameskerr

comment created time in 21 days

issue commentfacebook/flow

Unable to access module with well_formed_exports

Although I suppose just testing for module properties won't affect the type of the module, so perhaps there is room for leniency here.

charlag

comment created time in 21 days

IssuesEvent

issue closedfacebook/flow

Unable to access module with well_formed_exports

<!-- Please fill out this entire template so that we can address your bug report as quickly as possible.

Any bug reports that don't contain instructions to reproduce the issue will be closed. -->

Flow version:

Expected behavior

Code like this:

let importBase = typeof module !== undefined ? module.id : __module

should be allowed

Actual behavior

module may only be used as part of a legal top level export statement [invalid-export]

<!-- Please reproduce your issue on flow.org/try so that we can debug it.

Not all issues are reproducible on try-flow because they may require multiple files or specific flowconfig settings. If your bug can only be reproduced under one of these constraints, please make a small github repo that contains a minimal way to reproduce your problem. -->

  • Link to Try-Flow or Github repo: https://github.com/tutao/flow-module-export

We (unfortunately) have a lot of such imports in our project and I would not be able to enable types-first without changing it in some way (like with Babel macro). I think it's a part of the bigger issue where you cannot access module properties (or even test for its presence) in any way and I believe it should be allowed. We don't use module.exports anywhere in the flow checked files so we don't even need flow to scan for it, we just need module ID to track imports for hot reloading and it's not possible to do with well_formed_exports.

closed time in 21 days

charlag

issue commentfacebook/flow

Unable to access module with well_formed_exports

well_formed_exports is essentially checking that the type of each module is completely determined by syntax, and does not rely on any code execution, and can thus be inferred statically. Code like you have above violates this assumption, which is why it is an error. This is working as intended

charlag

comment created time in 21 days

issue closedfacebook/flow

Generic type not scoped as expected in closure.

<!-- Please fill out this entire template so that we can address your bug report as quickly as possible.

Any bug reports that don't contain instructions to reproduce the issue will be closed. -->

Flow version: v0.129.0

Expected behavior

The flow documentation about generics makes this claim:

Generic types work a lot like variables or function parameters except that they are used for types. You can use them whenever they are in scope.

In this example, I'd expect the generic "T" type to be to be a string everywhere it is in scope.


function entries<T>() {
  let entries: T[] = []

  return {
    push: (entry: T) => {
      entries.push(entry)
    }
  }
}

let e = entries<string>()

e.push("abc") // <---- ERROR HERE

Actual behavior

This error is given.

    14: e.push("abc")
               ^ Cannot call `e.push` with `"abc"` bound to `entry` because string [1] is incompatible with `T` [2]. [incompatible-call]
        References:
        14: e.push("abc")
                   ^ [1]
        6:      push: (entry: T) => {
                           ^ [2]

<!-- Please reproduce your issue on flow.org/try so that we can debug it.

Not all issues are reproducible on try-flow because they may require multiple files or specific flowconfig settings. If your bug can only be reproduced under one of these constraints, please make a small github repo that contains a minimal way to reproduce your problem. -->

  • Link to Try-Flow or Github repo: https://flow.org/try/#0FAMwrgdgxgLglgewgAgKYRgJzqgzgHgBUA+ACgEpkBvYASABtUY0Ns8AuZQgbQF1kAvMj7A6mJmEwoatWgAcwuABadS6LAE9OhSgOLU6tZMfVtcAOgXK1rDeUMBfOk6fBGzVIJZYcBXD4gAczJ7YFRLRSVSACIAQwAjKGjyIA

closed time in 21 days

jameskerr

issue commentfacebook/flow

Generic type not scoped as expected in closure.

It's good to get in the habit of annotating function types, as it helps Flow infer better types for you. If this makes your code verbose and duplicative, I imagine there are ways you could define generic types to express these that eliminate the code duplication.

jameskerr

comment created time in 21 days

issue commentfacebook/flow

Empty object is valid for non exact type annotation

Agreed. We have wanted to get rid of unsealed objects for a while, the difficulty is devising a new way to support the existing pattern of building up an object over time.

diverpb

comment created time in a month

issue commentfacebook/flow

Docs should be updated for new error suppression mechanisms

Docs were updated in 42de9df5cf38d12b6fc51cb6a50f97b17e053828

lyleunderwood

comment created time in a month

issue closedfacebook/flow

Docs should be updated for new error suppression mechanisms

Upon upgrading to 0.127.0, I received the following error:

.flowconfig:15 Unsupported option specified! (suppress_comment)

I figured this must be a result of the new error suppression stuff, so I figured I would go to flow.org and see what changes I should make to my config to resolve the issue. I found a bunch of documentation that no longer applies:

https://flow.org/en/docs/config/options/#toc-suppress-comment-regex

closed time in a month

lyleunderwood

issue commentfacebook/flow

Empty object is valid for non exact type annotation

Annotating the type of someObj limits what you can do with it. When initializing someObj, you write an unsealed object to the variable, but then tell Flow you only want to allow it to be used as if it is a value of type {id : number}. So the unsealedness of the empty object literal is masked by the fact that you are immediately annotating the value you are assigning it to.

diverpb

comment created time in a month

issue closedfacebook/flow

Can’t assign values to `mixed` when it’s within an Array or Object type

Flow version: v0.128.0

Expected behavior

According to the documentation page Mixed Types, anything can be assigned to mixed:

mixed will accept any type of value. Strings, numbers, objects, functions– anything will work.

That documentation page doesn’t say it should work any different when mixed is inside an array or object. Therefore, the following code, which uses an Array<mixed> type, should pass Flow type checking:

const arrayOfNumbers: Array<number> = [1, 2, 3];
const arrayOfMixed: Array<mixed> = arrayOfNumbers;

Additionally, all of the example code in the “Actual behavior” section should pass Flow type checking.

I know that covariance and contravariance can sometimes cause similar confusion, but I don’t see why it would change my expectations here.

Actual behavior

Flow raises type errors in four of the six paragraphs of code below (demo on Try Flow):

// @flow

// mixed works when it’s a top-level value
const num: number = 3;
const mix: mixed = num;

// mixed FAILS inside array types
const arrayOfNumbers: Array<number> = [1, 2, 3];
const arrayOfMixed: Array<mixed> = arrayOfNumbers;

// mixed FAILS inside object types
const personWithNumberAge: { age: number } = { age: 55 };
const personWithMixedAge: { age: mixed } = personWithNumberAge;

// mixed FAILS inside indexed object types
const stringsToNumbers: { [string]: number } = { "a": 1, "b": 2 };
const stringsToMixed: { [string]: mixed } = stringsToNumbers;

// mixed FAILS inside indexed object types as function parameters (my use-case)
function withStringsToMixed(obj: { [string]: mixed }): Array<string> {
  return Object.keys(obj);
}
withStringsToMixed(stringsToNumbers);

// generics work inside indexed object types
function withStringsToGeneric<T>(obj: { [string]: T }): Array<string> {
  return Object.keys(obj);
}
withStringsToGeneric(stringsToNumbers);

The type errors are of this form:

Cannot assign somethingContainingNumbers to somethingContainingMixed because number [1] is incompatible with mixed [2] in [some container]. [incompatible-type]

All four errors that Flow raises for the above example code:

    9: const arrayOfMixed: Array<mixed> = arrayOfNumbers;
                                          ^ Cannot assign `arrayOfNumbers` to `arrayOfMixed` because number [1] is incompatible with mixed [2] in array element. [incompatible-type]
        References:
        8: const arrayOfNumbers: Array<number> = [1, 2, 3];
                                       ^ [1]
        9: const arrayOfMixed: Array<mixed> = arrayOfNumbers;
                                     ^ [2]
    13: const personWithMixedAge: { age: mixed } = personWithNumberAge;
                                                   ^ Cannot assign `personWithNumberAge` to `personWithMixedAge` because number [1] is incompatible with mixed [2] in property `age`. [incompatible-type]
        References:
        12: const personWithNumberAge: { age: number } = { age: 55 };
                                              ^ [1]
        13: const personWithMixedAge: { age: mixed } = personWithNumberAge;
                                             ^ [2]
    17: const stringsToMixed: { [string]: mixed } = stringsToNumbers;
                                                    ^ Cannot assign `stringsToNumbers` to `stringsToMixed` because number [1] is incompatible with mixed [2] in the indexer property. [incompatible-type]
        References:
        16: const stringsToNumbers: { [string]: number } = { "a": 1, "b": 2 };
                                                ^ [1]
        17: const stringsToMixed: { [string]: mixed } = stringsToNumbers;
                                              ^ [2]
    23: withStringsToMixed(stringsToNumbers);
                           ^ Cannot call `withStringsToMixed` with `stringsToNumbers` bound to `obj` because number [1] is incompatible with mixed [2] in the indexer property. [incompatible-call]
        References:
        16: const stringsToNumbers: { [string]: number } = { "a": 1, "b": 2 };
                                                ^ [1]
        20: function withStringsToMixed(obj: { [string]: mixed }): Array<string> {
                                                         ^ [2]

The last paragraph of my code example, “generics work inside indexed object types”, shows that this issue can be worked around by adding an unused generic parameter to the function. This workaround is only possible if the mixed-containing type is a parameter to the function, not if it’s a local variable.

For comparison, when I try writing equivalent code in TypeScript by changing mixed to unknown, TypeScript raises no errors. I know that Flow and TypeScript are not always directly comparable, though, since their type systems differ in a few ways.

closed time in a month

roryokane

issue commentfacebook/flow

Suggestion: Add $FlowIgnore to the standardized suppression comments

I'd happily accept a PR adding this feature.

noppa

comment created time in 2 months

issue commentfacebook/flow

Type refinement stopped working in 0.125

declare function foo(x : number) : string;
declare function foo(x : string) : number;

function foo(x) {
  ... definition goes here
}

Something like this. Here, if foo is given a number Flow will know it returns a string, and vice versa.

frontendphil

comment created time in 2 months

issue commentfacebook/flow

Type refinement stopped working in 0.125

The fix for this is quite complex and might not be able to come out before the planned rework of utility types planned for this year. Is it possible to rewrite this code to avoid the use of $ElementType? You might try overloading the definition of this function instead?

frontendphil

comment created time in 2 months

issue commentfacebook/flow

String is not a valid ComponentType

What you are looking for is React.ElementType which is the type of all things that can be inputs to a React element (strings and components).

danielo515

comment created time in 3 months

issue closedfacebook/flow

String is not a valid ComponentType

Hello I creating a component that takes a component to render as props. However, it's being impossible for me to type that it can accept both react components and default components (those defined by strings). Flow says that string is not a valid type for ComponentType

// @flow
import * as React from "react";


type Props = {
  component: React.ComponentType<*>
}
  
const Bla = ({component: C }: Props) => <C/>

Bla.defaultProps = {
  component: 'div'
}

const x = <Bla/>

Flow version: 0.125.1

Expected behavior

I expect string to be a valid component

Actual behavior

Only react components can be used

  • Link to Try-Flow or Github repo: https://flow.org/try/#0PTAEAEDMBsHsHcBQBLAtgB1gJwC6gFSgCGAzqAEoCmRAxnpFrKqAERbV0sDcivOAnukqgACo3RkAvKADeiUKBpNMAO0oqcALgoccAOgDCy2Go0AVQZQA8+AHyIAvvNCIlKkngBC0IqGkAKGSUME3UtUANQB20xWAkASj9bUCsDYHtEbyI9ABNKSCIAV2gcWIk-WWdg1TDtAHIc5AA3OsdeNw9QAA8Kqyz0oA

closed time in 3 months

danielo515

issue commentfacebook/flow

Type refinement stopped working in 0.125

Good catch. Working on a fix

frontendphil

comment created time in 3 months

issue closedfacebook/flow

empty type is treated as any

Flow version: 0.125.1

Expected behavior

empty to behave like mixed (does not cast to anything only refinements are allowed)

Actual behavior

empty is basically alias to any

code

declare var nothing: empty
declare var something: 'cotne'

declare function giveMeNumber(number): void


giveMeNumber(1)// ok
giveMeNumber('cotne')// error as expected

giveMeNumber(nothing)// should error

if (something !== 'cotne') {
  giveMeNumber(something)// should error
}

Try

closed time in 3 months

thecotne

issue commentfacebook/flow

empty type is treated as any

In this case empty is behaving as designed, that is to say, the exact opposite way as mixed. In Flow, mixed is the top type, the supertype of all other types. This means you cannot assume anything about its contents, but can create it from any value. For example, all of the following are legal: let x : mixed = 3, let x : mixed = {} and let x : mixed = () => {}, while all of the following are errors (assuming x has type mixed): x.foo, x() and x = x + 1. Put another way, you can write anything to a mixed value, but cannot read anything from it.

empty has the opposite behavior: it is the bottom type in Flow, the subtype of all other types. It is impossible to create, but if you obtain a value of type empty, you can do anything with it. So to contrast with the examples above, all of the following are errors: let x : empty = 3, let x : empty = {} and let x : empty = () => {}, while all of the following (assuming x has type empty) are legal: x.foo, x() and x = x + 1. Reading and writing empty are dual to mixed, you can read anything from an empty value, but cannot write anything to it.

In the example above, you can call giveMeNumber inside that refinement because Flow knows that the if statement will never succeed, so the code inside is dead; dead code is one of the only sources of empty in Flow. As such, the above code won't error because that function won't even get called.

As an aside, the reason any is an unsafe type is because it combines the permissibility of writing to mixed and reading from empty: you can put anything into an any value, and do anything you want with it.

thecotne

comment created time in 3 months

more