| Q | A <!--(Can use an emoji 👍) -->
| ------------------------ | ---
| Fixed Issues? |
| Patch: Bug Fix? |
| Major: Breaking Change? |
| 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 `all` option landed in https://github.com/babel/babel/pull/7934/files#diff-3a8233bcd2766d2c7d87f23f944f7726R3 but it is only exposed from the plugin, not the preset, so this exposes it there too since the flow preset is what we want people to use.
* Revert "Move subclass inheritance to end (#7772)"
This reverts commit f8ab9466d331871a90f458af40b14e8d831e0c29.
* Only use getPrototypeOf if setPrototypeOf is implemented
* Update fixtures
* Helpers updates
* Update fixtures
* Fall back to getPrototypeOf
* Update fixtures
<!--
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
