This is much like Babylon's existing behavior around `expected.json`. The equivalent of babel/babylon#188 is already applied here, to guard against silent failure (and a potential false positive) if a test is accidentally committed without its expected.js.
This encapsulates the logic for turning an acceptable preset name into
the absolute path for that preset. It can be used to preprocess a
presets list to map each preset to its absolute path, which is necessary
if `babel.transform` is going to be executed on a file outside the
directory subtree where the presets are installed.
This adds a getPossiblePresetNames helper encapsulating the logic for
what preset names we should try to resolve, and the resolvePreset method
just calls this helper and actually resolves them.
This encapsulates the logic for turning an acceptable plugin name into
the absolute path for that plugin. It can be used to preprocess a
plugins list to map each plugin to its absolute path, which is necessary
if `babel.transform` is going to be executed on a file outside the
directory subtree where the plugins are installed.
This adds a getPossiblePluginNames helper encapsulating the logic for
what plugin names we should try to resolve, and the resolvePlugin method
just calls this helper and actually resolves them.
* Increase test coverage
* Test for error when binding `this` in destructuring pattern
* Ignore coverage of inAsync check in parseAwait - already checked externally
* Ignore coverage of default case in checkPropClash
* Remove unused parameter isAsync from parseParenAndDistinguishExpression
* Ignore coverage of an `else` branch in flowParseTypeParameterDeclaration
* Flow: remove unused parameters to flowParseTypeAnnotatableIdentifier
* Flow: ignore coverage of pass-through throw statement in parseConditional
* Flow: Add test for error on property with type param
* Flow: ignore coverage of pass-through throw statements in parseMaybeAssign, parseArrow
* Add test for error on XML-style comment in module code
* Update test for error on method in object pattern
* Test for error: "Only '=' operator can be used for specifying default value"
* Property variance type annotations for Flow plugin
Non-method properties and indexers of object types, declare class, and
interfaces can be "positive" or "negative." Class fields, but again not
methods, can also have variance.
This PR generalizes the variance annotations for type parameters into a
new node type, and reuses that node for those properties.
The code for object types is reused for interfaces and declare classes.
The changes there are straightfoward.
The code for class fields is reused for object literals, which do not
support variance annotations (currently). This code is a bit sketchy,
because we always parse variance annotations in the `parsePropertyName`
extension, then error in a the subsequent parse phase for object
literals (`parseObjPropValue`) or class methods (`parseClassMethod`).
* Remove bogus unreachable code, clarify variance parsing conditional
* Don't use a new node type for variance annotations
Adding a new node type, specifically changing the TypeParameter node's
variance property to be node-valued, is a breaking change. We might
choose to make this breaking change in a later version.
* s/start/variancePos
Expanding on #150, this allows `unexpected()` to accept the expected token type instead of a message string.
This overload is then used in a couple more places (that independently implement a logic similar to `expect()`'s) to construct an `Unexpected token, expected FOO` message.
* Consolidate contiguous var declarations in destructuring transform
Fixes#3081.
* Simplify var node coalescing in es2015-destructuring
* Revert "Simplify var node coalescing in es2015-destructuring"
This reverts commit 15cb373f0726f68225f7080a7ae206a63af174ee.
* More careful condition for var coalescing in es2015-destructuring
