* Transform initializers with ids in rest elements
Fix issue 11281. Transform parameters with default initializers that
have ids that are also in a parameter with a rest element.
Before, these parameters were not transformed.
* Add plugin-transform-parameters as dependency
* Remove outdated comment
* Use set instead of array for paramsWithRestElement
* Skip when encounter "Scope"
Previously, f({...R}, f = R => R) would be incorrectly transformed.
* Pass in loose mode option instead of false
* Address review and re-organize tests
Checking the RHS of an assignment pattern/checking the parent of
an identifier node fails on cases like "({...R}, a = f(R))" or
"({...R}, {[R.key]: a = 42})".
Also refactor tests by removing unecessary tests and
separating "should transform" from "should not transform" tests.
This reverts commit 43b83f8ed7545b9c049eeed85541fa162842fb8f.
Fix objectSpread helper breaking old codes
remove tests to regenerate later
renamed output
new name
try using word
add comment as requested
revert inline name changes
add 2 for consistency
Update packages/babel-helpers/src/helpers.js
Co-Authored-By: Daniel Tschinder <daniel@tschinder.de>
In https://github.com/babel/babel/issues/9511 (and #9495 is another symptom), @PavelKastornyy reported a node crash becaue the JavaScript heap run out of memory. The problem was that their code was adding enumerable properties to `Object.prototype`: it is something that shouldn't be done, but Babel shouldn't make node crash if someone adds them.
I reduced down the problem to `for...in` loops in `@babel/traverse` that grew the memory consumption exponentially because of that unexpected properties.
* add isSpread field
* use argument
* t.booleanLiteral
* fix typo
* push empty-argument object
* .object
* .value
* object field should be an expression
* lint
* update outputs
* isSpread for the second argument is redundant
* add test
* alternating spread
Prior to this change, we'd conduct an open-ended traversal on the 'id'
of any VariableDeclarator to find a RestElement. The 'id' of
a VariableDeclarator can contain an AssignmentPattern (to supply
a default value), and if the right-hand side of the AssignmentPattern
contained a RestElement, we'd transform it.
The problem here is that the right-hand side of an AssignmentPattern can
be *any* Expression. If the right-hand side is a function body, we'd
traverse the entire function body, and if a RestElement occurred
anywhere in that function body, we'd transform it and emit the
transformations wherever we began the traversal (at least one scope
outside its usage).
The fix is to stop the inner traversal if we encounter an
AssignmentPattern. The outer traversal will still visit the
AssignmentPattern, so RestElements within the right-hand side of an
AssignmentPattern will be properly transformed at that time.
