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.
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.
As a follow up from #3145 we agreed to add a new format that is a
superset of the compact format option. Do things that are considered
dangerous. e.g. not printing semicolons, or print literal values
as opposed to raw values.
`generatedPositionFor` accepts a position in one of the sourcemap's *input* source files. Therefore the `source` path
should be one of the sourcemap's input `sources`, not the output `file`.
- Drops input mappings that cannot be mapped through Babel's sourcemap
- For example, Babel's sourcemap does not have mappings for leading comments, so any mapping from an input sourcemap for those leading comments must be dropped from the merged sourcemap
Removed `@flow` annotation from files that don't actually pass Flow check at the moment. These will be added back file by file once the files are properly converted to use Flow.
Closes#3064
In the current state, when the inputSourceMap has multiple sources, all the generated source map will point to the first file. Use the mapping's source instead.
