babel/packages/babel-plugin-transform-flow-strip-types
Sam Goldman a40f54f847 Add support for explicit type arguments in new and call expressions (#7934)
* Add all option to babel-plugin-syntax-flow

The Flow parser has some conditional logic based on whether types should
be parsed or not, which is based on either (a) the @flow pragma in the
docblock of the file of (b) the `all` configuration, provided via
command line or .flowconfig.

This commit adds the ability to provide the `all` configuration to
Babel as well, via the syntax-flow plugin. This should be set to `true`
if the project uses all=true.

* Parse @flow pragma

The Flow parser has some conditional logic based on whether types should
be parsed or not, which is based on either (a) the @flow pragma in the
docblock of the file of (b) the `all` configuration, provided via
command line or .flowconfig.

This commit parses the @flow (or @noflow) pragma from the first comment
in the source file. Directives are allowed to appear before the comment.

* WIP: add tests for explicit type arguments

This commit includes tests which have unexpected output, but will change
to the expected output as later commits add parsing support for various
features.

* Parse type arguments in new expressions

* Parse type arguments in call expressions

* Parse optional call expressions with explicit type args

* Add explicit type arguments to babel-types

Flow calls these typeArguments instead of typeParameters, which clearly
separates formal/actual parameters, and mirrors the existing arguments
key.

The existing definitions to support TypeScript also included Flow's
TypeParameterInstantiation node type, which I've moved to the the new
field.

* Add support for explicit type arguments to babel-generator

* Add test for explicit type args to transform-flow-strip-types plugin

* Oops. Forgot to regenerate the babel-types README.

* Fix Flow parser shouldParseTypes() function

I was looking at `options.all`, but the correct property ws
`options.flowAll`. Oops!

* Remove typeapp_call from whitelist of expected failures

Now that Babylon parses this syntax extension, we can remove the
typeapp_call tests from the list of expected differences.

Note that I am using the `flowAll` option, mirroring the behavior of the
Flow tests, which assume types without requiring the `@flow` pragma.

* Use Babylon plugin options instead of parser options

* Parse optional call expressions type arguments unambiguously
2018-05-18 08:05:16 -05:00
..
2017-03-25 21:46:16 -04:00
2018-05-14 17:15:44 -07:00

@babel/plugin-transform-flow-strip-types

Strip all flow type annotations and declarations from your output code.

Example

In

function foo(one: any, two: number, three?): string {}

Out

function foo(one, two, three) {}

Installation

npm install --save-dev @babel/plugin-transform-flow-strip-types

Usage

.babelrc

{
  "plugins": ["@babel/plugin-transform-flow-strip-types"]
}

Via CLI

babel --plugins @babel/plugin-transform-flow-strip-types script.js

Via Node API

require("@babel/core").transform("code", {
  plugins: ["@babel/plugin-transform-flow-strip-types"]
});

Options

requireDirective

boolean, defaults to false.

Setting this to true will only strip annotations and declarations from files that contain the // @flow directive. It will also throw errors for any Flow annotations found in files without the directive.