I previously tried an approach to scope bindings from var to scope but
it didn't catch all cases. This is evident in this bug:
https://phabricator.babeljs.io/T2892
Where even after transforming a const to a var we still get an error
that it's read-only.
This approach will go through and delete every existing let and const
binding and creates a new one with the kind "var"
Original PR: https://github.com/babel/babel/pull/2469. Seems this got
lost in the v6 changes.
- - -
Without this, the only way to replace the arrow function is to either
manually override its `node.body`, or duplicate the arrow:
```js
// Old
ArrowFunctionExpression: function (node) {
node.body = t.blockStatement(...);
// Or
return t.ArrowFunctionExpression(
node.params,
t.blockStatement(...),
node.async
);
}
// New
ArrowFunctionExpression: function() {
this.get("body").replaceWith(t.blockStatement(...));
}
```
Given the following `.babelrc`:
```
{
"plugins": ["./myPluginDir/somePlugin.js"]
}
```
Babel should resolve that plugin relative to the directory that contains the `.babelrc` file.
Currently, Babel is resolving the plugin relative to the current `process.cwd()`, as you can see in this test case: https://github.com/skevy/babel-plugin-resolution-test-case
This is occurring because the "fake" `Module` that we're creating in the `resolve` helper doesn't have an `id` and `filename`. Therefore, Node builds an array of paths that contains a number of node_module paths as well as `.`, and doesn't contain the path in which we'd actually like to look up the plugin. `.` of course resolves to the current `process.cwd()`, and thus makes the Babel plugin resolution mechanism quite fragile. The relevant code in Node.JS can be found here (tagged at the v5.4.1 release): ff99203724/lib/module.js (L236-L242).
This PR adds `id` and `filename` to that fake `Module` in order to resolve this issue.
This introduces "pass per preset" feature, spawting a new traversal for each preset in case if the `passPerPreset` is `true` (default is `false`). This gives opportunity to define "before" and "after" presets, mimicking a similar feature from Babel 5. A rationally for this is to make plugins as short as possible, and handled only needed nodes, not afrading potential collisions in case if presets are merged.
