cerxes/babel
3
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Update plugins READMEs from babel.github.io [skip ci] (#4931)

Browse Source
This commit is contained in:
Tommaso
2016-12-02 15:07:16 -08:00
committed by Brian Ng
parent 81575bcdfe
commit 27e201e0e1
24 changed files with 482 additions and 42 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
packages/babel-plugin-transform-runtime/README.md
View File

@@ -1,18 +1,20 @@
# babel-plugin-transform-runtime
Externalise references to helpers and builtins, automatically polyfilling your code without polluting globals.
> Externalise references to helpers and builtins, automatically polyfilling your code without polluting globals. (This plugin is recommended in a library/tool)
NOTE: Instance methods such as `"foobar".includes("foo")` will not work since that would require modification of existing builtins (Use [`babel-polyfill`](http://babeljs.io/docs/usage/polyfill) for that).
## Why?
Babel uses very small helpers for common functions such as `_extend`. By default this will be added to every file that requires it. This duplication is sometimes unnecessary, especially when your application is spread out over multiple files.
This is where the runtime transformer plugin comes in: all of the helpers will reference the module babel-runtime to avoid duplication across your compiled output. The runtime will be compiled into your build.
This is where the `transform-runtime` plugin comes in: all of the helpers will reference the module `babel-runtime` to avoid duplication across your compiled output. The runtime will be compiled into your build.
Another purpose of this transformer is to create a sandboxed environment for your code. If you use [babel-polyfill](https://babeljs.io/docs/usage/polyfill/) and the built-ins it provides such as `Promise`, `Set` and `Map`, those will pollute the global scope. While this might be ok for an app or a command line tool, it becomes a problem if your code is a library which you intend to publish for others to use or if you can't exactly control the environment in which your code will run.
Another purpose of this transformer is to create a sandboxed environment for your code. If you use [babel-polyfill](http://babeljs.io/docs/usage/polyfill/) and the built-ins it provides such as `Promise`, `Set` and `Map`, those will pollute the global scope. While this might be ok for an app or a command line tool, it becomes a problem if your code is a library which you intend to publish for others to use or if you can't exactly control the environment in which your code will run.
The transformer will alias these built-ins to `core-js` so you can use them seamlessly without having to require the polyfill.
See the technical details section for more information on how this works and the types of transformations that occur.
See the [technical details](#technical-details) section for more information on how this works and the types of transformations that occur.
## Installation
@@ -20,9 +22,14 @@ See the technical details section for more information on how this works and the
npm install --save-dev babel-plugin-transform-runtime
```
It is also recommended you install the `babel-runtime` package as a
runtime dependency, if you haven't already, as the transformed code will
require that package. See the examples below for more details.
It is also recommended you install the [babel-runtime](https://www.npmjs.com/package/babel-runtime) package as a runtime dependency, if you haven't already, as the transformed code will require that package. See the examples below for more details.
**NOTE - Production vs. development dependencies**
In most cases, you should install `babel-plugin-transform-runtime` as a development dependency (with `--save-dev`) and `babel-runtime` as a production dependency (with `--save`).
The transformation plugin is typically used only in development, but the runtime itself will be depended on by your deployed/published code.
## Usage