| 1 | * [Using Plugins](#using-plugins)
|
| 2 | * [CSS](#css)
|
| 3 | * [Compiler Plugins](#compiler-plugins)
|
| 4 | * [Resource Plugins](#resource-plugins)
|
| 5 |
|
| 6 | ### Using Plugins
|
| 7 |
|
| 8 | [SystemJS plugins](https://github.com/systemjs/systemjs#plugins) are installed like any other dependency in jspm,
|
| 9 | [and can be found listed at the top of the jspm registry](https://github.com/jspm/registry/blob/master/registry.json#L2).
|
| 10 |
|
| 11 | Plugins are installed by name:
|
| 12 |
|
| 13 | ```
|
| 14 | jspm install css
|
| 15 | ```
|
| 16 |
|
| 17 | To use a plugin, add a `!` to the end of a require:
|
| 18 |
|
| 19 | ```javascript
|
| 20 | import './some/style.css!';
|
| 21 | ```
|
| 22 |
|
| 23 | The plugin name is taken from the extension name. You can also add any plugin name after the `!` to load with a different plugin than the extension name:
|
| 24 |
|
| 25 | ```
|
| 26 | jspm install json
|
| 27 | ```
|
| 28 |
|
| 29 | ```javascript
|
| 30 | import config from './config-service!json';
|
| 31 | ```
|
| 32 |
|
| 33 | Plugins can also be used in dynamic imports - `System.import('component.jsx!')`;
|
| 34 |
|
| 35 | > Plugins should always be declared as dependencies of the package they are used in - they are contextual modules just like any other dependency.
|
| 36 |
|
| 37 | ### CSS
|
| 38 |
|
| 39 | CSS is supported in jspm through the `css` plugin:
|
| 40 |
|
| 41 | ```
|
| 42 | jspm install css
|
| 43 | ```
|
| 44 |
|
| 45 | CSS can then be declared as a dependency in the tree:
|
| 46 |
|
| 47 | ```javascript
|
| 48 | import './component.css!';
|
| 49 | ```
|
| 50 |
|
| 51 | CSS should always be a dependency in your package.json if sharing a package that has CSS plugin requires of this form.
|
| 52 |
|
| 53 | #### CSS Builds
|
| 54 |
|
| 55 | The CSS plugin will inline and combine CSS requires into the bundle output when using `jspm bundle`. The following options can be added to the jspm `config.js` file to alter this behaviour further:
|
| 56 |
|
| 57 | * `buildCSS: false` add this option to opt-out of CSS inlining, and instead have the CSS loaded as separate files in production.
|
| 58 | * `separateCSS: true` add this option to create a `bundle.js` AND a `bundle.css` file which can be included with a separate link tag.
|
| 59 |
|
| 60 | If using CSS imports, it is advisable to follow [modular CSS best practises](https://github.com/systemjs/plugin-css#modular-css-concepts).
|
| 61 |
|
| 62 | Read more at the CSS plugin project page - https://github.com/systemjs/plugin-css.
|
| 63 |
|
| 64 | ### Compiler Plugins
|
| 65 |
|
| 66 | Compiler plugins are plugins like [jsx](https://github.com/floatdrop/plugin-jsx) (as well as json and text) allow you to load other languages into JavaScript. These provide implementations of the `translate` hook, which makes them **buildable**.
|
| 67 |
|
| 68 | That is, when using `jspm bundle` compilations will be inline automatically, and the plugin itself will not be used in production. When in development, the plugin can optionally support in-browser compilation.
|
| 69 |
|
| 70 | > Separate file production of compiler plugins using pre-compilation is not currently supported, although this is a feature that is planned for implementation in future. For now only use compiler plugins if you're using jspm bundling.
|
| 71 |
|
| 72 | ### Resource Plugins
|
| 73 |
|
| 74 | These are plugins that are used to load production resources. For example, using the CSS plugin with builds disabled or the [image](https://github.com/systemjs/plugin-image) plugin. The plugin does not build at all, and runs in production. |
| \ | No newline at end of file |