Minor stylistic improvements

docs/00-introduction.md

@@ -41,7 +41,7 @@ $ rollup main.js --file bundle.js --format umd --name "myBundle"
 
 Developing software is usually easier if you break your project into smaller separate pieces, since that often removes unexpected interactions and dramatically reduces the complexity of the problems you'll need to solve, and simply writing smaller projects in the first place [isn't necessarily the answer](https://medium.com/@Rich_Harris/small-modules-it-s-not-quite-that-simple-3ca532d65de4). Unfortunately, JavaScript has not historically included this capability as a core feature in the language.
 
-This finally changed with the ES6 revision of JavaScript, which includes a syntax for importing and exporting functions and data so they can be shared between separate scripts. The specification is now fixed, but it is only implemented in modern browsers and not finalised in Node.js. Rollup allows you to write your code using the new module system, and will then compile it back down to existing supported formats such as CommonJS modules, AMD modules, and IIFE-style scripts. This means that you get to *write future-proof code*, and you also get the tremendous benefits of...
+This finally changed with the ES6 revision of JavaScript, which includes a syntax for importing and exporting functions and data so they can be shared between separate scripts. The specification is now fixed, but it is only implemented in modern browsers and not finalised in Node.js. Rollup allows you to write your code using the new module system, and will then compile it back down to existing supported formats such as CommonJS modules, AMD modules, and IIFE-style scripts. This means that you get to *write future-proof code*, and you also get the tremendous benefits of…
 
 ### Tree-Shaking
 
@@ -57,7 +57,7 @@ const query = 'Rollup';
 utils.ajax(`https://api.example.com?search=${query}`).then(handleResponse);
 ```
 
-But with ES modules, instead of importing the whole `utils` object, we can just import the one `ajax` function we need:
+With ES modules, instead of importing the whole `utils` object, we can just import the one `ajax` function we need:
 
 ```js
 // import the ajax function with an ES6 import statement

docs/04-tutorial.md

@@ -103,7 +103,7 @@ export default {
 };
 ```
 
-(Note that you can use CJS modules as well, to wit, `module.exports = {/* config */}`)
+(Note that you can use CJS modules and therefore `module.exports = {/* config */}`)
 
 To use the config file, we use the `--config` or `-c` flag:
 
@@ -196,7 +196,7 @@ const main = function () {
 module.exports = main;
 ```
 
-_Note: Only the data we actually need gets imported – `name` and `devDependencies` and other parts of `package.json` are ignored. That's **tree-shaking** in action!_
+_Note: Only the data we actually need gets imported – `name` and `devDependencies` and other parts of `package.json` are ignored. That's **tree-shaking** in action._
 
 ### Code Splitting
 
@@ -243,7 +243,7 @@ var foo = 'hello world!';
 exports.default = foo;
 ```
 
-This is very useful if you want to load and parse expensive features only once they are used.
+This is useful if you want to load and parse expensive features only once they are used.
 
 A different use for code-splitting is the ability to specify several entry points that share some dependencies. Again we extend our example to add a second entry point `src/main2.js` that statically imports `src/foo.js` just like we did in the original example:
 

docs/05-plugin-development.md

@@ -400,7 +400,7 @@ Set the deferred source of an asset.
 
 #### `this.warn(warning: string | RollupWarning, position?: number | { column: number; line: number }) => void`
 
-Using this method will queue warnings for a build. These warnings will be printed by the CLI just like internally-generated warnings (except with the plugin name), or captured by custom `onwarn` handlers.
+Using this method will queue warnings for a build. These warnings will be printed by the CLI just like internally generated warnings (except with the plugin name), or captured by custom `onwarn` handlers.
 
 The `warning` argument can be a `string` or an object with (at minimum) a `message` property:
 

docs/07-tools.md

@@ -4,7 +4,7 @@ title: Integrating Rollup With Other Tools
 
 ### With NPM Packages
 
-At some point, it's very likely that your project will depend on packages installed from NPM into your `node_modules` folder. Unlike other bundlers such as Webpack and Browserify, Rollup doesn't know "out of the box" how to handle these dependencies - we need to add some configuration.
+At some point, it's likely that your project will depend on packages installed from NPM into your `node_modules` folder. Unlike other bundlers such as Webpack and Browserify, Rollup doesn't know "out of the box" how to handle these dependencies - we need to add some configuration.
 
 Let's add a simple dependency called [the-answer](https://www.npmjs.com/package/the-answer), which exports the answer to the question of life, the universe and everything:
 
@@ -13,7 +13,7 @@ npm install the-answer
 # or `npm i the-answer`
 ```
 
-If we update our `src/main.js` file...
+If we update our `src/main.js` file…
 
 ```js
 // src/main.js
@@ -24,13 +24,13 @@ export default function () {
 }
 ```
 
-...and run Rollup...
+…and run Rollup…
 
 ```console
 npm run build
 ```
 
-...we'll see a warning like this:
+…we'll see a warning like this:
 
 ```
 (!) Unresolved dependencies
@@ -43,13 +43,13 @@ The resulting `bundle.js` will still work in Node.js, because the `import` decla
 
 #### rollup-plugin-node-resolve
 
-The [rollup-plugin-node-resolve](https://github.com/rollup/rollup-plugin-node-resolve) plugin teaches Rollup how to find external modules. Install it...
+The [rollup-plugin-node-resolve](https://github.com/rollup/rollup-plugin-node-resolve) plugin teaches Rollup how to find external modules. Install it…
 
 ```console
 npm install --save-dev rollup-plugin-node-resolve
 ```
 
-...and add it to your config file:
+…and add it to your config file:
 
 ```js
 // rollup.config.js
@@ -111,7 +111,7 @@ export default {
 };
 ```
 
-Voila, `lodash` will now be treated as external, and not be bundled with your library.
+Voilà, `lodash` will now be treated as external, and not be bundled with your library.
 
 The `external` key accepts either an array of module names, or a function which takes the module name and returns true if it should be treated as external. For example:
 

docs/08-troubleshooting.md

@@ -71,13 +71,13 @@ Usually, a plugin will only omit the sourcemap if it (the plugin, not the bundle
 
 ### Warning: "Treating [module] as external dependency"
 
-Rollup will only resolve *relative* module IDs by default. This means that an import statement like this...
+Rollup will only resolve *relative* module IDs by default. This means that an import statement like this…
 
 ```js
 import moment from 'moment';
 ```
 
-...won't result in `moment` being included in your bundle – instead, it will be an external dependency that is required at runtime. If that's what you want, you can suppress this warning with the `external` option, which makes your intentions explicit:
+…won't result in `moment` being included in your bundle – instead, it will be an external dependency that is required at runtime. If that's what you want, you can suppress this warning with the `external` option, which makes your intentions explicit:
 
 ```js
 // rollup.config.js

docs/999-big-list-of-options.md

@@ -137,13 +137,13 @@ Specifies the format of the generated bundle. One of the following:
 Type: `{ [id: string]: string } | ((id: string) => string)`<br>
 CLI: `-g`/`--globals <external-id:variableName,another-external-id:anotherVariableName,...>`
 
-Specifies `id: variableName` pairs necessary for external imports in `umd`/`iife` bundles. For example, in a case like this...
+Specifies `id: variableName` pairs necessary for external imports in `umd`/`iife` bundles. For example, in a case like this…
 
 ```js
 import $ from 'jquery';
 ```
 
-...we want to tell Rollup that `jquery` is external and the `jquery` module ID equates to the global `$` variable:
+…we want to tell Rollup that `jquery` is external and the `jquery` module ID equates to the global `$` variable:
 
 ```js
 // rollup.config.js
@@ -229,7 +229,7 @@ this.a.b.c = ...
 #### plugins
 Type: `Plugin | (Plugin | void)[]`
 
-See [Using plugins](guide/en/#using-plugins) for more information on how to use plugins and [Plugins](guide/en/#plugin-development) on how to write your own (try it out, it's not as difficult as it may sound and very much extends what you can do with Rollup!). For plugins imported from packages, remember to call the imported plugin function (i.e. `commonjs()`, not just `commonjs`). Falsy plugins will be ignored, which can be used to easily activate or deactivate plugins.
+See [Using plugins](guide/en/#using-plugins) for more information on how to use plugins and [Plugins](guide/en/#plugin-development) on how to write your own (try it out, it's not as difficult as it may sound and very much extends what you can do with Rollup). For plugins imported from packages, remember to call the imported plugin function (i.e. `commonjs()`, not just `commonjs`). Falsy plugins will be ignored, which can be used to easily activate or deactivate plugins.
 
 ```js
 // rollup.config.js
@@ -719,7 +719,7 @@ Type: `boolean`<br>
 CLI: `--strict`/`--no-strict`<br>
 Default: `true`
 
-Whether to include the 'use strict' pragma at the top of generated non-ESM bundles. Strictly-speaking, ES modules are *always* in strict mode, so you shouldn't disable this without good reason.
+Whether to include the 'use strict' pragma at the top of generated non-ESM bundles. Strictly speaking, ES modules are *always* in strict mode, so you shouldn't disable this without good reason.
 
 #### output.dynamicImportFunction
 Type: `string`<br>