<!--
Before making a PR please make sure to read our contributing guidelines
https://github.com/babel/babel/blob/master/CONTRIBUTING.md
For any issue references: Add a comma-separated list of a [closing word](https://help.github.com/articles/closing-issues-via-commit-messages/) followed by the ticket number fixed by the PR
-->
| Q | A <!--(yes/no) -->
| ------------------------ | ---
| Patch: Bug Fix? |
| Major: Breaking Change? |
| Minor: New Feature? | y
| Deprecations? |
| Spec Compliancy? |
| Tests Added/Pass? | y/y
| Fixed Tickets | #5616
| License | MIT
| Doc PR | <!-- if yes, add `[skip ci]` to your commit message to skip CI builds -->
| Dependency Changes |
<!-- Describe your changes below in as much detail as possible -->
Once merged I will make the corresponding documentation changes on the website (in a 7 branch)
| Q | A <!--(Can use an emoji 👍) -->
| ------------------------ | ---
| Fixed Issues? | Fixes#8001
| Patch: Bug Fix? | Y
| Major: Breaking Change? | Not unless things were relying on a very specific AST structure as output
| Minor: New Feature? |
| Tests Added + Pass? | Yes
| Documentation PR | <!-- If so, add `[skip ci]` to your commit message to skip CI -->
| Any Dependency Changes? |
| License | MIT
The filed bug was for `-0`, but I also realize that `numericLiteral` also shouldn't be getting `-Infinity`/`Infinity` or `NaN` since those just get stringified with the JS-standard stringification logic which means we get a reference to `NaN` or `Infinity` identifiers, which could have been shadowed in a local scope and thus not be the right value. I've avoided that by generating `NaN` as `0/0` and the infinity values as `1/0` and `-1/0`.
| Q | A <!--(Can use an emoji 👍) -->
| ------------------------ | ---
| Fixed Issues? |
| Patch: Bug Fix? | Y
| Major: Breaking Change? | N
| Minor: New Feature? |
| Tests Added + Pass? | Yes
| Documentation PR | <!-- If so, add `[skip ci]` to your commit message to skip CI -->
| Any Dependency Changes? |
| License | MIT
Currently the `opts.filename` value exposed to plugins is just whatever the user passed. While it _could_ be relative to the working directory, if Babel was passed an absolute URL, it'll be absolute.
This PR explicitly ensures the filename is a relative path based on the working directory. This also exposes an officially endorsed API for reading the working directory path.
* Update member-expression-to-functions
1. Babel using British spellings, so `memoise`
2. Provide a helper `AssignmentMemoiser` class, which will assign the memo'd value with the `n`th access.
* Private properties!
* Fixes
* Tests
* Update helper name
* Fix privates that reference other privates
* Don't extend a builtin
* Rebase
Follow-up to https://github.com/babel/babel/pull/7404
There is no TypeParameter type in the Babylon TypeScript AST hierarchy.
Flow does have a TypeParameter type, but it should not be confused with
the TypeScript TSTypeParameter, since Flow !== TypeScript, and the types
have totally different fields. Instead, the .typeParameter.type of a
Babylon-parsed TSInferType node should be TSTypeParameter.
It would probably be fine to leave the declared type of the TSInferType
.typeParameter field as TSType instead of TSTypeParameter, but the more
specific TSTypeParameter type should be safe/correct, since the TypeScript
parseInferType function always uses SyntaxKind.TypeParameter:
66d6e5e6e0/src/compiler/parser.ts (L3006)
I noticed this typo because it has been causing ast-types test failures
lately, e.g. https://travis-ci.org/benjamn/ast-types/jobs/369634972
* 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
* Remove second wrapper from _wrapNativeSuper
* Fix tests on node 4
I DON'T KNOW WHY IT WORKS.
* Update fixtures
* Use Reflect.construct
* Parens
* Fix things
* Fix things
* Undo changes
* Fix with sham
* Typo
* 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
