* 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
* Support internalSlots to babel-types and babel-generator
* Parsing support for internal slot properties
* Print internal slots in babel-generator
* Add whitespace before first internal slot property
* Add support for plugin options in Babylon
They work similarly to how they work in Babel. e.g.
babylon.parse({
options: [
"plugin1",
["plugin2", { option: true }]
]
});
The inernal api to get an option is
this.getPluginOption("pluginName", "option")
If the plugin isn't defined, it returns undefined.
* Add Babylon option decorators.secoratorsBeforeExport
* Nit
* drop support for Node.js v4; closes#7753
- remove version 4 from Travis build matrix
- update environment support doc
- update `CONTRIBUTING.md`
- update `engines` field of root `package.json`
Signed-off-by: Christopher Hiller <boneskull@boneskull.com>
* update engines for babylon
Signed-off-by: Christopher Hiller <boneskull@boneskull.com>
* Update decorators parsing
This commit introduces three changes:
1) Class properties can be decorated
2) Decorators can contain arbitrary expressions, using @(...)
3) The Decorator node type has a new property, "arguments". This
makes it possible do distinguish @dec() and @(dec()), which have
different behaviors because @(dec()) is equivalent to @(dec())().
* Rename Decorator#expression to Decorator#callee
* Add test for @dec()()
* Update test262 and whitelist
* Use test262-stream
* Check escapes in contextual keywords
* Check escapes when parsing new.target
* Check escapes for getters/setters
* Check escapes for static class methods
* Check escapes on async arrow and functions
