* 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 failing test case demonstrates a regression between 7.0.0-beta.38 and
7.0.0-beta.39 in the @babel/plugin-proposal-object-rest-spread package.
I distilled this test case from a larger configuration of plugins in my
application, one of which calls api.traverse.cache.clearScope(). Although
calling clearScope() is an uncommon thing for a plugin to do, it was a
reliable way to reproduce the problem. If I can find other reliable
reproductions, I'll push some additional failing tests to this PR.
Regardless of how common it is, clearing the scope cache should be a safe
operation that only slows down the transform (because scopes have to be
recreated and re-crawled). Crashing due to a spurious duplicate
declaration seems like a bug worth fixing.
My hunch is that [these two lines](eb38ea2b10/packages/babel-plugin-proposal-object-rest-spread/src/index.js (L75-L76))
(which were changed in `7.0.0-beta.39`) are not actually removing the
original rest element as a binding from the enclosing `Scope`, in certain
circumstances, so the new variable declaration ends up colliding with the
old (removed) binding.
Possibly related: #7304 (reported by @julien-f)
