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>
### `@babel/runtime`
- Added `@babel/runtime-corejs3` package and `corejs: 3` options to `@babel/plugin-transform-runtime`.
- Added support of instance methods, fixes#8928.
- Added flag `proposals` (in `corejs: { version: 3, proposals: true }` format) for support all proposals polyfills from `core-js`.
- Used separate directories in runtime for `core-js` entry points with proposals and without.
- Used `get-iterator-method` helper for getting iterators, fixes#2500.
- As a cheap bonus, added support of IE8- (except some cases of `regenerator`).
### `@babel/polyfill`
- Should be deprecated in favor of separate usage required features from `core-js` and `regenerator-runtime` with an informative message.
### `@babel/preset-env`
- Uses for built-ins data from [`core-js-compat`](https://github.com/zloirock/core-js/tree/master/packages/core-js-compat) instead of `compat-table` since information from `compat-table` [is not enough](https://github.com/zloirock/core-js/tree/master/packages/core-js-compat).
- `useBuilIns` now requires direct setting of `corejs` version option, without it will be used `2` by default and shown deprecation warning.
- Added support of minor `core-js` versions for simplify updating in the future.
- For preventing some order-related problems, polyfills in the both `core-js@3` plugins added on `post` stage in the order of `core-js-compat` data.
- Divided plugins and polyfills parts of `preset-env`, instead of 2 internal plugins for adding polyfills, we have 6: usage and entry versions of plugins for `core-js@2`, ### Current state:
`core-js@3`, `regenerator-runtime`.
- Added support `samsung` target (for Samsung Internet) since `core-js-compat` and `compat-table` now contains mapping for this, fixes#6602.
#### `useBuilIns: entry` with `corejs: 3`
- No longer transforms `@babel/polyfill`.
- Transforms **all possible** `core-js` entry points to import of related modules (based on data from [`core-js-compat`](https://unpkg.com/core-js-compat@3.0.0-beta.15/entries.json)).
- Since of this, we no longer need `shippedProposals` / `proposals` flags with `useBuilIns: entry`.
- Removes `regenerator-runtime/runtime` import where it's not required.
#### `useBuilIns: usage` with `corejs: 3`
- In addition to `shippedProposals`, added flag `proposals` (in `corejs: { version: 3, proposals: true }` format) for polyfill all proposals from `core-js`.
- Fixed list of dependencies in built-in definitions.
- Improved the way of determination method / built-in name and source of this method.
- Adds import of required polyfills on `MemberExpression`, `ObjectPattern`, `in` operator.
- Adds import of required polyfills on access to global object properties.
- Adds import of all required common iterators on all syntax features which use iterators protocol (`for-of`, destructuring, spread, `yield` delegation, etc.).
- Adds import of promises on syntax features which use promises (async functions/generators, dynamic import, etc.), fixes#9250, #7402, etc.
### `core-js@2` stuff
I didn't want to tough `core-js@2`-related stuff, however
- Fixed some serious errors in definitions which breaks `Object.getOwnPropertySymbols`, `Symbol.toStringTag` logic, `Promise#finally`, `Array#forEach`, etc.
- `Array#flatMap` and trim methods moved to stable features as a part of ES2019 and loaded by deprecated `@babel/polyfill` and `@babel/preset-env` with `corejs: 2` option.
* 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.
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)
