Since nodejs/node@08085c49b6, which will be part of Node.js v6.0,
functions from the `path` core module (like `dirname`) will require
their input to be a string.
Currently, at some points in the code they might be called
with `undefined`; This patch adds `… || ""` so that the input
is always a string.
For `path.dirname` in the babel-core file, this does not change
behaviour, since
`path.dirname(undefined) === path.dirname("") === "."` (where the
first expression is only defined for Node.js ≤ v5.x).
For `path.basename`, this changes the return value, since
`path.basename(undefined) === "undefined"` (on Node.js ≤ v5.x), but
`path.basename("") === ""`. However, it seems reasonable to assume
that, due to the trailing expression in
`path.basename(…) || "stdout"`, the current behaviour is not actually
the intended one.
There are possibly more places in the code base where similar changes
may be neccessary; However, these suffice to make the tests pass
and un-break the build of at least one external project when using
the current Node.js master branch.
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.
