* Pass `dirname` as extra metadata to preset constructor.
Sometimes a preset would like to know where it should resolve relative paths from (e.g. https://github.com/tleunen/babel-plugin-module-resolver) and this extra information makes that possible.
* Test for `dirname` passed into preset constructor
This adds a check for `dirname`’s existence and correctness to the
`resolve-addons-relative-to-file` test, and serves as a minimal example
of a path-aware preset.
When you write
```
for (const x of l) {
setTimeout(() => x);
}
```
we need to add a closure because the variable is meant to be block-scoped and recreated each time the block runs. We do this.
However, we also add the closure when no loop is present. This isn't necessary, because if no loop is present then each piece of code runs at most once. I changed the transform to only add a closure if a variable is referenced from within a loop.
The core package accepts a babelrc option, which if set to false stops
the transforms from using .babelrc and .babelignore files. Document
this option and remove the --no-babelrc CLI flag, referring to the CLI
documentation instead.
[skip ci]
This encapsulates the logic for turning an acceptable preset name into
the absolute path for that preset. It can be used to preprocess a
presets list to map each preset to its absolute path, which is necessary
if `babel.transform` is going to be executed on a file outside the
directory subtree where the presets are installed.
This adds a getPossiblePresetNames helper encapsulating the logic for
what preset names we should try to resolve, and the resolvePreset method
just calls this helper and actually resolves them.
This encapsulates the logic for turning an acceptable plugin name into
the absolute path for that plugin. It can be used to preprocess a
plugins list to map each plugin to its absolute path, which is necessary
if `babel.transform` is going to be executed on a file outside the
directory subtree where the plugins are installed.
This adds a getPossiblePluginNames helper encapsulating the logic for
what plugin names we should try to resolve, and the resolvePlugin method
just calls this helper and actually resolves them.
