Browse Source

Hopefully last round of docs changes

v6-dev
Eli Perelman 8 years ago
parent
commit
448aa4b651
  1. 19
      docs/SUMMARY.md
  2. 411
      docs/api/README.md
  3. 55
      docs/cli/README.md
  4. 4
      docs/creating-presets.md
  5. 2
      docs/customization/advanced.md
  6. 4
      docs/customization/simple.md
  7. 4
      docs/middleware/README.md
  8. 10
      docs/middleware/neutrino-middleware-eslint/README.md
  9. 22
      docs/presets/neutrino-preset-airbnb-base/README.md
  10. 6
      docs/presets/neutrino-preset-jest/README.md
  11. 6
      docs/presets/neutrino-preset-karma/README.md
  12. 6
      docs/presets/neutrino-preset-mocha/README.md
  13. 4
      docs/presets/neutrino-preset-node/README.md
  14. 4
      docs/presets/neutrino-preset-react/README.md
  15. 4
      docs/presets/neutrino-preset-web/README.md
  16. 46
      docs/upgrading-neutrino.md
  17. 30
      docs/usage.md
  18. 2
      package.json
  19. 2
      packages/neutrino/bin/build.js
  20. 2
      packages/neutrino/bin/inspect.js
  21. 2
      packages/neutrino/bin/start.js
  22. 2
      packages/neutrino/bin/test.js
  23. 7
      packages/neutrino/src/api.js
  24. 2
      packages/neutrino/src/index.js
  25. 51
      yarn.lock

19
docs/SUMMARY.md

@ -5,7 +5,6 @@
* [Usage](./usage.md)
* [Project Layout](./project-layout.md)
* [FAQ](./FAQ.md)
* [Middleware](./middleware/README.md)
* [Presets](./presets/README.md)
* [Web](./presets/neutrino-preset-web/README.md)
* [React](./presets/neutrino-preset-react/README.md)
@ -15,6 +14,24 @@
* [Mocha](./presets/neutrino-preset-mocha/README.md)
* [Jest](./presets/neutrino-preset-jest/README.md)
* [Community presets](./presets/community-presets.md)
* [Middleware](./middleware/README.md)
* [banner](./middleware/neutrino-middleware-banner/README.md)
* [chunk](./middleware/neutrino-middleware-chunk/README.md)
* [clean](./middleware/neutrino-middleware-clean/README.md)
* [compile-loader](./middleware/neutrino-middleware-compile-loader/README.md)
* [copy](./middleware/neutrino-middleware-copy/README.md)
* [env](./middleware/neutrino-middleware-env/README.md)
* [eslint](./middleware/neutrino-middleware-eslint/README.md)
* [font-loader](./middleware/neutrino-middleware-font-loader/README.md)
* [hot](./middleware/neutrino-middleware-hot/README.md)
* [html-loader](./middleware/neutrino-middleware-html-loader/README.md)
* [html-template](./middleware/neutrino-middleware-html-template/README.md)
* [image-loader](./middleware/neutrino-middleware-image-loader/README.md)
* [loader-merge](./middleware/neutrino-middleware-loader-merge/README.md)
* [minify](./middleware/neutrino-middleware-minify/README.md)
* [named-modules](./middleware/neutrino-middleware-named-modules/README.md)
* [start-server](./middleware/neutrino-middleware-named-start-server/README.md)
* [style-loader](./middleware/neutrino-middleware-named-style-loader/README.md)
* [Customization](./customization/README.md)
* [Simple](./customization/simple.md)
* [Advanced](./customization/advanced.md)

411
docs/api/README.md

@ -1,33 +1,52 @@
# Neutrino API
When using Neutrino via the [CLI](../cli/README.md), it creates an instance of the Neutrino API which picks up
any presets and arguments passed on the command line or located in package.json. If you desire, you can also create your
own instance of the Neutrino API and interact with it programmatically.
any middleware and arguments passed on the command line or located in package.json. If you desire, you can also create
your own instance of the Neutrino API and interact with it programmatically.
## Importing
The default export of the Neutrino module is an object with several mechanisms for interacting with the API:
```js
const {
Neutrino,
run,
build,
inspect,
start,
test
} = require('neutrino');
```
The `Neutrino` function is the lowest-level API, with each of the other methods a higher-level API
which creates an instance of the API internally. First, we will cover the low-level `Neutrino` API and
later showing how to use the higher-level functions.
## Instantiation
In order to access the Neutrino API, you must require or import it and instantiate it, passing in any
In order to access the Neutrino API, you must require or import it and invoke it, passing in any
options:
Using `require`:
```js
const Neutrino = require('neutrino');
const { Neutrino } = require('neutrino');
const api = new Neutrino(options);
const neutrino = Neutrino(options);
```
Using ES imports:
```js
import Neutrino from 'neutrino';
import { Neutrino } from 'neutrino';
const api = new Neutrino(options);
const neutrino = Neutrino(options);
```
## API options
The Neutrino constructor can accept an object for setting a number of useful options:
The Neutrino function can accept an object for setting a number of useful options:
### `options.root`
@ -36,7 +55,7 @@ the package.json would be located. If the option is not set, Neutrino defaults i
path is specified, it will be resolved relative to `process.cwd()`; absolute paths will be used as-is.
```js
new Neutrino({
Neutrino({
// if not specified, defaults to process.cwd()
// relative, resolves to process.cwd() + ./website
@ -53,7 +72,7 @@ Set the directory which contains the application source code. If the option is n
If a relative path is specified, it will be resolved relative to `options.root`; absolute paths will be used as-is.
```js
new Neutrino({
Neutrino({
// if not specified, defaults to options.root + src
// relative, resolves to options.root + ./lib
@ -70,7 +89,7 @@ Set the directory which will be the output of built assets. If the option is not
If a relative path is specified, it will be resolved relative to `options.root`; absolute paths will be used as-is.
```js
new Neutrino({
Neutrino({
// if not specified, defaults to options.root + build
// relative, resolves to options.root + ./dist
@ -87,7 +106,7 @@ Set the directory that contains test files. If the option is not set, Neutrino d
If a relative path is specified, it will be resolved relative to `options.root`; absolute paths will be used as-is.
```js
new Neutrino({
Neutrino({
// if not specified, defaults to options.root + test
// relative, resolves to options.root + ./testing
@ -104,7 +123,7 @@ Set the main entry point for the application. If the option is not set, Neutrino
If a relative path is specified, it will be resolved relative to `options.source`; absolute paths will be used as-is.
```js
new Neutrino({
Neutrino({
// if not specified, defaults to options.source + index.js
// relative, resolves to options.source + ./entry.js
@ -122,7 +141,7 @@ Set the directory which contains the Node.js modules of the project. If the opti
used as-is.
```js
new Neutrino({
Neutrino({
// if not specified, defaults to options.root + node_modules
// relative, resolves to options.root + ./modules
@ -140,69 +159,70 @@ using the `use` method. The `use` method takes in a middleware function, and opt
passed to the middleware function.
```js
api.use(middleware, middlewareOptions)
neutrino.use(middleware, middlewareOptions)
```
Typically presets do not require any additional options, and middleware may, but check with your particular package
for specifics. As an example, if you wanted to require the list of presets and Neutrino options from a package.json:
```js
const Neutrino = require('neutrino');
const { Neutrino } = require('neutrino');
const pkg = require('./package.json');
const api = new Neutrino(pkg.neutrino.options);
const neutrino = Neutrino(pkg.neutrino.options);
api.use(require(pkg.neutrino.presets[0]));
neutrino.use(require(pkg.neutrino.use[0]));
```
You can call `.use` iteratively for multiple presets:
```js
pkg.neutrino.presets
.forEach(preset => neutrino.use(require(preset)));
pkg.neutrino.use
.map(require)
.map(neutrino.use);
```
## Environment
When using the CLI, environment variables are automatically set based on the command you are using.
When using the API this is not the case, and you **must** set it prior to calling any build commands or
loading any presets if you expect them to build correctly based on their target.
When using the CLI and the higher-level API functions, environment variables are automatically set based on the command
you are using. When using the `Neutrino` low-level API this is not the case, and you **must** set it prior to calling
any build commands or loading any middleware if you expect them to build correctly based on their target.
```js
process.env.NODE_ENV = 'production';
const api = new Neutrino();
// load presets...
const neutrino = Neutrino();
api.build();
process.env.NODE_ENV = 'production';
// load middleware...
```
## API
### Constructor
## Neutrino API
When creating a Neutrino instance, you have the option of providing an object which can be passed as options to
middleware as `neutrino.options`.
```js
const Neutrino = require('neutrino');
const { Neutrino } = require('neutrino');
const api = new Neutrino();
const neutrino = Neutrino();
// or with optional options
const api = new Neutrino({ jest: { bail: true } });
const neutrino = Neutrino({ jest: { bail: true } });
```
### `.config`
### `options`
An object containing various properties for the benefit of the API and middleware. This can contain
options set by both Neutrino and any included middleware.
### `config`
When constructing a Neutrino instance, a property of `.config` is set to be a new instance of
When constructing a Neutrino instance, a property of `config` is set to be a new instance of
[webpack-chain](https://github.com/mozilla-neutrino/webpack-chain). This property is then available to all presets
which subsequently augment it with their specific configuration. All middleware and presets added use this single
`.config` to store their data, meaning that middleware load order has an effect on which config values take precedence.
`config` to store their data, meaning that middleware load order has an effect on which config values take precedence.
Middleware loaded first will have any configuration overridden by later middleware with matching properties.
### `.use(middleware, middlewareOptions)`
### `use(middleware, middlewareOptions)`
Invoke a Neutrino middleware function, optionally providing options which will be passed to the middleware function.
Middleware will be invoked with two arguments:
@ -223,105 +243,298 @@ function middleware(neutrino, options) {
neutrino.use(middleware, { entryPoint: 'babel-polyfill' });
```
### `start(args)`
The `start()` method is responsible for creating a development bundle, and when possible, starting a development
server or source watcher. Prior to starting this process, Neutrino will trigger and wait for `prestart` events to
finish. After it is complete, Neutrino will trigger and wait for `start` events to finish.
If the Neutrino config contains options for `devServer`, then a webpack-dev-server will be started, otherwise a Webpack
source watcher will be started.
### `emitForAll(eventName, payload)`
Currently any `args` passed to `start()` have no effect and will be passed through to any event handlers.
Trigger a Promise-dependent event. For example, calling `emitForAll('build')` will trigger an event named build, and
each event handler can return a Promise denoting when it is finished. When all events have finished, this call will
resolve.
The `start` method will return a Promise which resolves after the build is done or development watcher has stopped,
and all `start` events have finished.
This method returns a Promise which resolves when all event handlers have also resolved.
```js
api
.start()
.then(() => console.log('Exiting!'));
.emitForAll('custom-event')
.then(() => console.log('All custom-events have resolved!'));
```
### `build(args)`
By passing an additional argument for `payload`, you can pass custom data to all the event handlers
The `build()` method is responsible for creating a bundle typically used for production. Prior to starting this process,
Neutrino will trigger and wait for `prebuild` events to finish. After it is complete, Neutrino will trigger and wait for
`build` events to finish.
```js
api.emitForAll('custom-event', { custom: 'payload' });
Currently any `args` passed to `build()` have no effect and will be passed through to any event handlers.
// ...
The `build` method will return a Promise which resolves after the build is done and all `build` events have finished, or
will reject if there was a failure during building.
neutrino.on('custom-event', (args, payload) => {
console.log(payload.custom); // "payload"
});
```
### `config.toConfig()`
While tools like webpack-chain provide a convenient API for creating Webpack configurations, this is not a format that
is understandable by Webpack. With `config.toConfig()`, the webpack-chain instance at `config` will be converted to
a configuration object readable directly by Webpack.
```js
api
.build()
.then(() => console.log('Saved to build/'))
.catch(err => console.error(err));
api.config.toConfig(); // -> { ... }
```
### `test(args)`
### `requiresAndUses(middleware)`
The `test()` method is responsible for gathering args needed for testing and triggering relevant events as a signal to
test presets that they may run. Using the `test` method does nothing other than triggering these events; without
middleware listening for these events, nothing will happen. Prior to starting this process, Neutrino will trigger and
wait for `pretest` events to finish. After it is complete, Neutrino will trigger and wait for
`test` events to finish, in which test runners will do their work.
This method takes an array of module strings which map to the location of middleware and returns a
[`Future`](https://github.com/fluture-js/Fluture) which will attempt to look up, require, and `use` each middleware.
This function is shorthand for `api.useRequires(api.requires(middleware))`.
Any `args` passed to `test()` are passed on to the event handles and typically have properties for an array of
`files` to test, as well as a property for `watch`ing and rerunning tests.
The Future can be resolved with an [Immutable List](https://facebook.github.io/immutable-js/docs/#/List) of middleware,
or rejected with an error if a failure occurs requiring the middleware.
The `test` method will return a Promise which resolves after all `test` events have finished, or
will reject if there was a failure during testing.
```js
api.requiresAndUses(['middleware-alpha', 'middleware-beta'])
.fork(
err => console.log('Could not import middleware', err),
() => console.log('Finished importing all middleware')
);
```
### `requires(middleware)`
This method takes an array of module strings which map to the location of middleware and returns a
[`Future`](https://github.com/fluture-js/Fluture) which will attempt to look up and require each middleware.
The middleware is not `use`d at this point, only required.
The Future can be resolved with an [Immutable List](https://facebook.github.io/immutable-js/docs/#/List) of middleware,
or rejected with an error if a failure occurs requiring the middleware.
```js
// Using Future to fork and handle any errors
api
.test()
.then(() => console.log('all passed'))
.catch(err => console.error(err));
.requires(['middleware-alpha', 'middleware-beta'])
.fork(
err => console.log('Could not require middleware', err),
middleware => middleware.map(console.log)
);
```
```js
// Using Future promise API to fork and handle any errors
api
.test({
files: [/* ... */],
watch: true
})
.then(() => console.log('all passed'));
.requires(['middleware-alpha', 'middleware-beta'])
.promise()
.then(middleware => middleware.map(console.log))
.catch(err => console.log('Could not require middleware', err));
```
### `getWebpackConfig()`
### `useRequires(requires)`
While tools like webpack-chain provide a convenient API for creating Webpack configurations, this is not a format that
is understandable by Webpack. With `getWebpackConfig()`, the webpack-chain instance at `.config` will be converted to
an configuration object readable directly by Webpack.
Accepts a [`Future`](https://github.com/fluture-js/Fluture) of a
[List](https://facebook.github.io/immutable-js/docs/#/List) of middleware to run through `api.use`. Useful for passing
the Future from `api.requires` to have the List to be subsequently `use`d.
The Future can be resolved with an [Immutable List](https://facebook.github.io/immutable-js/docs/#/List) of middleware,
or rejected with an error if a failure occurs requiring the middleware.
```js
api.getWebpackConfig(); // -> { ... }
// Using Future to fork and handle any errors
api.useRequires(api.requires(['middleware-alpha', 'middleware-beta']))
.fork(
err => console.log('Could not import middleware', err),
() => console.log('Finished importing all middleware')
);
```
### `emitForAll(eventName, payload)`
### `register(command, handler)`
Trigger a Promise-dependent event. For example, calling `emitForAll('build')` will trigger an event named build, and
each event handler can return a Promise denoting when it is finished. When all events have finished, this call will
resolve.
This method registers a new command which can be run from the API at a later time. This function takes two
arguments: a string command name, and a function which accepts a Webpack configuration and returns a
[`Future`](https://github.com/fluture-js/Fluture).
This method returns a Promise which resolves when all event handlers have also resolved.
_Example: add a new runnable command which resolves with a JSON-formatted Webpack configuration:`
```js
api
.emitForAll('custom-event')
.then(() => console.log('All custom-events have resolved!'));
const api = Neutrino();
const Future = require('fluture');
api.register('jsonify', config => Future.of(JSON.stringify(config, null, 2)));
```
By passing an additional argument for `payload`, you can pass custom data to all the event handlers
### `run(command)`
This method returns a Future which executes a command which has been registered in the Neutrino API. It accepts a
single argument for the command name to run.
_Example: execute the `jsonify` command we registered in the `register()` example`:
```js
api.emitForAll('custom-event', { custom: 'payload' });
const api = Neutrino();
const Future = require('fluture');
api.register('jsonify', config => Future.of(JSON.stringify(config, null, 2)));
// ...
neutrino.on('custom-event', (args, payload) => {
console.log(payload.custom); // "payload"
});
api
.run('jsonify')
.fork(console.error, json => console.log(json));
```
## `run` API
The Neutrino package contains several functions automate several pieces of interacting with the Neutrino API.
There is the mid-level `run` function, and higher-level functions `build`, `inspect`, `start`, and `test`. These are
functions that are invoked when using the CLI.
Every runnable command performs the following flow:
- Instantiates a `Neutrino` API
- Sets the `NODE_ENV` environment variable
- Requires and `use`s provided middleware
- Merges any config overrides at `options.config` into the `api.config` at a higher precedence
- Triggers all `pre` events for the given command name
- Invokes `api.run` for the registered command name
- Triggers all events for the given command name
Calling a runnable command will return a [`Future`](https://github.com/fluture-js/Fluture) which can then be used to
kick off the above flow. This Future will be resolved with the resolution value of the command, or rejected
with any errors the command provides.
### `run(command, middleware, options)`
The lower-level `run` function takes three arguments:
- A string command name which the API can call
- An array of module strings which will be required and used as middleware
- An object of options that should be specified to the Neutrino API
Prior to starting this process, Neutrino will trigger and wait for `pre{command}` events to
finish. After it is complete, Neutrino will trigger and wait for `{command}` events to finish.
```js
const { run } = require('neutrino');
run('build', ['neutrino-preset-react'])
.fork(
errors => errors.forEach(console.error),
stats => console.log(stats.toString({ colors: true }))
);
```
### `start(middleware, options)`
The `start` function takes two arguments:
- An array of module strings which will be required and used as middleware
- An object of options that should be specified to the Neutrino API
The `start()` function is responsible for creating a development bundle, and when possible, starting a development
server or source watcher. Prior to starting this process, Neutrino will trigger and wait for `prestart` events to
finish. After it is complete, Neutrino will trigger and wait for `start` events to finish.
If the Neutrino config contains options for `devServer`, then a webpack-dev-server will be started, otherwise a Webpack
source watcher will be started.
Calling start will return a [`Future`](https://github.com/fluture-js/Fluture) which can then be used to
kick off the runnable flow. This Future will be resolved with a Webpack compiler (for example, if you wish to listen for
additional build events), or reject with an **array of errors**. This resolution will be completed when the dev server
or Webpack watcher has been started.
```js
const { start } = require('neutrino');
start(['neutrino-preset-react'])
.fork(
errors => errors.forEach(console.error),
compiler => console.log('App running!')
);
```
### `build(middleware, options)`
The `build` function takes two arguments:
- An array of module strings which will be required and used as middleware
- An object of options that should be specified to the Neutrino API
The `build()` function is responsible for creating a bundle typically used for production. Prior to starting this process,
Neutrino will trigger and wait for `prebuild` events to finish. After it is complete, Neutrino will trigger and wait for
`build` events to finish.
Calling start will return a [`Future`](https://github.com/fluture-js/Fluture) which can then be used to
kick off the runnable flow. This Future will be resolved with a Webpack stats object about the build, or reject with an
**array of errors**. This resolution will be completed when the build has been completed.
```js
const { build } = require('neutrino');
build(['neutrino-preset-node'])
.fork(
errors => errors.forEach(console.error),
stats => console.log(stats.toString({ colors: true }))
);
```
### `test(middleware, options)`
The `test` function takes two arguments:
- An array of module strings which will be required and used as middleware
- An object of options that should be specified to the Neutrino API
The `test()` function is responsible for gathering middleware and options needed for testing and triggering relevant
events as a signal to test middleware that they may run. Using the `test` method has no other functionality other than
performing the automated runnable flow outlined above. Since `test()` does nothing other than triggering this flow,
without middleware listening for `test` events, nothing will happen. Prior to starting this process, Neutrino will
trigger and wait for `pretest` events to finish. After it is complete, Neutrino will trigger and wait for
`test` events to finish, in which test runners will do their work.
Any `args` passed to `test()` are passed on to the event handles and typically have properties for an array of
`files` to test, as well as a property for `watch`ing and rerunning tests.
Calling start will return a [`Future`](https://github.com/fluture-js/Fluture) which can then be used to
kick off the runnable flow. This Future will be resolved, or reject with **an error**. This resolution will be completed
when the testing has been finished.
```js
const { test } = require('neutrino');
test(['neutrino-preset-node'])
.fork(
err => console.error(err),
() => console.log('Testing completed!')
);
// ---
test(['neutrino-preset-node'], { args: { files: [/* ... */], watch: true } })
.fork(
err => console.error(err),
() => console.log('Testing completed!')
);
```
### `inspect(middleware, options)`
The `inspect` function takes two arguments:
- An array of module strings which will be required and used as middleware
- An object of options that should be specified to the Neutrino API
The `inspect()` function is responsible for creating an object string which represents a Webpack configuration for the
provided middleware and options. Upon following the runnable flow, `inspect()` will:
- Grab the Webpack configuration object
- Deep-sort the object
- Stringify the object with 2 spaces (**not** JSON stringified!)
Calling start will return a [`Future`](https://github.com/fluture-js/Fluture) which can then be used to
kick off the runnable flow. This Future will be resolved with a string representation of the Webpack config, or reject
with **an error**. This resolution will be completed when the build has been completed.
```js
const { inspect } = require('neutrino');
inspect(['neutrino-preset-node'])
.fork(
err => console.error(err),
config => console.log(config)
);
```

55
docs/cli/README.md

@ -25,7 +25,8 @@ Commands:
Options:
--inspect Output a string representation of the configuration used by Neutrino and exit [boolean]
--presets A list of Neutrino presets used to configure the build [array] [default: []]
--use A list of Neutrino middleware used to configure the build [array] [default: []]
--env The value for the environment variable, NODE_ENV [string]
--version Show version number [boolean]
--help Show help [boolean]
```
@ -36,45 +37,45 @@ Using `--version` will output the current version of the Neutrino CLI to the con
```bash
❯ neutrino --version
4.0.0
5.0.0
```
## `--presets`
## `--use`
The `--presets` flag can be used in conjunction with any of the top-level commands to specify a collection of
presets to load. These can be an npm package or a relative path to a module to load as a preset.
The `--use` flag can be used in conjunction with any of the top-level commands to specify a collection of
middleware and presets to load. These can be an npm package or a relative path to a module to load as middleware.
```bash
❯ neutrino start --presets neutrino-preset-react neutrino-preset-karma
❯ neutrino start --use neutrino-preset-react neutrino-preset-karma
```
The Neutrino CLI will still attempt to load any presets defined in the project's package.json located at
`config.presets`. Presets passed via the CLI `--presets` will take precedence over presets defined in
`config.presets`, meaning that options set by package.json presets can have their values overridden by
`--presets` presets.
The Neutrino CLI will still attempt to load any presets and middleware defined in the project's package.json located at
`config.use`. Middleware passed via the CLI `--use` will take precedence over middleware defined in
`config.use`, meaning that options set by package.json middleware can have their values overridden by
`--use` middleware.
## `--inspect`
The `--inspect` flag can be used to write out a stringified version of the Webpack configuration which has been
accumulated by all middleware. When using the `--inspect` flag, the Neutrino CLI will still import all presets and
middleware that has been supplied, but will then exit after logging the configuration to stdout. No builds, servers, or
middleware that have been supplied, but will then exit after logging the configuration to stdout. No builds, servers, or
watchers will be started.
```bash
❯ neutrino start --inspect --presets neutrino-preset-react neutrino-preset-jest
❯ neutrino start --inspect --use neutrino-preset-react neutrino-preset-jest
```
This could also be used to help create diffs between configuration changes. Take the following command:
```bash
❯ neutrino start --inspect --presets neutrino-preset-react neutrino-preset-jest
❯ neutrino start --inspect --use neutrino-preset-react neutrino-preset-jest
```
We can capture this inspection to a file, and capture the change by adding a preset override:
```bash
❯ neutrino start --inspect --presets neutrino-preset-react neutrino-preset-jest > a.config
❯ neutrino start --inspect --presets neutrino-preset-react neutrino-preset-jest override.js > b.config
❯ neutrino start --inspect --use neutrino-preset-react neutrino-preset-jest > a.config
❯ neutrino start --inspect --use neutrino-preset-react neutrino-preset-jest override.js > b.config
```
Using `git diff a.config b.config`, we get a pretty diff of the configuration change:
@ -97,19 +98,19 @@ index 3356802..d4d82ef 100644
## `neutrino start`
Using the command `neutrino start` builds a project in development mode, also starting a development server or source
watcher depending on the preset or config options used. This command sets the `NODE_ENV` environment variable to
`development`.
watcher depending on the middleware or configuration used. This command sets the `NODE_ENV` environment variable to
`development` by default.
## `neutrino build`
Using the command `neutrino build` builds a project in production mode, rendering static assets to the configured build
output destination. This command sets the `NODE_ENV` environment variable to `production`.
output destination. This command sets the `NODE_ENV` environment variable to `production` by default.
## `neutrino test`
Using the command `neutrino test` passes execution onto a test runner preset. It is up to the preset being used to
determine how source files are built or provided to tests. See your particular test preset for details. This
command sets the `NODE_ENV` environment variable to `test`.
Using the command `neutrino test` passes execution onto a test runner preset. It is up to the preset or middleware being
used to determine how source files are built or provided to tests. See your particular test middleware for details. This
command sets the `NODE_ENV` environment variable to `test` by default.
Looking at the `--help` for `neutrino test`:
@ -118,8 +119,10 @@ Looking at the `--help` for `neutrino test`:
neutrino test [files..]
Options:
--presets A list of Neutrino presets used to configure the build [array] [default: []]
--inspect Output a string representation of the configuration used by Neutrino and exit [boolean] [default: false]
--use A list of Neutrino presets used to configure the build [array] [default: []]
--version Show version number [boolean]
--env The value for the environment variable, NODE_ENV [string]
--help Show help [boolean]
--coverage Collect test coverage information and generate report [boolean] [default: false]
--watch Watch source files for changes and re-run tests [boolean] [default: false]
@ -127,7 +130,7 @@ Options:
Using the command `neutrino test` will execute every test file located in your
[testing directory](../project-layout#Testing). You may also provide to this command the specific test files you wish
to run individually. It is important to note that when combined with the `--presets` parameter, you should use two
to run individually. It is important to note that when combined with the `--use` parameter, you should use two
dashes after the last preset to denote the end of the presets and the beginning of the test files.
```bash
@ -135,16 +138,16 @@ dashes after the last preset to denote the end of the presets and the beginning
```
```bash
❯ neutrino test --presets neutrino-preset-react neutrino-preset-karma -- a_test.js b_test.js
❯ neutrino test --use neutrino-preset-react neutrino-preset-karma -- a_test.js b_test.js
```
You can also pass a flag `--watch` to watch source files for changes and re-run tests, if your preset supports it.
You can also pass a flag `--watch` to watch source files for changes and re-run tests, if your middleware supports it.
```bash
❯ neutrino test --watch
```
As well you can pass a flag `--coverage` to collect test coverage information and generate a report, if your preset
As well you can pass a flag `--coverage` to collect test coverage information and generate a report, if your middleware
supports it.
```bash

4
docs/creating-presets.md

@ -47,8 +47,8 @@ middleware interacts with and makes changes through this config, which is all av
Neutrino exposes events for various stages of the build process your preset can hook into **if necessary**.
- `prestart`: Triggered before creating a development bundle or launching a dev server.
- `start`: Triggered after the development bundle has finished or the dev server has been stopped.
- `prestart`: Triggered before creating a development bundle, launching a dev server, or a source watcher.
- `start`: Triggered after the development bundle has been created the dev server or source watcher has started.
- `prebuild`: Triggered before creating a production build.
- `build`: Triggered after the production build has completed.
- `pretest`: Triggered before invoking any test runners.

2
docs/customization/advanced.md

@ -42,7 +42,7 @@ your project._
```json
{
"config": {
"presets": [
"use": [
"neutrino-preset-react",
"neutrino-preset-karma",
"override.js"

4
docs/customization/simple.md

@ -18,7 +18,7 @@ specified your presets through `neutrino` as opposed to flags through `scripts`:
```json
{
"neutrino": {
"presets": [
"use": [
"neutrino-preset-react",
"neutrino-preset-karma"
]
@ -175,7 +175,7 @@ Add a new property to `neutrino` named `config`. This will be an object where we
```json
{
"neutrino": {
"presets": [],
"use": [],
"config": {
}

4
docs/middleware/README.md

@ -34,10 +34,10 @@ api.use(middleware, options);
To use a concrete example, let's create middleware that adds an environment plugin:
```js
const Neutrino = require('neutrino');
const { Neutrino } = require('neutrino');
const { EnvironmentPlugin } = require('webpack');
const api = new Neutrino();
const api = Neutrino();
function env(neutrino, additionalVars = []) {
neutrino.config

10
docs/middleware/neutrino-middleware-eslint/README.md

@ -107,7 +107,7 @@ document that clearly in your middleware.
`neutrino-middleware-eslint` also provides a method for getting the ESLint configuration suitable for use in an eslintrc
file. Typically this is used for providing hints or fix solutions to the development environment, e.g. IDEs and text
editors. Doing this requires [creating an instance of the Neutrino API](../../api/README.md) and providing the presets uses.
If you keep this information in `neutrino.presets` in package.json, this should be relatively straightforward. By
If you keep this information in `neutrino.use` in package.json, this should be relatively straightforward. By
providing all the presets used to Neutrino, you can ensure all the linting options used across all presets will be
merged together for your development environment, without the need for copying, duplication, or loss of organization and
separation.
@ -116,11 +116,13 @@ _Example: Create a .eslintrc.js file in the root of the project._
```js
// .eslintrc.js
const Neutrino = require('neutrino');
const { Neutrino } = require('neutrino');
const pkg = require('./package.json');
const api = new Neutrino();
const api = Neutrino();
pkg.neutrino.presets.map(preset => neutrino.use(preset));
pkg.neutrino.use
.map(require)
.map(api.use);
module.exports = api.eslintrc();
```

22
docs/presets/neutrino-preset-airbnb-base/README.md

@ -49,18 +49,18 @@ linting **before** your build preset. For example, if you are building your proj
```json
{
"scripts": {
"start": "neutrino start --presets neutrino-preset-airbnb-base neutrino-preset-web",
"build": "neutrino build --presets neutrino-preset-airbnb-base neutrino-preset-web"
"start": "neutrino start --use neutrino-preset-airbnb-base neutrino-preset-web",
"build": "neutrino build --use neutrino-preset-airbnb-base neutrino-preset-web"
}
}
```
Or if you have set up Neutrino with `neutrino.presets` in your package.json:
Or if you have set up Neutrino with `neutrino.use` in your package.json:
```json
{
"neutrino": {
"presets": [
"use": [
"neutrino-preset-airbnb-base",
"neutrino-preset-web"
]
@ -190,7 +190,7 @@ Neutrino middleware, making it easy to compose and extend the configuration.
_Example: Turn off semicolons from being required as defined by the Airbnb rules._
```js
// If using as middleware, remove from presets and .use it from your override:
// If using as middleware, remove from middleware and .use it from your override:
const airbnb = require('neutrino-preset-airbnb-base');
module.exports = neutrino => {
@ -224,7 +224,7 @@ module.exports = neutrino => {
`neutrino-lint-airbnb-base` also provides a method for getting the ESLint configuration suitable for use in an eslintrc
file. Typically this is used for providing hints or fix solutions to the development environment, e.g. IDEs and text
editors. Doing this requires [creating an instance of the Neutrino API](../../api/README.md) and providing the presets uses.
If you keep this information in `neutrino.presets` in package.json, this should be relatively straightforward. By
If you keep this information in `neutrino.use` in package.json, this should be relatively straightforward. By
providing all the presets used to Neutrino, you can ensure all the linting options used across all those preset will be
merged together for your development environment, without the need for copying, duplication, or loss of organization and
separation. This is inherited from `neutrino-middleware-eslint`.
@ -233,16 +233,18 @@ _Example: Create a .eslintrc.js file in the root of the project._
```js
// .eslintrc.js
const Neutrino = require('neutrino');
const { Neutrino } = require('neutrino');
const pkg = require('./package.json');
const api = new Neutrino();
const api = Neutrino();
// If the Airbnb preset is not included in pkg.neutrino.presets,
// If the Airbnb preset is not included in pkg.neutrino.use,
// use it manually:
api.use(require('neutrino-preset-airbnb-base'));
// Add the rest of the presets:
pkg.neutrino.presets.map(preset => api.use(preset));
pkg.neutrino.use
.map(require)
.map(api.use);
module.exports = api.eslintrc();
```

6
docs/presets/neutrino-preset-jest/README.md

@ -87,17 +87,17 @@ let's pretend this is a Node.js project:
```json
{
"scripts": {
"test": "neutrino test --presets neutrino-preset-node neutrino-preset-jest"
"test": "neutrino test --use neutrino-preset-node neutrino-preset-jest"
}
}
```
Or if you have set up Neutrino with `neutrino.presets` in your package.json:
Or if you have set up Neutrino with `neutrino.use` in your package.json:
```json
{
"neutrino": {
"presets": [
"use": [
"neutrino-preset-node",
"neutrino-preset-jest"
]

6
docs/presets/neutrino-preset-karma/README.md

@ -68,17 +68,17 @@ let's pretend this is a React project:
```json
{
"scripts": {
"test": "neutrino test --presets neutrino-preset-node neutrino-preset-karma"
"test": "neutrino test --use neutrino-preset-node neutrino-preset-karma"
}
}
```
Or if you have set up Neutrino with `neutrino.presets` in your package.json:
Or if you have set up Neutrino with `neutrino.use` in your package.json:
```json
{
"neutrino": {
"presets": [
"use": [
"neutrino-preset-react",
"neutrino-preset-karma"
]

6
docs/presets/neutrino-preset-mocha/README.md

@ -66,17 +66,17 @@ let's pretend this is a Node.js project:
```json
{
"scripts": {
"test": "neutrino test --presets neutrino-preset-node neutrino-preset-mocha"
"test": "neutrino test --use neutrino-preset-node neutrino-preset-mocha"
}
}
```
Or if you have set up Neutrino with `neutrino.presets` in your package.json:
Or if you have set up Neutrino with `neutrino.use` in your package.json:
```json
{
"neutrino": {
"presets": [
"use": [
"neutrino-preset-node",
"neutrino-preset-mocha"
]

4
docs/presets/neutrino-preset-node/README.md

@ -86,8 +86,8 @@ Now edit your project's package.json to add commands for starting and building t
```json
{
"scripts": {
"start": "neutrino start --presets neutrino-preset-node",
"build": "neutrino build --presets neutrino-preset-node"
"start": "neutrino start --use neutrino-preset-node",
"build": "neutrino build --use neutrino-preset-node"
}
}
```

4
docs/presets/neutrino-preset-react/README.md

@ -75,8 +75,8 @@ Now edit your project's package.json to add commands for starting and building t
```json
{
"scripts": {
"start": "neutrino start --presets neutrino-preset-react",
"build": "neutrino build --presets neutrino-preset-react"
"start": "neutrino start --use neutrino-preset-react",
"build": "neutrino build --use neutrino-preset-react"
}
}
```

4
docs/presets/neutrino-preset-web/README.md

@ -70,8 +70,8 @@ Now edit your project's package.json to add commands for starting and building t
```json
{
"scripts": {
"start": "neutrino start --presets neutrino-preset-web",
"build": "neutrino build --presets neutrino-preset-web"
"start": "neutrino start --use neutrino-preset-web",
"build": "neutrino build --use neutrino-preset-web"
}
}
```

46
docs/upgrading-neutrino.md

@ -112,7 +112,7 @@ been renamed to `options`.
"vendor": ["react"]
}
},
"presets": [
"use": [
"neutrino-preset-react"
],
"options": {
@ -148,6 +148,8 @@ neutrino.config.module.rule('style')
}
```
- The Neutrino CLI has renamed `--presets` to `--use` to better reflect the usage of middleware and presets, and to
make the inclusion of middleware consistent with the API at `neutrino.use()`.
- Jest upgraded to v19, which changes the option `testPathDirs` to `roots`. Jest options set using
package.json can now only be done at `neutrino.options.jest` (no more package.json `jest`);
- Linting base is deprecated in favor of `neutrino-middleware-eslint`:
@ -180,19 +182,27 @@ neutrino.custom.eslintrc();
neutrino.eslintrc();
```
- The Neutrino API no longer accepts preset strings in its constructor. The constructor now accepts an options object to
- The default export of the Neutrino package is now an object with several methods, one of these being the low-level
Neutrino API:
```js
const { Neutrino } = require('neutrino');
```
- The Neutrino API has undergone significant changes and no longer needs to be called as a constructor with `new`.
- The Neutrino API no longer accepts preset strings as its argument. The function now accepts an options object to
be set at `neutrino.options`:
```js
const Neutrino = require('neutrino');
const api = new Neutrino({ mocha: { reporter: 'nyan' } });
const { Neutrino } = require('neutrino');
const api = Neutrino({ mocha: { reporter: 'nyan' } });
api.options.mocha.reporter // "nyan"
```
- Since the Neutrino API no longer accepts preset strings in its constructor, you must now pass presets and middleware
as code/functions to the `.use()` method. This means the API no longer does preset module resolution. This has been
moved to the CLI.
as code/functions to the `.use()` method.
```js
// v4 API
@ -200,14 +210,28 @@ const Neutrino = require('neutrino');
const api = new Neutrino(['neutrino-preset-node', 'neutrino-preset-mocha']);
// v5 API
const Neutrino = require('neutrino');
const api = new Neutrino();
const { Neutrino } = require('neutrino');
const api = Neutrino();
api.use(require('neutrino-preset-node'));
api.use(require('neutrino.preset-mocha'));
api.use(require('neutrino-preset-mocha'));
```
This also means the API function no longer does preset module resolution. If you wish to require presets and middleware
and have them simultaneously `use`d, use `requiresAndUses`:
```js
// v5 API
const { Neutrino } = require('neutrino');
const api = Neutrino();
api.usesAndRequires([
'neutrino-preset-node',
'neutrino-preset-mocha'
]);
```
- `neutrino.getWebpackOptions()` has been renamed to `neutrino.getWebpackConfig()` and no longer caches the configuration after being called.
- `neutrino.getWebpackOptions()` has been removed in favor of the lower level to `neutrino.config.toConfig()`.
- Using a `node` target no longer skips the watcher for a builder, it now uses the Webpack source watcher. This means
commands like `neutrino start && node build` is obsolete. `neutrino build && node build` would work to start a Node
commands like `neutrino start && node build` are obsolete. `neutrino build && node build` would work to start a Node
instance for production-built bundles.

30
docs/usage.md

@ -30,7 +30,7 @@ Usage:
```bash
# PRESET_MODULE is the name of the preset to build with, e.g. neutrino-preset-react
neutrino start --presets PRESET_MODULE
neutrino start --use PRESET_MODULE
```
Putting this into your `package.json` will allow you to build your project using either
@ -39,7 +39,7 @@ Putting this into your `package.json` will allow you to build your project using
```json
{
"scripts": {
"start": "neutrino start --presets neutrino-preset-react"
"start": "neutrino start --use neutrino-preset-react"
}
}
```
@ -53,7 +53,7 @@ steps after your build is completed.
```bash
# PRESET_MODULE is the name of the preset to build with, e.g. neutrino-preset-react
neutrino build --presets PRESET_MODULE
neutrino build --use PRESET_MODULE
```
Putting this into your `package.json` will allow you to build your project using either
@ -62,7 +62,7 @@ Putting this into your `package.json` will allow you to build your project using
```json
{
"scripts": {
"build": "neutrino build --presets neutrino-preset-react"
"build": "neutrino build --use neutrino-preset-react"
}
}
```
@ -78,7 +78,7 @@ using a Neutrino-compatible preset. Neutrino currently provides three core testi
```bash
# PRESET_MODULE is the name of the preset to build with, e.g. neutrino-preset-react
# TESTING_MODULE is the name of another preset to build with, e.g. neutrino-preset-karma
neutrino build --presets PRESET_MODULE TESTING_MODULE
neutrino build --use PRESET_MODULE TESTING_MODULE
```
Putting this into your `package.json` will allow you to test your project using either
@ -87,34 +87,34 @@ Putting this into your `package.json` will allow you to test your project using
```json
{
"scripts": {
"test": "neutrino test --presets neutrino-preset-react neutrino-preset-karma"
"test": "neutrino test --use neutrino-preset-react neutrino-preset-karma"
}
}
```
Using the command `neutrino test` will execute every test file located in your
[testing directory](./project-layout#Testing). You may also provide to this command the specific test files you wish
to run individually. It is important to note that when combined with the `--presets` parameter, you should use two
dashes after the last preset to denote the end of the presets and the beginning of the test files.
to run individually. It is important to note that when combined with the `--use` parameter, you should use two
dashes after the last middleware to denote the end of the middleware and the beginning of the test files.
```bash
neutrino test --presets PRESET_A PRESET_B -- a_test.js b_test.js
neutrino test --use PRESET_A PRESET_B -- a_test.js b_test.js
```
## Using multiple presets
All Neutrino commands support the `--presets` command line parameter, but having to specify this for each script target
can be cumbersome and verbose, especially if you have many presets. Fortunately, Neutrino also supports specifying
presets using the `neutrino.presets` field in your project's package.json file. By omitting the `--presets` flag and
specifying a `neutrino.presets` array, every call to a Neutrino command will look up which presets are configured in
your package.json.
All Neutrino commands support the `--use` command line parameter, but having to specify this for each script target
can be cumbersome and verbose, especially if you have many middleware or presets. Fortunately, Neutrino also supports
specifying presets using the `neutrino.use` field in your project's package.json file. By omitting the `--use`
flag and specifying a `neutrino.use` array, every call to a Neutrino command will look up which presets are
configured in your package.json.
This is the recommended approach when using more than one preset.
```json
{
"neutrino": {
"presets": [
"use": [
"neutrino-preset-react",
"neutrino-preset-karma"
]

2
package.json

@ -35,7 +35,7 @@
"gitbook-cli": "^2.3.0",
"gitbook-plugin-anchorjs": "^1.1.1",
"gitbook-plugin-edit-link": "^2.0.2",
"gitbook-plugin-github": "^3.0.0",
"gitbook-plugin-github": "^2.0.0",
"gitbook-plugin-npmsearchlist": "^1.0.0",
"gitbook-plugin-prism": "^2.2.0",
"oao": "^0.8.0",

2
packages/neutrino/bin/build.js

@ -8,7 +8,7 @@ module.exports = (middleware, options) => {
.fork((errors) => {
spinner.fail('Building project failed');
errors.forEach((err) => {
console.error(err.message || err.stack || err);
console.error(err.stack || err);
err.details && console.error(err.details);
});
process.exit(1);

2
packages/neutrino/bin/inspect.js

@ -2,6 +2,6 @@ const { inspect } = require('../src');
module.exports = (middleware, options) => inspect(middleware, options)
.fork((err) => {
console.error(err.message || err.stack || err);
console.error(err.stack || err);
process.exit(1);
}, console.log);

2
packages/neutrino/bin/start.js

@ -8,7 +8,7 @@ module.exports = (middleware, options) => {
.fork((errors) => {
spinner.fail('Building project failed');
errors.forEach((err) => {
console.error(err.message || err.stack || err);
console.error(err.stack || err);
err.details && console.error(err.details);
});

2
packages/neutrino/bin/test.js

@ -2,6 +2,6 @@ const { test } = require('../src');
module.exports = (middleware, options) => test(middleware, options)
.fork((err) => {
console.error(err.message || err.stack || err);
console.error(err.stack || err);
process.exit(1);
}, Function.prototype);

7
packages/neutrino/src/api.js

@ -39,7 +39,10 @@ const Api = pipe(getOptions, (options) => {
// register :: String command -> Future handler -> ()
register: (command, handler) => api.commands[command] = handler,
// requireMiddleware :: (Array String middleware) -> Future Error a
// run :: String command -> Future Error a
run: command => api.commands[command](api.config.toConfig()),
// requires :: (Array String middleware) -> Future Error (List a)
requires: middleware => List(middleware).map(pipe(
createPaths(api.options.root),
resolveAny,
@ -52,7 +55,7 @@ const Api = pipe(getOptions, (options) => {
// use :: Function middleware -> Object options -> IO ()
use: (middleware, options = {}) => middleware(api, options),
// useRequires :: Future Error a -> Future Error a
// useRequires :: Future Error (List a) -> Future Error (List a)
useRequires: requires => requires
// For all middleware, pass it to api.use()
.map(chain(Future.encase(api.use)))

2
packages/neutrino/src/index.js

@ -16,7 +16,7 @@ const run = (command, middleware, options) => {
// Trigger all pre-events for the current command
.chain(() => Future.fromPromise2(api.emitForAll, `pre${command}`, api.options.args))
// Execute the command
.chain(() => api.commands[command](api.config.toConfig()))
.chain(() => api.run(command))
// Trigger all post-command events, resolving with the value of the command execution
.chain(value => Future
.fromPromise2(api.emitForAll, command, api.options.args)

51
yarn.lock

@ -675,11 +675,11 @@ babel-types@^6.22.0, babel-types@^6.23.0, babel-types@^6.7.2:
lodash "^4.2.0"
to-fast-properties "^1.0.1"
babylon@6.15.0, babylon@^6.1.0, babylon@^6.11.0, babylon@^6.15.0:
babylon@6.15.0:
version "6.15.0"
resolved "https://registry.yarnpkg.com/babylon/-/babylon-6.15.0.tgz#ba65cfa1a80e1759b0e89fb562e27dccae70348e"
babylon@^6.16.1:
babylon@^6.1.0, babylon@^6.11.0, babylon@^6.15.0, babylon@^6.16.1:
version "6.16.1"
resolved "https://registry.yarnpkg.com/babylon/-/babylon-6.16.1.tgz#30c5a22f481978a9e7f8cdfdf496b11d94b404d3"
@ -2148,9 +2148,9 @@ gitbook-plugin-edit-link@^2.0.2:
version "2.0.2"
resolved "https://registry.yarnpkg.com/gitbook-plugin-edit-link/-/gitbook-plugin-edit-link-2.0.2.tgz#d8fcd927eced81e7a662a72d59db609eafd7e72f"
gitbook-plugin-github@^3.0.0:
version "3.0.0"
resolved "https://registry.yarnpkg.com/gitbook-plugin-github/-/gitbook-plugin-github-3.0.0.tgz#67457df98a57ea8ef9b2518b88340db370a5317b"
gitbook-plugin-github@^2.0.0:
version "2.0.0"
resolved "https://registry.yarnpkg.com/gitbook-plugin-github/-/gitbook-plugin-github-2.0.0.tgz#5166e763cfcc402d432880b7a6c85c1c54b56a8d"
gitbook-plugin-npmsearchlist@^1.0.0:
version "1.0.0"
@ -3098,7 +3098,7 @@ lodash.without@~4.1.0:
lodash._basedifference "~4.4.0"
lodash.rest "^4.0.0"
lodash@4.5.1, lodash@^4.2.0:
lodash@4.5.1:
version "4.5.1"
resolved "https://registry.yarnpkg.com/lodash/-/lodash-4.5.1.tgz#80e8a074ca5f3893a6b1c10b2a636492d710c316"
@ -3106,7 +3106,7 @@ lodash@^2.4.1:
version "2.4.2"
resolved "https://registry.yarnpkg.com/lodash/-/lodash-2.4.2.tgz#fadd834b9683073da179b3eae6d9c0d15053f73e"
lodash@^4.0.0, lodash@^4.14.0, lodash@^4.17.4, lodash@^4.3.0:
lodash@^4.0.0, lodash@^4.14.0, lodash@^4.17.4, lodash@^4.2.0, lodash@^4.3.0:
version "4.17.4"
resolved "https://registry.yarnpkg.com/lodash/-/lodash-4.17.4.tgz#78203a4d1c328ae1d86dca6460e369b57f4055ae"
@ -4238,7 +4238,7 @@ read@1, read@~1.0.1, read@~1.0.7:
dependencies:
mute-stream "~0.0.4"
"readable-stream@1 || 2", readable-stream@^2.0.0, "readable-stream@^2.0.0 || ^1.1.13", readable-stream@^2.1.0, readable-stream@^2.1.5, readable-stream@^2.2.2:
"readable-stream@1 || 2", readable-stream@^2.0.0, "readable-stream@^2.0.0 || ^1.1.13", readable-stream@^2.0.1, readable-stream@^2.0.2, readable-stream@^2.0.5, readable-stream@^2.1.0, readable-stream@^2.1.5, readable-stream@^2.2.2:
version "2.2.2"
resolved "https://registry.yarnpkg.com/readable-stream/-/readable-stream-2.2.2.tgz#a9e6fec3c7dda85f8bb1b3ba7028604556fc825e"
dependencies:
@ -4250,7 +4250,7 @@ read@1, read@~1.0.1, read@~1.0.7:
string_decoder "~0.10.x"
util-deprecate "~1.0.1"
readable-stream@^2.0.1, readable-stream@^2.0.2, readable-stream@^2.0.5, readable-stream@~2.0.5:
readable-stream@~2.0.5:
version "2.0.6"
resolved "https://registry.yarnpkg.com/readable-stream/-/readable-stream-2.0.6.tgz#8f90341e68a53ccc928788dacfcd11b36eb9b78e"
dependencies:
@ -4528,15 +4528,15 @@ right-align@^0.1.1:
dependencies:
align-text "^0.1.1"
rimraf@2, rimraf@^2.2.8, rimraf@^2.5.2, rimraf@^2.5.4, rimraf@~2.5.1, rimraf@~2.5.2, rimraf@~2.5.4:
version "2.5.4"
resolved "https://registry.yarnpkg.com/rimraf/-/rimraf-2.5.4.tgz#96800093cbf1a0c86bd95b4625467535c29dfa04"
rimraf@2, rimraf@^2.2.8, rimraf@^2.5.2, rimraf@^2.6.1:
version "2.6.1"
resolved "https://registry.yarnpkg.com/rimraf/-/rimraf-2.6.1.tgz#c2338ec643df7a1b7fe5c54fa86f57428a55f33d"
dependencies:
glob "^7.0.5"
rimraf@^2.6.1:
version "2.6.1"
resolved "https://registry.yarnpkg.com/rimraf/-/rimraf-2.6.1.tgz#c2338ec643df7a1b7fe5c54fa86f57428a55f33d"
rimraf@^2.5.4, rimraf@~2.5.1, rimraf@~2.5.2, rimraf@~2.5.4:
version "2.5.4"
resolved "https://registry.yarnpkg.com/rimraf/-/rimraf-2.5.4.tgz#96800093cbf1a0c86bd95b4625467535c29dfa04"
dependencies:
glob "^7.0.5"
@ -4574,14 +4574,14 @@ semver-diff@^2.0.0:
dependencies:
semver "^5.0.3"
"semver@2 >=2.2.1 || 3.x || 4 || 5", "semver@2 || 3 || 4 || 5", "semver@2.x || 3.x || 4 || 5", "semver@4 || 5", semver@5.1.0, "semver@^2.3.0 || 3.x || 4 || 5", semver@^5.0.3, semver@~5.1.0:
version "5.1.0"
resolved "https://registry.yarnpkg.com/semver/-/semver-5.1.0.tgz#85f2cf8550465c4df000cf7d86f6b054106ab9e5"
semver@5.3.0, semver@^5.1.0, semver@^5.3.0, semver@~5.3.0:
"semver@2 >=2.2.1 || 3.x || 4 || 5", "semver@2 || 3 || 4 || 5", "semver@2.x || 3.x || 4 || 5", "semver@4 || 5", semver@5.3.0, "semver@^2.3.0 || 3.x || 4 || 5", semver@^5.0.3, semver@^5.1.0, semver@^5.3.0, semver@~5.3.0:
version "5.3.0"
resolved "https://registry.yarnpkg.com/semver/-/semver-5.3.0.tgz#9b2ce5d3de02d17c6012ad326aa6b4d0cf54f94f"
semver@5.1.0, semver@~5.1.0:
version "5.1.0"
resolved "https://registry.yarnpkg.com/semver/-/semver-5.1.0.tgz#85f2cf8550465c4df000cf7d86f6b054106ab9e5"
semver@^4.0.3, semver@^4.1.0:
version "4.3.6"
resolved "https://registry.yarnpkg.com/semver/-/semver-4.3.6.tgz#300bc6e0e86374f7ba61068b5b1ecd57fc6532da"
@ -4902,16 +4902,7 @@ tar@^2.0.0, tar@~2.2.1:
fstream "^1.0.2"
inherits "2"
terminal-kit@^0.26.1:
version "0.26.1"
resolved "https://registry.yarnpkg.com/terminal-kit/-/terminal-kit-0.26.1.tgz#142d960c98b3afc8e800fe5ebdf9cbbea6abdfa1"
dependencies:
async-kit "^2.2.3"
nextgen-events "^0.9.8"
string-kit "^0.5.12"
tree-kit "^0.5.26"
terminal-kit@^0.26.2:
terminal-kit@^0.26.1, terminal-kit@^0.26.2:
version "0.26.2"
resolved "https://registry.yarnpkg.com/terminal-kit/-/terminal-kit-0.26.2.tgz#545e61585e90c284782a5bb0d17f6f1be9b8f1ad"
dependencies:

Loading…
Cancel
Save