{
  "name": "babel-plugin-transform-runtime",
  "version": "6.23.0",
  "description": "Externalise references to helpers and builtins, automatically polyfilling your code without polluting globals",
  "repository": {
    "type": "git",
    "url": "https://github.com/babel/babel/tree/master/packages/babel-plugin-transform-runtime"
  },
  "license": "MIT",
  "main": "lib/index.js",
  "keywords": [
    "babel-plugin"
  ],
  "dependencies": {
    "babel-runtime": "^6.22.0"
  },
  "devDependencies": {
    "babel-helper-plugin-test-runner": "^6.22.0"
  },
  "readme": "# babel-plugin-transform-runtime\n\n> Externalise references to helpers and builtins, automatically polyfilling your code without polluting globals. (This plugin is recommended in a library/tool)\n\nNOTE: 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).\n\n## Why?\n\nBabel 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.\n\nThis 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.\n\nAnother 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.\n\nThe transformer will alias these built-ins to `core-js` so you can use them seamlessly without having to require the polyfill.\n\nSee the [technical details](#technical-details) section for more information on how this works and the types of transformations that occur.\n\n## Installation\n\n**NOTE - Production vs. development dependencies**\n\nIn most cases, you should install `babel-plugin-transform-runtime` as a development dependency (with `--save-dev`).\n\n```sh\nnpm install --save-dev babel-plugin-transform-runtime\n```\n\nand `babel-runtime` as a production dependency (with `--save`).\n\n```sh\nnpm install --save babel-runtime\n```\n\nThe transformation plugin is typically used only in development, but the runtime itself will be depended on by your deployed/published code. See the examples below for more details.\n\n## Usage\n\n### Via `.babelrc` (Recommended)\n\nAdd the following line to your `.babelrc` file:\n\n```js\n// without options\n{\n  \"plugins\": [\"transform-runtime\"]\n}\n\n// with options\n{\n  \"plugins\": [\n    [\"transform-runtime\", {\n      \"helpers\": false, // defaults to true\n      \"polyfill\": false, // defaults to true\n      \"regenerator\": true, // defaults to true\n      \"moduleName\": \"babel-runtime\" // defaults to \"babel-runtime\"\n    }]\n  ]\n}\n```\n\n### Via CLI\n\n```sh\nbabel --plugins transform-runtime script.js\n```\n\n### Via Node API\n\n```javascript\nrequire(\"babel-core\").transform(\"code\", {\n  plugins: [\"transform-runtime\"]\n});\n```\n\n## Technical details\n\nThe `runtime` transformer plugin does three things:\n\n* Automatically requires `babel-runtime/regenerator` when you use generators/async functions.\n* Automatically requires `babel-runtime/core-js` and maps ES6 static methods and built-ins.\n* Removes the inline babel helpers and uses the module `babel-runtime/helpers` instead.\n\nWhat does this actually mean though? Basically, you can use built-ins such as `Promise`, `Set`, `Symbol` etc as well use all the Babel features that require a polyfill seamlessly, without global pollution, making it extremely suitable for libraries.\n\nMake sure you include `babel-runtime` as a dependency.\n\n### Regenerator aliasing\n\nWhenever you use a generator function or async function:\n\n```javascript\nfunction* foo() {\n\n}\n```\n\nthe following is generated:\n\n```javascript\n\"use strict\";\n\nvar _marked = [foo].map(regeneratorRuntime.mark);\n\nfunction foo() {\n  return regeneratorRuntime.wrap(function foo$(_context) {\n    while (1) switch (_context.prev = _context.next) {\n      case 0:\n      case \"end\":\n        return _context.stop();\n    }\n  }, _marked[0], this);\n}\n```\n\nThis isn't ideal as then you have to include the regenerator runtime which\npollutes the global scope.\n\nInstead what the `runtime` transformer does it compile that to:\n\n```javascript\n\"use strict\";\n\nvar _regenerator = require(\"babel-runtime/regenerator\");\n\nvar _regenerator2 = _interopRequireDefault(_regenerator);\n\nfunction _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { default: obj }; }\n\nvar _marked = [foo].map(_regenerator2.default.mark);\n\nfunction foo() {\n  return regeneratorRuntime.wrap(function foo$(_context) {\n    while (1) switch (_context.prev = _context.next) {\n      case 0:\n      case \"end\":\n        return _context.stop();\n    }\n  }, _marked[0], this);\n}\n```\n\nThis means that you can use the regenerator runtime without polluting your current environment.\n\n### `core-js` aliasing\n\nSometimes you may want to use new built-ins such as `Map`, `Set`, `Promise` etc. Your only way\nto use these is usually to include a globally polluting polyfill.\n\nWhat the `runtime` transformer does is transform the following:\n\n```javascript\nvar sym = Symbol();\n\nvar promise = new Promise;\n\nconsole.log(arr[Symbol.iterator]());\n```\n\ninto the following:\n\n```javascript\n\"use strict\";\n\nvar _getIterator2 = require(\"babel-runtime/core-js/get-iterator\");\n\nvar _getIterator3 = _interopRequireDefault(_getIterator2);\n\nvar _promise = require(\"babel-runtime/core-js/promise\");\n\nvar _promise2 = _interopRequireDefault(_promise);\n\nvar _symbol = require(\"babel-runtime/core-js/symbol\");\n\nvar _symbol2 = _interopRequireDefault(_symbol);\n\nfunction _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { default: obj }; }\n\nvar sym = (0, _symbol2.default)();\n\nvar promise = new _promise2.default();\n\nconsole.log((0, _getIterator3.default)(arr));\n```\n\nThis means is that you can seamlessly use these native built-ins and static methods\nwithout worrying about where they come from.\n\n**NOTE:** Instance methods such as `\"foobar\".includes(\"foo\")` will **not** work.\n\n### Helper aliasing\n\nUsually babel will place helpers at the top of your file to do common tasks to avoid\nduplicating the code around in the current file. Sometimes these helpers can get a\nlittle bulky and add unnecessary duplication across files. The `runtime`\ntransformer replaces all the helper calls to a module.\n\nThat means that the following code:\n\n```javascript\nclass Person {\n}\n```\n\nusually turns into:\n\n```javascript\n\"use strict\";\n\nfunction _classCallCheck(instance, Constructor) { if (!(instance instanceof Constructor)) { throw new TypeError(\"Cannot call a class as a function\"); } }\n\nvar Person = function Person() {\n  _classCallCheck(this, Person);\n};\n```\n\nthe `runtime` transformer however turns this into:\n\n```javascript\n\"use strict\";\n\nvar _classCallCheck2 = require(\"babel-runtime/helpers/classCallCheck\");\n\nvar _classCallCheck3 = _interopRequireDefault(_classCallCheck2);\n\nfunction _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { default: obj }; }\n\nvar Person = function Person() {\n  (0, _classCallCheck3.default)(this, Person);\n};\n```\n",
  "readmeFilename": "README.md",
  "_id": "babel-plugin-transform-runtime@6.23.0",
  "dist": {
    "shasum": "df8a865f8cb854267308232e22940e3ad3b4b22c"
  },
  "_from": "babel-plugin-transform-runtime@^6.22.0",
  "_resolved": "http://registry.npmjs.org/babel-plugin-transform-runtime/-/babel-plugin-transform-runtime-6.23.0.tgz"
}