[flow] Parsing error when calling generic functions with type arguments when flow pragma is not first comment

[FermiDirak]

Bug Report

Current Behavior
When the @flow pragma is not specified as the first comment of a JS or JSX file, babel parser will not be able to parse any code that passes type arguments.

Input Code

// arbitrary comment
// @flow

const n: number = 5; // this works fine

const set = new Set<number>([1, 2, 3]);
        // unexpected token^

Expected behavior/code
Flow should be able to parse functions that are called with type arguments so long as the @flow pragma exists before any code.

Babel Configuration (.babelrc)

{
  presets: [
    "@babel/preset-env",
    "@babel/preset-react",
    "@babel/preset-flow",
  ]
}

Environment

• Babel version: [^7.0.0]
• Node/npm version: [Node 8.11.1]
• OS: [OSX 10.13.4]
• Monorepo: [yes]
• How you are using Babel: [loader]

Possible Solution

It appears this line ignores the flow pragma if it isn't found in the first comment of the source file.

babel/packages/babel-parser/src/plugins/flow.js

Line 77 in c586d4e

// to "@flow" or "@noflow" if we see a pragma. Transitions to null if we are

This could be changed a-la Flow-Strip-Types, which first checks all comments for a flow pragma before it begins transforming. (https://github.com/babel/babel/blob/c586d4e8cac816941bf2ba559472fd9cc3150921/packages/babel-plugin-transform-flow-strip-types/src/index.js). Perhaps a solution like this could be used here as well.

[babel-bot]

Hey @FermiDirak! We really appreciate you taking the time to report an issue. The collaborators
on this project attempt to help as many people as possible, but we're a limited number of volunteers,
so it's possible this won't be addressed swiftly.

If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack
community that typically always has someone willing to help. You can sign-up here
for an invite.

[JakubRimal]

@FermiDirak Thank you very much, you saved me at least a few hours as without seeing this issue I would never guess that the problem is because of a position of the @flow... 😮 😃

[pwlmaciejewski]

I'm experiencing the same issue with flow enabled by default on all files:

// .flowconfig
[options]
all=true

Adding @flow pragma in the first line of the throwing files fixes fixes it.

[nicolo-ribaudo]

Babel doesn't read your .flowconfig file. You can add the "all": true option to the flow preset (or plugin) in your Babel config.

[pwlmaciejewski]

@nicolo-ribaudo yes, but afaik babel-preset-flow doesn't expose any options, or at least they are not documented here: https://babeljs.io/docs/en/babel-preset-flow.

It comes with babel-plugin-transform-flow-strip-types that has requireDirective option set to false by default. If I get it correctly, it should strip the types out of the box. Or maybe babel-plugin-transform-flow-strip-types has nothing to do with this error?

[nicolo-ribaudo]

That preset taks an "all": boolean option (and also the plugin). It's a documentation bug.

[existentialism]

Ref: babel/website#1973

[pwlmaciejewski]

Thanks, @nicolo-ribaudo, it works 👍

In my case it was babel-preset-expo that uses flow-strip-types, but this one does the trick:

overrides: [{
    plugins: [
        ['@babel/plugin-transform-flow-strip-types', {all: true}],
    ]
}]

[loganfsmyth]

Looks like this is probably because of

babel/packages/babel-parser/src/plugins/flow.js

Line 103 in 165ef29

this.flowPragma = null;

which will set flowPragma to null for the first comment it sees, meaning that it will never try to process later comments.

That line should just be removed since the logic in

babel/packages/babel-parser/src/plugins/flow.js

Line 1601 in 165ef29

this.flowPragma = null;

is supposed to handle that. That said, I'm not sure this parseStatement call is actually a good place for it, or at least we want to make sure that code like

(/* @flow */ 42);

also doesn't count (I assume), but that comment isn't after any statement has finished.

[julienw]

Just a quick note that this affects prettier as well, because prettier uses babel to parse JS files by default. Setting prettier's parser to babel-flow works but has issues as well when we want to use prettier for different file types (eg JS and CSS).

[tanhauhau]

after some investigation on the flow's source code, i noticed that the logic babel used to determine whether a file is deemed a "flow" file is different than flow's implementation

Basically, in flow, it

• check docblock_max_tokens tokens, which is default to 10, to look for any sign of comments that matches @flow comment
  • if it encounter any other token than CommentToken, it will early exit
    • with the exception of strings and semicolons, which they assume would be "use strict";

in babel-parser flow-plugin, we look for

• first comment
  • if it is a flow comment, deemed as flow file
  • if it is not, deemed as not a flow file

one edge case for this logic would be

a<x>(y);
// @flow
a<x>(y);

babel repl

anything before the first flow comment would be parsed as non-flow js, and anything after it would be treated as flow, eg: first statement treated as BinaryExpression, and second statement as CallExpression with TypeParameterInstantiation.

[tanhauhau]

I would like to contribute to fix this behavior, by adding a similar max_header_tokens options to flow syntax, just like what we did with all

I've started with some test cases and boilerplates, #9885, but I am not sure on how to lookahead and parse the first n tokens,

[nicolo-ribaudo]

Fixed by #9891