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] Parsing error when calling generic functions with type arguments when flow pragma is not first comment #9240

Closed
FermiDirak opened this issue Dec 26, 2018 · 13 comments

Comments

Projects
None yet
9 participants
@FermiDirak
Copy link

commented Dec 26, 2018

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.

// 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

This comment has been minimized.

Copy link
Collaborator

commented Dec 26, 2018

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

This comment has been minimized.

Copy link

commented Feb 4, 2019

@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

This comment has been minimized.

Copy link

commented Feb 18, 2019

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

This comment has been minimized.

Copy link
Member

commented Feb 18, 2019

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

This comment has been minimized.

Copy link

commented Feb 18, 2019

@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

This comment has been minimized.

Copy link
Member

commented Feb 18, 2019

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

@existentialism

This comment has been minimized.

Copy link
Member

commented Feb 18, 2019

@pwlmaciejewski

This comment has been minimized.

Copy link

commented Feb 18, 2019

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

This comment has been minimized.

Copy link
Member

commented Apr 10, 2019

Looks like this is probably because of

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

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

This comment has been minimized.

Copy link

commented Apr 12, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Apr 22, 2019

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

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

This comment has been minimized.

Copy link
Contributor

commented Apr 22, 2019

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

This comment has been minimized.

Copy link
Member

commented May 4, 2019

Fixed by #9891

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.