Merge commit '9af485a584e47fd503ed5c62b9f6482574715f1e' as 'thirdparty/systemjs'

7 files changed, 1102 insertions, 0 deletions

diff --git a/thirdparty/systemjs/docs/config-api.md b/thirdparty/systemjs/docs/config-api.md
new file mode 100644
index 000000000..6ef4c6b92
--- /dev/null
+++ b/thirdparty/systemjs/docs/config-api.md
@@ -0,0 +1,292 @@
+## Configuration API
+
+### Setting Configuration
+
+Once SystemJS has loaded, configuration can be set on SystemJS by using the configuration function `System.config`:
+
+```javascript
+System.config({
+  configA: {},
+  configB: 'value'
+});
+```
+
+This is a helper function which normalizes configuration and sets configuration properties on the SystemJS instance.
+
+`System.config({ prop: 'value' })` is mostly equivalent to `System.prop = value` except that it will extend configuration objects,
+and certain properties will be normalized to be stored correctly.
+
+For this reason it is usually advisable to use `System.config` instead of setting instance properties directly.
+
+### Configuration Options
+
+* [babelOptions](#babeloptions)
+* [bundle](#bundle)
+* [defaultJSExtensions](#defaultjsextensions)
+* [depCache](#depcache)
+* [map](#map)
+* [meta](#meta)
+* [packages](#packages)
+* [paths](#paths)
+* [traceurOptions](#traceuroptions)
+* [transpiler](#transpiler)
+* [typescriptOptions](#typescriptoptions)
+
+#### babelOptions
+Type: `Object`
+Default: `{}`
+
+Set the Babel transpiler options when [System.transpiler](#transpiler) is set to `babel`:
+
+```javascript
+System.config({
+  babelOptions: {
+    stage: 1
+  }
+});
+```
+
+A list of options is available in the [Babel project documentation](https://babeljs.io/docs/usage/options/).
+
+#### bundle
+Type: `Object`
+
+Bundles allow a collection of modules to be downloaded together as a package whenever any module from that collection is requested.
+Useful for splitting an application into sub-modules for production. Use with the [SystemJS Builder](https://github.com/systemjs/builder).
+
+```javascript
+System.config({
+  bundles: {
+    bundleA: ['dependencyA', 'dependencyB']
+  }
+});
+```
+
+In the above any require to `dependencyA` or `dependencyB` will first trigger a `System.import('bundleA')` before proceeding with the load of `dependencyA` or `dependencyB`.
+
+It is an alternative to including a script tag for a bundle in the page, useful for bundles that load dynamically where we want to trigger the bundle load automatically only when needed.
+
+The bundle itself is a module which contains named System.register and define calls as an output of the builder. The dependency names the bundles config lists should be the same names that are explicitly defined in the bundle.
+
+#### defaultJSExtensions
+
+Backwards-compatibility mode for the loader to automatically add '.js' extensions when not present to module requests.
+
+This allows code written for SystemJS 0.16 or less to work easily in the latest version:
+
+```javascript
+System.defaultJSExtensions = true;
+
+// requests ./some/module.js instead
+System.import('./some/module');
+```
+
+Note that this is a compatibility property for transitioning to using explicit extensions and will be deprecated in future.
+
+#### depCache
+Type: `Object`
+
+An alternative to bundling providing a solution to the latency issue of progressively loading dependencies.
+When a module specified in depCache is loaded, asynchronous loading of its pre-cached dependency list begins in parallel.
+
+```javascript
+System.config({
+  depCache: {
+    moduleA: ['moduleB'], // moduleA depends on moduleB
+    moduleB: ['moduleC'] // moduleB depends on moduleC
+  }
+});
+
+// when we do this import, depCache knows we also need moduleB and moduleC,
+// it then directly requests those modules as well as soon as we request moduleA
+System.import('moduleA')
+```
+
+Over HTTP/2 this approach may be preferable as it allows files to be individually cached in the browser meaning bundle optimizations are no longer a concern.
+
+#### map
+Type: `Object`
+
+The map option is similar to paths, but acts very early in the normalization process. It allows you to map a module alias to a
+location or package:
+
+```javascript
+System.config({
+  map: {
+    jquery: '//code.jquery.com/jquery-2.1.4.min.js'
+  }
+});
+```
+
+```javascript
+import $ from 'jquery';
+
+```
+
+In addition, a map also applies to any subpaths, making it suitable for package folders as well:
+
+```javascript
+System.config({
+  map: {
+    package: 'local/package'
+  }
+});
+```
+
+```javascript
+// loads /local/package/path.js
+System.import('package/path.js');
+```
+
+> Note map configuration used to support contextual submaps but this has been deprecated for package configuration.
+
+#### meta
+Type: `Object`
+Default: `{}`
+
+Module meta provides an API for SystemJS to understand how to load modules correctly.
+
+Meta is how we set the module format of a module, or know how to shim dependencies of a global script.
+
+```javascript
+System.config({
+  meta: {
+    // meaning [baseURL]/vendor/angular.js when no other rules are present
+    // path is normalized using map and paths configuration
+    'vendor/angular.js': {
+      format: 'global', // load this module as a global
+      exports: 'angular', // the global property to take as the module value
+      deps: [
+        // dependencies to load before this module
+        'jquery'
+      ]
+    }
+  }
+});
+```
+
+Wildcard meta is also supported and is additive from least to most specific match:
+
+```javascript
+System.config({
+  meta: {
+    '/vendor/*': { format: 'global' }
+  }
+});
+```
+
+* [`format`](module-formats.md):
+  Sets in what format the module is loaded.
+* [`exports`](module-formats.md#exports):
+  For the `global` format, when automatic detection of exports is not enough, a custom exports meta value can be set.
+  This tells the loader what global name to use as the module's export value.
+* [`deps`](module-formats.md#shim-dependencies): 
+  Dependencies to load before this module. Goes through regular paths and map normalization. Only supported for the `cjs`, `amd` and `global` formats.
+* [`globals`](module-formats.md#custom-globals):
+  A map of global names to module names that should be defined only for the execution of this module. 
+    Enables use of legacy code that expects certain globals to be present. 
+    Referenced modules automatically becomes dependencies. Only supported for the `cjs` and `global` formats.
+* [`loader`](overview.md#plugin-loaders):
+  Set a loader for this meta path.
+* [`sourceMap`](creating-plugins.md):
+  For plugin transpilers to set the source map of their transpilation.
+* `scriptLoad`: Set to `true` to load the module using `<script>` tag injection (`importScript()` in a worker context) instead of using `fetch` and `eval`. This enables [CSP](https://www.w3.org/TR/CSP2/) support but disables the native loading of CommonJS modules and global modules where the export name is not declared via metadata.
+* `nonce`: The [nonce](https://www.w3.org/TR/CSP2/#script-src-the-nonce-attribute) attribute to use when loading the script as a way to enable CSP.
+  This should correspond to the "nonce-" attribute set in the Content-Security-Policy header.
+* `integrity`: The [subresource integrity](http://www.w3.org/TR/SRI/#the-integrity-attribute) attribute corresponding to the script integrity, describing the expected hash of the final code to be executed.
+  For example, `System.config({ meta: { 'src/example.js': { integrity: 'sha256-e3b0c44...' }});` would throw an error if the translated source of `src/example.js` doesn't match the expected hash.
+* `crossOrigin`: When scripts are loaded from a different domain (e.g. CDN) the global error handler (`window.onerror`)
+  has very limited information about errors to [prevent unintended leaking]
+  (https://developer.mozilla.org/en/docs/Web/API/GlobalEventHandlers/onerror#Notes).
+  In order to mitigate this, the `<script>` tags need to set [`crossorigin` attribute]
+  (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script#attr-crossorigin) and the server needs to
+  [enable CORS](http://enable-cors.org/).
+  The [valid values](https://developer.mozilla.org/en-US/docs/Web/HTML/CORS_settings_attributes) are 
+  `"anonymous"` and `"use-credentials"`.
+* `esmExports`: When loading a module that is not an ECMAScript Module, we set the module as the `default` export, but then also 
+  iterate the module object and copy named exports for it a well. Use this option to disable this iteration and copying of the exports.
+
+#### packages
+Type: `Object`
+Default: `{}`
+
+Packages provide a convenience for setting meta and map configuration that is specific to a common path.
+
+In addition packages allow for setting contextual map configuration which only applies within the package itself.
+This allows for full dependency encapsulation without always needing to have all dependencies in a global namespace.
+
+```javascript
+System.config({
+  packages: {
+    // meaning [baseURL]/local/package when no other rules are present
+    // path is normalized using map and paths configuration
+    'local/package': {
+      main: 'index.js',
+      format: 'cjs',
+      defaultExtension: 'js',
+      map: {
+        // use local jquery for all jquery requires in this package
+        'jquery': './vendor/local-jquery.js',
+
+        // import '/local/package/custom-import' should route to '/local/package/local/import/file.js'
+        './custom-import': './local/import/file.js'
+      },
+      meta: {
+        // sets meta for modules within the package
+        'vendor/*': {
+          'format': 'global'
+        }
+      }
+    }
+  }
+});
+```
+
+* `main`: The main entry point of the package (so `import 'local/package'` is equivalent to `import 'local/package/index.js'`)
+* `format`: The module format of the package. See [Module Formats](https://github.com/systemjs/systemjs/blob/master/docs/module-formats.md).
+* `defaultExtension`: The default extension to add to modules requested within the package.
+  Takes preference over defaultJSExtensions.
+  Can be set to `defaultExtension: false` to optionally opt-out of extension-adding when `defaultJSExtensions` is enabled.
+* `map`: Local and relative map configurations scoped to the package. Apply for subpaths as well.
+* `meta`: Package-scoped meta configuration with wildcard support. Modules are subpaths within the package path.
+  This also provides an opt-out mechanism for `defaultExtension`, by adding modules here that should skip extension adding.
+
+#### paths
+Type: `Object`
+
+The [ES6 Module Loader](https://github.com/systemjs/systemjs/blob/master/docs/es6-modules-overview.md) paths implementation, applied after normalization and supporting subpaths via wildcards.
+
+_It is usually advisable to use map configuration over paths unless you need strict control over normalized module names._
+
+#### traceurOptions
+Type: `Object`
+Default: `{}`
+
+Set the Traceur compilation options.
+
+```javascript
+System.config({
+    traceurOptions: {
+    }
+});
+```
+
+A list of options is available in the [Traceur project documentation](https://github.com/google/traceur-compiler/wiki/Options-for-Compiling).
+
+#### transpiler
+Type: `String`
+Default: `traceur`
+
+Sets the module name of the transpiler to be used for loading ES6 modules.
+
+Represents a module name for `System.import` that must resolve to either Traceur, Babel or TypeScript.
+
+When set to `traceur`, `babel` or `typescript`, loading will be automatically configured as far as possible.
+
+#### typescriptOptions
+Type: `Object`
+Default: `{}`
+
+Sets the TypeScript transpiler options.
+
+A list of options is available in the [TypeScript project documentation](https://www.typescriptlang.org/docs/handbook/compiler-options.html).
diff --git a/thirdparty/systemjs/docs/creating-plugins.md b/thirdparty/systemjs/docs/creating-plugins.md
new file mode 100644
index 000000000..531ece163
--- /dev/null
+++ b/thirdparty/systemjs/docs/creating-plugins.md
@@ -0,0 +1,84 @@
+### Creating a Plugin
+
+A plugin is just a set of overrides for the loader hooks of the ES6 module specification.
+
+The hooks plugins can override are `locate`, `fetch`, `translate` and `instantiate`.
+
+Read more about loader extensions and hooks at the [ES6 Module Loader polyfill wiki](https://github.com/ModuleLoader/es6-module-loader/blob/v0.17.0/docs/loader-extensions.md).
+
+The behaviors of the hooks are:
+
+* Locate: Overrides the location of the plugin resource
+* Fetch: Called with third argument representing default fetch function, has full control of fetch output.
+* Translate: Returns the translated source from `load.source`, can also set `load.metadata.sourceMap` for full source maps support.
+* Instantiate: Providing this hook as a promise or function allows the plugin to hook instantiate. Any return value becomes the defined custom module object for the plugin call.
+
+### Building Plugins
+
+When building via [SystemJS Builder](https://github.com/systemjs/builder), plugins that use the translate hook will be inlined into the bundle automatically.
+
+In this way, the bundle file becomes independent of the plugin loader and resource.
+
+If it is desired for the plugin itself not to be inlined into the bundle in this way, setting `exports.build = false` on the plugin will disable this,
+causing the plugin loader itself to be bundled in production instead to continue to dynamically load the resource.
+
+#### Sample CoffeeScript Plugin
+
+For example, we can write a CoffeeScript plugin with the following (CommonJS as an example, any module format works fine):
+
+js/coffee.js:
+```javascript
+  var CoffeeScript = require('coffeescript');
+
+  exports.translate = function(load) {
+    // optionally also set the sourceMap to support both builds and in-browser transpilation
+    // load.metadata.sourceMap = generatedSourceMap;
+    return CoffeeScript.compile(load.source);
+  }
+```
+
+By overriding the `translate` hook, we now support CoffeeScript loading with:
+
+```
+ - js/
+   - coffee.js             our plugin above
+   - coffeescript.js       the CoffeeScript compiler
+ - app/
+   - main.coffee
+```
+
+```javascript
+  System.import('app/main.coffee!').then(function(main) {
+    // main is now loaded from CoffeeScript
+  });
+```
+
+Source maps can also be passed by setting `load.metadata.sourceMap`.
+
+#### Sample CSS Plugin
+
+A CSS plugin, on the other hand, could override the fetch hook:
+
+js/css.js:
+```javascript
+  exports.fetch = function(load, fetch) {
+    return new Promise(function(resolve, reject) {
+      var cssFile = load.address;
+
+      var link = document.createElement('link');
+      link.rel = 'stylesheet';
+      link.href = cssFile;
+      link.onload = resolve;
+
+      document.head.appendChild(link);
+    })
+    .then(function() {
+      // return an empty module in the module pipeline itself
+      return '';
+    });
+  }
+```
+
+Each loader hook can either return directly or return a promise for the value.
+
+The other loader hooks are also treated otherwise identically to the specification.
diff --git a/thirdparty/systemjs/docs/es6-modules-overview.md b/thirdparty/systemjs/docs/es6-modules-overview.md
new file mode 100644
index 000000000..82f127548
--- /dev/null
+++ b/thirdparty/systemjs/docs/es6-modules-overview.md
@@ -0,0 +1,108 @@
+## Background
+
+### Modules and Module Loaders
+
+A module is simply a JavaScript file written with module syntax. Modules _export_ values, which can then be _imported_ by other modules.
+
+[CommonJS](http://wiki.commonjs.org/wiki/CommonJS) and [AMD](https://github.com/amdjs/amdjs-api/wiki/AMD) JavaScript files are modules.
+
+A module loader provides the ability to dynamically load modules, and also keeps track of all loaded modules in a module registry.
+
+Typically, in production, the module registry would be populated by an initial compiled bundle of modules. Later in the page state, it may become necessary to dynamically
+load a new module. This module can then share dependencies with the initial page bundle without having to reload any dependencies.
+
+Module code is treated differently to scripts due to the nature of exports and imports. 
+This is why the `<script type="module">` tag is introduced to distinguish script code from module code.
+
+### Module Naming
+
+Normalization rules allow module names to be converted into URLs.
+
+This allows module aliases like `import $ from 'jquery'` to be equivalent to writing `import $ from 'https://code.jquery.com/jquery.js'`
+
+Normalization rules are specific to the module loader implementation, with some certain standard conventions set down by the browser loader specification.
+
+## ES6 Module Syntax
+
+### Exporting
+
+ES6 module syntax is most similar to the `exports.method = function() {}` pattern in NodeJS of creating multiple named exports.
+
+In CommonJS one might write:
+
+```javascript
+  exports.someMethod = function() {
+
+  };
+
+  exports.another = {};
+```
+
+In ES6, this same code would be written:
+
+exporter.js:
+```javascript
+  export function someMethod() {
+
+  }
+
+  export var another = {};
+```
+
+Notice that the name of the function, class or variable gets used as the export name.
+
+### Importing
+
+When importing, we import any exports we need by name, and can also choose to rename them:
+
+importer.js:
+```javascript
+  import { someMethod, another as newName } from './exporter';
+
+  someMethod();
+  typeof newName == 'object';
+```
+
+### Default Import and Export
+
+Sometimes one doesn't want to write an import name at all. For this we can use the default export:
+
+export-default.js:
+```javascript
+  export default function foo() {
+    console.log('foo');
+  }
+```
+
+import-default.js:
+```javascript
+  import customName from './export-default';
+
+  customName(); // -> 'foo'
+```
+
+### All Supported Syntax
+
+There are a few other variations of module syntax, the full list of supported statements is listed below.
+
+```javascript
+import 'jquery';                        // import a module without any import bindings
+import $ from 'jquery';                 // import the default export of a module
+import { $ } from 'jquery';             // import a named export of a module
+import { $ as jQuery } from 'jquery';   // import a named export to a different name
+
+export var x = 42;                      // export a named variable
+export function foo() {};               // export a named function
+
+export default 42;                      // export the default export
+export default function foo() {};       // export the default export as a function
+
+export { encrypt };                     // export an existing variable
+export { decrypt as dec };              // export a variable as a new name
+export { encrypt as en } from 'crypto'; // export an export from another module
+export * from 'crypto';                 // export all exports from another module
+                                        // (except the default export)
+import * as crypto from 'crypto';       // import an entire module instance object
+```
+
+Note that any valid declaration can be exported. In ES6, this includes `class` (as in the example above), `const`, and `let`.
\ No newline at end of file
diff --git a/thirdparty/systemjs/docs/module-formats.md b/thirdparty/systemjs/docs/module-formats.md
new file mode 100644
index 000000000..3bafda590
--- /dev/null
+++ b/thirdparty/systemjs/docs/module-formats.md
@@ -0,0 +1,228 @@
+### Module Formats
+
+The following module formats are supported:
+
+* `esm`: ECMAScript Module (previously referred to as `es6`)
+* `cjs`: [CommonJS](#commonjs)
+* `amd`: [Asynchronous Module Definition](#amd)
+* `global`: [Global shim module format](#globals)
+* `register`: [System.register](system-api.md#systemregister-name-deps-declare) or [System.registerDynamic](system-api.md#systemregisterdynamic-name-deps-executingrequire-declare) compatibility module format
+
+The module format can be set via meta configuration:
+
+```javascript
+System.config({
+  meta: {
+    './module/path.js': {
+      format: 'esm'
+    }
+  }
+});
+```
+
+#### Module format detection
+
+When the module format is not set, automatic regular-expression-based detection is used.
+This module format detection is never completely accurate, but caters well for the majority use cases.
+
+The module format detection happens in the following order:
+* _System.register / System.registerDynamic_
+  If the source code starts with a number of comments, followed by `System.register` or `System.registerDynamic` as the first line of code.
+* _ES modules_
+  The source is only detected as an ES module if it contains explicit module syntax - valid `import` or `export` statements.
+* _AMD modules_
+  The presence of a valid AMD `define` statement in the code.
+* _CommonJS modules_
+  The presence of `require(...)` or `exports` / `module.exports` assigments
+* _Global_
+  This is the fallback module format after all the above fail.
+
+> Note that ES6 modules are detected via the presence of `import` and `export` module syntax and no other features at all. This is because the transpilation applies to the module format specifically, not the language.
+
+#### Inter-Format Dependencies
+
+Any module type can be loaded from any other type with full support thanks to [zebra-striping](https://github.com/ModuleLoader/es6-module-loader/blob/v0.17.0/docs/circular-references-bindings.md#zebra-striping).
+
+When loading CommonJS, AMD or Global modules from within ES6, the full module is available at the `default` export which can be loaded with the default import syntax.
+
+For convenience, named exports are also auto-populated but may not be correctly bound as expected, so use these carefully.
+
+./app/es6-loading-commonjs:
+```javascript
+// entire underscore instance
+import _ from './underscore.js';
+
+// unbound named export
+import {map} from './underscore.js';
+```
+
+### ES6
+
+ES6 modules are automatically transpiled as they are loaded, using the loader [transpiler option](config-api.md#transpiler) set.
+
+Circular references and bindings are implemented to the ES6 specification.
+
+The `__moduleName` local variable is also available, pending clarification of the module meta in the WhatWG loader spec.
+
+This provides the fully normalized name of the current module which can be useful for dynamically loading modules relative to the current module via:
+
+```javascript
+System.import('./local-module', __moduleName);
+```
+
+In due course this will be entirely replaced by the contextual loader once this has been specified.
+
+_ES6 is loaded via XHR making it non-[CSP](http://www.html5rocks.com/en/tutorials/security/content-security-policy/) compatible. ES6 should always be built for production to avoid transpiler costs, making this a development-only feature._
+
+### CommonJS
+
+* The `module`, `exports`, `require`, `global`, `__dirname` and `__filename` variables are all provided.
+* `module.id` is set.
+
+When executing CommonJS any global `define` is temporarily removed.
+
+For comprehensive handling of NodeJS modules, a conversion process is needed to make them SystemJS-compatible, such as the one used by jspm.
+
+_CommonJS is loaded via XHR making it non-[CSP](http://www.html5rocks.com/en/tutorials/security/content-security-policy/) compatible._
+
+Note that CommonJS modules on npm, loaded as CommonJS may well not load correctly through SystemJS. This is because SystemJS
+does not implement the NodeJS loading algorithm.
+
+If you want to load NodeJS modules through SystemJS you can use `import nodeModule from '@node/node-module-name'`, but this should only
+be used when absolutely necessary as it stops code from being universal, and makes it only compatible with NodeJS.
+
+### AMD
+
+* AMD support includes all AMD structural variations including the [CommonJS wrapper form](http://requirejs.org/docs/api.html#cjsmodule).
+* The special `module`, `exports`, and `require` module names are handled at the AMD format level and are not defined in the primary loader registry. `module.uri` and `module.id` are provided with `module.config` as a no-op.
+* Named defines are supported and will write directly into the loader registry.
+* A single named define will write into the loader registry but also be treated as the value of the module loaded if the names do not match. This enables loading a module containing `define('jquery', ...`.
+* Contextual dynamic requires are fully supported (`define(function(require) {  require(['./dynamic/require'], callback) })`)
+
+When executing AMD, the global `module`, `exports` are temporarily removed, and the global `define` and `require` are set to the SystemJS AMD functions.
+
+_By default AMD modules are loaded via `<script>` tag injection making them [CSP](http://www.html5rocks.com/en/tutorials/security/content-security-policy/)-compatible, provided that modules that are AMD are indicated [via meta](#module-formats) so that SystemJS knows to skip format detection and load them with script tags._
+
+#### RequireJS Support
+
+To use SystemJS side-by-side in a RequireJS project, make sure to include RequireJS after ES6 Module Loader but before SystemJS.
+
+Conversely, to have SystemJS provide a RequireJS-like API in an application set:
+
+```javascript
+window.define = System.amdDefine;
+window.require = window.requirejs = System.amdRequire;
+```
+
+### Globals
+
+The `global` format loads globals identically to if they were included via `<script>` tags 
+but with some extra features including the ability to [shim dependencies](#shim-dependencies), 
+set [custom globals](#custom-globals), and [define the exports](#exports) of the global module.
+
+By default, the exports of a global are calculated as the diff of the environment global from before to after execution.
+
+This provides a convenient mechanism for auto-conversion of globals into modules.
+
+For example:
+
+```javascript
+var MyGlobal = 42;
+```
+
+Will get converted into the module `Module({ default: 42 })`.
+
+While the script:
+
+```javascript
+(function(global) {
+  global.globalA = 'global A';
+  global.globalB = 'global B';
+})(typeof self != 'undefined' ? self : global);
+```
+
+Will get converted into the module `Module({ globalA: 'global A', globalB: 'global B' })`
+
+Globals are picked up by variable assignment and undeclared assignment:
+
+```javascript
+var x = 'global'; // detected as a global
+y = 'global';     // detected as a global
+```
+
+These two cases fail in IE8 and WebWorkers, so do need to have their [exports explicitly declared](#exports) if compatibility is desired.
+
+> Globals are not removed from the global object for shim compatibility, but this could become possible in future if all globals
+use the [globals](#globals) meta for shims instead of [deps](#shim-dependencies).
+
+#### Shim Dependencies
+
+When loading plugins of globals like Angular or jQuery plugins, we always need to shim the dependencies of the plugin
+to be dependent on the global it expects to find.
+
+We do this via deps metadata on the module:
+
+```javascript
+System.config({
+  meta: {
+    'vendor/angular-ui-router.js': {
+      deps: ['/vendor/angular.js']
+    }
+  }
+});
+System.import('vendor/angular-ui-router.js');
+```
+
+Note that deps is only supported for global modules.
+
+> It is always advisable to explicitly shim global modules as above for any globals they expect to be present.
+  For example, the above module may work fine without the shim if Angular always happens to load first in the page,
+  but this isn't always guaranteed, and problems will likely be hit later on when the load order happens to change.
+
+#### Custom Globals
+
+When shimming dependencies, the issue with this is that every dependency needs to be a global in order to be loadable by a global.
+
+This holds the entire ecosystem back as globals become the lowest common denominator.
+
+If we want to upgrade Angular to an ES6 version of Angular, while still supporting old Angular global modules, we can do this via custom globals:
+
+```javascript
+System.config({
+  meta: {
+    'vendor/angular-ui-router.js': {
+      globals: {
+        angular: 'vendor/angular.js'
+      }
+    }
+  }
+});
+System.import('vendor/angular-ui-router.js');
+```
+
+In the above scenario, a globally scoped `angular` will be set to the module value for the Angular ES6 module only for the duration of execution of the global plugin. They will be reverted to whatever they where before after execution, if they didn't exist they're removed. This doesn't influence the globals that might already be generated by the referenced package. 
+
+> **The globals meta-configuration option is only available for the `global` and `cjs` module formats.** as these are the only formats that are source-code-transformation based.
+
+Referenced packages automatically becomes dependencies. 
+
+#### Exports
+
+When automatic detection of exports is not enough, a custom exports meta value can be set.
+
+This is a member expression on the global object to be taken as the exports of the module.
+
+For example, `angular` or `jQuery.fn.pluginName`.
+
+> Globals can be loaded in a way that is CSP-compatible by setting their `format` and `exports` metadata when not setting any `globals` metadata. SystemJS then knows it can use script tag injection for this case. For example, Google Analytics can be loaded without requiring CORS or CSP via setting:
+  ```javascript
+  System.config({
+    meta: {
+      'https://www.google-analytics.com/analytics.js': {
+        exports: 'ga',
+        format: 'global'
+      }
+    }
+  });
+  ```
+
diff --git a/thirdparty/systemjs/docs/overview.md b/thirdparty/systemjs/docs/overview.md
new file mode 100644
index 000000000..a3899f297
--- /dev/null
+++ b/thirdparty/systemjs/docs/overview.md
@@ -0,0 +1,166 @@
+### Loading Modules
+
+Any URL can be loaded as a module with standard URL syntax:
+
+```html
+<script src="system.js"></script>
+<script>
+  // loads relative to the current page URL
+  System.import('./local-module.js'); 
+
+  // load from an absolute URL directly
+  System.import('https://code.jquery.com/jquery.js');
+</script>
+```
+
+Any type of module format can be loaded and it will be detected automatically by SystemJS.
+
+##### File access from files
+
+> _Note that when running locally, ensure you are running from a local server or a browser with local XHR requests enabled. If not you will get an error message._
+
+> _For Chrome on Mac, you can run it with: `/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --allow-file-access-from-files &> /dev/null &`_
+
+> _In Firefox this requires navigating to `about:config`, entering `security.fileuri.strict_origin_policy` in the filter box and toggling the option to false._
+
+### Loading ES6
+
+app/es6-file.js:
+```javascript
+  export class q {
+    constructor() {
+      this.es6 = 'yay';
+    }
+  }
+```
+
+```html
+  <script>
+    System.import('./app/es6-file.js').then(function(m) {
+      console.log(new m.q().es6); // yay
+    });
+  </script>
+```
+
+ES6 modules define named exports, provided as getters on a special immutable `Module` object.
+
+* [Read more about ES6 modules and syntax](es6-modules-overview.md).
+* To build for production, see the [production workflows](production-workflows.md).
+* [Read more about SystemJS module format support](module-formats.md).
+
+### Loader Configuration
+
+Some of the standard configuration options and their use cases are described below.
+
+For a reference see the [Config API](config-api.md) page.
+
+#### baseURL
+
+The *baseURL* provides a special mechanism for loading modules relative to a standard reference URL.
+
+This can be useful for being able to refer to the same module from many different page URLs or environments:
+
+```javascript
+System.config({
+  baseURL: '/modules'
+});
+
+
+// loads /modules/jquery.js
+System.import('jquery.js');
+```
+
+Module names of the above form are referred to as _plain names_ and are always loaded baseURL-relative instead of
+parentURL relative like one would expect with ordinary URLs.
+
+> Note we always run the `System.config` function instead of setting instance properties directly as this will set the correct normalized baseURL in the process.
+
+#### Map Config
+
+The baseURL is very useful for providing an absolute reference URL for loading all modules, but we don't necessarily want to
+have to locate every single shared dependency from within one folder.
+
+Sometimes we want to load things from different places.
+
+Map configuration is useful here to be able to specific exactly where to locate a given package:
+
+```javascript
+System.config({
+  map: {
+    jquery: 'https://code.jquery.com/jquery.js'
+  }
+});
+```
+
+Map configuration can also be used to map subpaths:
+
+```javascript
+System.config({
+  map: {
+    app: '/app/'
+  }
+});
+
+// will load /app/main.js
+System.import('app/main.js');
+```
+
+Map configuration is always applied before the baseURL rule in the loader.
+
+### Plugin Loaders
+
+Plugins handle alternative loading scenarios, including loading assets such as CSS or images, and providing custom transpilation scenarios.
+
+Plugins can also inline into bundles or remain separate requests when using [SystemJS Builder](https://github.com/systemjs/builder).
+
+To create a custom plugin, see the documentation on [creating plugins](creating-plugins.md).
+
+#### Basic Use
+
+> Note that if using the `defaultJSExtensions` compatibility feature, plugins for resources with custom extensions will only work by using the [package configuration](config-api.md#packages) `defaultExtension: false` option to override this for specific packages.
+
+To use a plugin, set up the plugin itself as a standard module, either locating it in the baseURL or providing map configuration for it.
+
+In this case, we're using the [text plugin](https://github.com/systemjs/plugin-text) as an example.
+
+Then configure a custom resource to be loaded via the plugin, we then use meta configuration:
+
+```javascript
+System.config({
+  // locate the plugin via map configuration
+  // (alternatively have it in the baseURL)
+  map: {
+    text: '/path/to/text-plugin.js'
+  },
+  // use meta configuration to reference which modules
+  // should use the plugin loader
+  meta: {
+    'templates/*.html': {
+      loader: 'text'
+    }
+  }
+});
+```
+
+Now any code that loads from `[baseURL]/templates/*.html` will use the text loader plugin and return the loaded content:
+
+app.js
+```javascript
+import htmlSource from 'templates/tpl.html';
+
+document.querySelector('.container').innerHTML = htmlSource;
+```
+
+When we build app.js, the text plugin will then automatically inline the templates into the bundle during the build.
+
+#### Plugin Syntax
+
+It is also possible to use syntax to load via plugins instead of configuration:
+
+```javascript
+System.import('some/file.txt!text')
+```
+
+When no plugin is explicitly specified the extension is used as the plugin name itself.
+
+> Note it is usually advisable to use plugin loader configuration over plugin syntax.
diff --git a/thirdparty/systemjs/docs/production-workflows.md b/thirdparty/systemjs/docs/production-workflows.md
new file mode 100644
index 000000000..6af698915
--- /dev/null
+++ b/thirdparty/systemjs/docs/production-workflows.md
@@ -0,0 +1,83 @@
+### Compiling Modules into a Bundle
+
+[SystemJS builder](https://github.com/systemjs/builder) provides comprehensive support for compiling all 
+module formats into a single bundle in a way that supports 
+[circular references and zebra-striping](https://github.com/ModuleLoader/es6-module-loader/blob/v0.17.0/docs/circular-references-bindings.md).
+
+It also offers the ability to [create self-executing bundles](https://github.com/systemjs/builder#self-executing-sfx-bundles) 
+that can run without needing SystemJS present at all by embedding a micro-loader implementation.
+
+### DepCache
+
+An alternative to bundling into a single bundle is to leave files as separate for loading in production.
+
+The depcache extension allows specifying the dependencies of all modules upfront through configuration so that loads can 
+happen in parallel.
+
+```javascript
+System.config({
+  depCache: {
+    'moduleA': ['moduleB'], // moduleA depends on moduleB
+    'moduleB': ['moduleC']  // moduleB depends on moduleC
+  }
+});
+
+// when we do this import, depCache knows we also need moduleB and moduleC,
+// it then directly requests those modules as well as soon as we request moduleA
+System.import('moduleA')
+```
+
+Over HTTP/2 this approach may be preferable as it allows files to be individually cached in the browser meaning bundle 
+optimizations are no longer a concern.
+
+### Bundle Extension
+
+It can be useful to load bundles of code on-demand instead of having them all included in the HTML page blocking the 
+initial load.
+
+The bundle extension will automatically download a bundle as soon as an attempt to import any module in that bundle is made.
+
+```javascript
+  // the bundle at build/core.js contains these modules
+  System.config({
+    bundles: {
+      'build/core': ['jquery', 'app/app', 'app/dep', 'lib/third-party']
+    }
+  });
+  
+  // when we load 'app/app' the bundle extension interrupts the loading process
+  // and ensures that build/core.js is loaded first
+  System.import('app/app');
+  
+  // this way a request to any one of 'jquery', 'app/app', 'app/dep', 'lib/third-party'
+  // will delegate to the bundle and only a single request is made
+```
+
+A built file must contain the exact named defines or named `System.register` statements for the modules
+it contains. Mismatched names will result in separate requests still being made.
+
+### CSP-Compatible Production
+
+SystemJS comes with a separate build for production only. This is fully [CSP](http://www.html5rocks.com/en/tutorials/security/content-security-policy/)-compatible using script tag injection to load scripts, 
+while still remaining an extension of the ES6 Module Loader.
+
+Replace the `system.js` file with `dist/system-csp-production.js`.
+
+If we have compiled all our modules into a bundle we can then write:
+
+```html
+  <script src="system-csp-production.js"></script>
+  <script>
+    System.config({
+      bundles: {
+        'bundle': ['app/main']
+      }
+    });
+    System.import('app/main').then(function(m) { 
+      // loads app/main from the app-built bundle
+    });
+  </script>
+```
+
+> Note the main build of SystemJS will also use script tag injection for AMD, register and global modules when it can for maximum CSP compatibility.
+  It is typically just plugin loaders, CommonJS and custom global metadata options that cause XHR source-loading to be needed.
diff --git a/thirdparty/systemjs/docs/system-api.md b/thirdparty/systemjs/docs/system-api.md
new file mode 100644
index 000000000..803d688fc
--- /dev/null
+++ b/thirdparty/systemjs/docs/system-api.md
@@ -0,0 +1,141 @@
+## SystemJS API
+
+For setting SystemJS configuration see the [Configuration API](config-api.md) page.
+
+#### System.amdDefine
+Type: `Function`
+
+For backwards-compatibility with AMD environments, set `window.define = System.amdDefine`.
+
+#### System.amdRequire
+Type: `Function`
+
+For backwards-compatibility with AMD environments, set `window.require = System.amdRequire`.
+
+#### System.config
+Type: `Function`
+
+SystemJS configuration helper function. See the [Configuration API](config-api.md).
+
+#### System.constructor
+Type: `Function`
+
+This represents the System base class, which can be extended or reinstantiated to create a custom System instance.
+
+Example:
+
+```javascript
+  var clonedSystem = new System.constructor();
+  clonedSystem.baseURL = System.baseURL;
+  clonedSystem.import('x'); // imports in a custom context
+```
+
+#### System.delete(moduleName)
+Type: `Function`
+
+Deletes a module from the registry by normalized name.
+
+```javascript
+System.delete('http://site.com/normalized/module/name.js');
+```
+
+#### System.get(moduleName) -> Module
+Type: `Function`
+
+Returns a module from the registry by normalized name.
+
+```javascript
+System.get('http://site.com/normalized/module/name.js').exportedFunction();
+```
+
+#### System.has(moduleName) -> Boolean
+Type: `Function`
+
+Returns whether a given module exists in the registry by normalized module name.
+
+```javascript
+if (System.has('http://site.com/normalized/module/name.js')) {
+  // ...
+}
+```
+
+#### System.import(moduleName [, normalizedParentName]) -> Promise(Module)
+Type: `Function`
+
+Loads a module by name taking an optional normalized parent name argument.
+
+Promise resolves to the module value.
+
+For loading relative to the current module, ES Modules define a `__moduleName` binding, so that:
+
+```javascript
+System.import('./local', __moduleName);
+```
+
+In CommonJS modules the above would be `module.id` instead.
+
+This is non-standard, but coverse a use case that will be provided by the spec.
+
+#### System.newModule(Object) -> Module
+Type: `Function`
+
+Given a plain JavaScript object, return an equivalent `Module` object.
+
+Useful when writing a custom `instantiate` hook or using `System.set`.
+
+#### System.register([name ,] deps, declare)
+Type: `Function`
+
+Declaration function for defining modules of the `System.register` polyfill module format.
+
+[Read more on the format at the loader polyfill page](https://github.com/ModuleLoader/es6-module-loader/blob/v0.17.0/docs/system-register.md)
+
+#### System.registerDynamic([name ,] deps, executingRequire, declare)
+Type: `Function`
+
+Companion module format to `System.register` for non-ES6 modules.
+
+Provides a `<script>`-injection-compatible module format that any CommonJS or Global module can be converted into for CSP compatibility.
+
+Output created by [SystemJS Builder](https://github.com/systemjs/builder) when creating bundles or self-executing bundles.
+
+For example, the following CommonJS module:
+
+```javascript
+module.exports = require('pkg/module');
+```
+
+Can be written:
+
+```javascript
+System.registerDynamic(['pkg/module'], true, function(require, exports, module) {
+  module.exports = require('pkg/module');
+});
+```
+
+`executingRequire` indicates that the dependencies are executed synchronously only when using the `require` function, and not before execution.
+
+* `require` is a standard CommonJS-style require
+* `exports` the CommonJS exports object, which is assigned to the `default` export of the module, with its own properties available as named exports.
+* `module` represents the CommonJS module object, with `export`, `id` and `url` properties set.
+
+#### System.set(moduleName, Module)
+Type: `Function`
+
+Sets a module into the registry directly and synchronously.
+
+Typically used along with `System.newModule` to create a valid `Module` object:
+
+```javascript
+System.set('custom-module', System.newModule({ prop: 'value' }));
+```
+
+> Note SystemJS stores all module names in the registry as normalized URLs. To be able to properly use the registry with `System.set` it is usually necessary to run `System.set(System.normalizeSync('custom-module'), System.newModule({ prop: 'value' }));` to ensure that `System.import` behaves correctly.
+
+#### System._nodeRequire
+Type: `Function`
+
+In CommonJS environments, SystemJS will substitute the global `require` as needed by the module format being loaded to ensure
+the correct detection paths in loaded code.
+
+The CommonJS require can be recovered within these modules from `System._nodeRequire`.