testem 3.19.1 → 3.20.1

package/README.md

@@ -1,49 +1,50 @@
 Got Scripts? Test’em!
 =================
 
-[![Build Status](https://github.com/testem/testem/actions/workflows/ci.yml/badge.svg?branch=master)](https://github.com/testem/testem/actions/workflows/ci.yml?query=branch%3Amaster) [![npm version](https://badge.fury.io/js/testem.svg)](http://badge.fury.io/js/testem)
+[![Build Status](https://github.com/testem/testem/actions/workflows/ci.yml/badge.svg?branch=master)](https://github.com/testem/testem/actions/workflows/ci.yml?query=branch%3Amaster) [![npm version](https://badge.fury.io/js/testem.svg)](https://badge.fury.io/js/testem)
 
-Unit testing in Javascript can be tedious and painful, but Testem makes it so easy that you will actually *want* to write tests.
+Testem is a **JavaScript test runner** that runs your tests in **real desktop browsers**—Chrome, Firefox, Safari, Edge, and others you launch—so your specs execute in the same browser engines and DOM your users get, not a pretend environment. It also runs tests in **[Node](https://nodejs.org/)**, **Chrome** (including **headless** runs via `browser_args`, e.g. `--headless`), or any launcher you configure. It is **framework-agnostic** and aimed at **any kind of tests** you want to run: unit, integration, end-to-end style suites, or custom setups—you pick the style; Testem wires it to the browser or process.
+
+Unit testing in JavaScript can be tedious and painful, but Testem makes it so easy that you will actually *want* to write tests.
 
 Features
 --------
 
-* Test-framework agnostic. Support for
-    - [Jasmine](http://jasmine.github.io/)
-    - [QUnit](http://qunitjs.com/)
-    - [Mocha](http://mochajs.org/)
+* Test-framework agnostic — designed for **any kind of tests** that fit your project (unit, integration, custom runners, etc.), not a single prescribed style. Support for
+    - [Jasmine](https://jasmine.github.io/)
+    - [QUnit](https://qunitjs.com/)
+    - [Mocha](https://mochajs.org/)
     - Others, through custom test framework adapters.
-* Run tests in all major browsers as well as [Node](http://nodejs.org) and [PhantomJS](http://phantomjs.org/)
+* Run tests in **all** major **real** browsers (your tests load and run in the actual browser) as well as [Node](https://nodejs.org) and **Chrome** (use `browser_args` with `--headless` for headless runs—see `docs/browser_args.md`)
 * Two distinct use-cases:
     - Test-Driven-Development(TDD) — designed to streamline the TDD workflow
-    - Continuous Integration(CI) — designed to work well with popular CI servers like Jenkins or Teamcity
+    - Continuous Integration(CI) — designed to work well with **GitHub Actions** and other CI systems, including Jenkins and TeamCity
 * Cross-platform support
-    - OS X
+    - macOS
     - Windows
     - Linux
 * Preprocessor support
-    - CoffeeScript
+    - Babel
+    - TypeScript
     - Browserify
-    - JSHint/JSLint
+    - ESLint/JSHint/JSLint
+    - CoffeeScript
     - everything else
 
-Screencasts
------------
-
-* Watch this **[introductory screencast (11:39)](http://www.youtube.com/watch?v=-1mjv4yk5JM)** to see it in action! This one demonstrates the TDD workflow.
-* [Launchers (12:10)](http://www.youtube.com/watch?v=Up0lVjWk9Rk) — more detail about launchers: how to specify what to auto-launch and how to configure one yourself to run tests in **Node**.
-* [Continuous Integration (CI) Mode (4:24)](http://www.youtube.com/watch?v=Js16Cj80HKY) — details about how CI mode works.
-* [Making JavaScript Testing Fun With Testem (22:53)](http://net.tutsplus.com/tutorials/javascript-ajax/make-javascript-testing-fun-with-testem/) — a thorough screencast by NetTuts+'s Jeffery Way covering the basics, Jasmine, Mocha/Chai, CoffeeScript and more!
-
 Installation
 ------------
-You need [Node](http://nodejs.org/) version 0.10+ or iojs installed on your system. Node is extremely easy to install and has a small footprint, and is really awesome otherwise too, so [just do it](http://nodejs.org/).
+Testem needs a supported **[Node.js](https://nodejs.org/)** runtime. The required range is defined in [`package.json`](package.json) under `engines` (currently **^20.19.0**, **^22.12.0**, or **>=24.0.0**).
+
+**Recommended:** install Testem **both** as a **dev dependency** (so your project pins a version) **and** **globally** (so the `testem` command is always available on your `PATH`):
 
-Once you have Node installed:
+```bash
+npm install testem --save-dev
+npm install testem -g
+```
 
-    npm install testem -g
+When you run the global `testem` inside a project directory that has a local `testem` install, the CLI **automatically re-runs the local copy** so the version stays in sync with `package.json`. Set **`TESTEM_USE_GLOBAL=1`** if you ever need to force the global binary only.
 
-This will install the `testem` executable globally on your system.
+This README uses the `testem` command in examples; add it to npm scripts or invoke it as `testem` from a shell after the installs above.
 
 Usage
 -----
@@ -61,7 +62,7 @@ You will see a terminal-based interface which looks like this
 
 ![Initial interface](https://github.com/testem/testem/raw/master/images/initial.png)
 
-Now open your browser and go to the specified URL. You should now see
+Now open a **real browser** (the URL Testem prints is a normal page in Chrome, Firefox, Safari, etc.) and go to the specified URL. You should now see
 
 ![Zero of zero](https://github.com/testem/testem/raw/master/images/zeros.png)
 
@@ -107,6 +108,28 @@ In development mode, Testem has a text-based graphical user interface which uses
 * d : half a page down target text panel
 * u : half a page up target text panel
 
+### File watching
+
+In development mode, Testem watches your project directory for changes and re-runs tests when a
+relevant file is added, edited, or removed. Watching is implemented with
+[chokidar](https://github.com/paulmillr/chokidar) (v5).
+
+* **`src_files`** — Glob patterns for source files whose changes should trigger a run (defaults to
+  `*.js` when unset). This is the main *watch list*.
+* **`watch_files`** — Optional; if set, these patterns are watched instead of defaulting to
+  `src_files` (see `docs/config_file.md`).
+* **`src_files_ignore`** — Patterns to exclude from the watch policy (e.g. `node_modules`).
+* **`disable_watching`** — Set to `true` to turn off the file watcher entirely.
+
+Testem watches the **current working directory** and applies your include/ignore patterns to
+events from the watcher. You do not need to list every file explicitly; globs and ignores follow
+the same policy as in the config reference.
+
+**Troubleshooting:** On some setups (Docker, network filesystems, VMs), native `fs.watch` can be
+flaky. Chokidar supports environment variables such as `CHOKIDAR_USE_POLLING=1` (force polling)
+and `CHOKIDAR_INTERVAL` (polling interval in ms). See the
+[chokidar readme](https://github.com/paulmillr/chokidar) for details.
+
 ### Command line options
 
 To see all command line options
@@ -120,6 +143,8 @@ To use Testem for continuous integration
 
     testem ci
 
+**GitHub Actions** is a common way to run Testem in CI: add a workflow job that runs `testem ci` (often with the **Headless Chrome** or **Chromium** launcher). This project’s own workflow is in [`.github/workflows/ci.yml`](https://github.com/testem/testem/blob/master/.github/workflows/ci.yml).
+
 In CI mode, Testem runs your tests on all the browsers that are available on the system one after another.
 
 You can run multiple browsers in parallel in CI mode by specifying the `--parallel` (or `-P`) option to be the number of concurrent running browsers.
@@ -134,21 +159,18 @@ Will print them out. The output might look like
 
     $ testem launchers
     Browsers available on this system:
-    IE7
-    IE8
-    IE9
+    IE11
     Chrome
     Firefox
     Safari
     Safari Technology Preview
     Opera
-    PhantomJS
 
-Did you notice that this system has IE versions 7-9? Yes, actually it has only IE9 installed, but Testem uses IE's compatibility mode feature to emulate IE 7 and 8.
+Your machine may list other launchers too. For **headless** runs, prefer **Chrome** with `browser_args` (for example `--headless`) rather than the deprecated PhantomJS launcher—see `docs/browser_args.md`.
 
-When you run `testem ci` to run tests, it outputs the results in the [TAP](http://testanything.org/) format by default, which looks like
+When you run `testem ci` to run tests, it outputs the results in the [TAP](https://testanything.org/) format by default, which looks like
 
-    ok 1 Chrome 16.0 - hello should say hello.
+    ok 1 Chrome 130.0 - hello should say hello.
 
     1..1
     # tests 1
@@ -156,9 +178,9 @@ When you run `testem ci` to run tests, it outputs the results in the [TAP](http:
 
     # ok
 
-TAP is a human-readable and language-agnostic test result format. TAP plugins exist for popular CI servers
+TAP is a human-readable and language-agnostic test result format. On **GitHub Actions**, a typical pattern is a step that runs `testem ci` and relies on the exit code to fail the job (see [`.github/workflows/ci.yml`](https://github.com/testem/testem/blob/master/.github/workflows/ci.yml) in this repository). For **Jenkins** and **TeamCity**, use TAP plugins:
 
-* [Jenkins TAP plugin](https://wiki.jenkins-ci.org/display/JENKINS/TAP+Plugin) - I've added [detailed instructions](https://github.com/testem/testem/blob/master/docs/use_with_jenkins.md) for setup with Jenkins.
+* [Jenkins TAP plugin](https://plugins.jenkins.io/tap/) - I've added [detailed instructions](https://github.com/testem/testem/blob/master/docs/use_with_jenkins.md) for setup with Jenkins.
 * [TeamCity TAP plugin](https://github.com/pavelsher/teamcity-tap-parser)
 
 ## TAP Options
@@ -203,13 +225,14 @@ Testem has other test reporters besides TAP: `dot`, `xunit` and `teamcity`. You
 
 You can also [add your own reporter](docs/custom_reporter.md).
 
-### Example xunit reporter output
+<details>
+<summary>Example <code>xunit</code> reporter output</summary>
 
 Note that the real output is not pretty printed.
 ```xml
-<testsuite name="Testem Tests" tests="4" failures="1" timestamp="Wed Apr 01 2015 11:56:20 GMT+0100 (GMT Daylight Time)" time="9">
-  <testcase classname="PhantomJS 1.9" name="myFunc returns true when input is valid" time="0"/>
-  <testcase classname="PhantomJS 1.9" name="myFunc returns false when user tickles it" time="0"/>
+<testsuite name="Testem Tests" tests="4" failures="1" timestamp="2026-04-25T10:00:00.000Z" time="9">
+  <testcase classname="Firefox 128" name="myFunc returns true when input is valid" time="0"/>
+  <testcase classname="Firefox 128" name="myFunc returns false when user tickles it" time="0"/>
   <testcase classname="Chrome" name="myFunc returns true when input is valid" time="0"/>
   <testcase classname="Chrome" name="myFunc returns false when user tickles it" time="0">
     <failure name="myFunc returns false when user tickles it" message="function is not ticklish">
@@ -221,17 +244,24 @@ Note that the real output is not pretty printed.
 </testsuite>
 ```
 
-### Example teamcity reporter output
+</details>
 
-    ##teamcity[testStarted name='PhantomJS 1.9 - hello should say hello']
-    ##teamcity[testFinished name='PhantomJS 1.9 - hello should say hello']
-    ##teamcity[testStarted name='PhantomJS 1.9 - hello should say hello to person']
-    ##teamcity[testFinished name='PhantomJS 1.9 - hello should say hello to person']
-    ##teamcity[testStarted name='PhantomJS 1.9 - goodbye should say goodbye']
-    ##teamcity[testFailed name='PhantomJS 1.9 - goodbye should say goodbye' message='expected |'hello world|' to equal |'goodbye world|'' details='AssertionError: expected |'hello world|' to equal |'goodbye world|'|n    at http://localhost:7357/testem/chai.js:873|n    at assertEqual (http://localhost:7357/testem/chai.js:1386)|n    at http://localhost:7357/testem/chai.js:3627|n    at http://localhost:7357/hello_spec.js:14|n    at callFn (http://localhost:7357/testem/mocha.js:4338)|n    at http://localhost:7357/testem/mocha.js:4331|n    at http://localhost:7357/testem/mocha.js:4728|n    at http://localhost:7357/testem/mocha.js:4819|n    at next (http://localhost:7357/testem/mocha.js:4653)|n    at http://localhost:7357/testem/mocha.js:4663|n    at next (http://localhost:7357/testem/mocha.js:4601)|n    at http://localhost:7357/testem/mocha.js:4630|n    at timeslice (http://localhost:7357/testem/mocha.js:5761)']
-    ##teamcity[testFinished name='PhantomJS 1.9 - goodbye should say goodbye']
+<details>
+<summary>Example <code>teamcity</code> reporter output</summary>
 
-    ##teamcity[testSuiteFinished name='mocha.suite' duration='11091']
+```text
+##teamcity[testStarted name='Firefox 128 - hello should say hello']
+##teamcity[testFinished name='Firefox 128 - hello should say hello']
+##teamcity[testStarted name='Firefox 128 - hello should say hello to person']
+##teamcity[testFinished name='Firefox 128 - hello should say hello to person']
+##teamcity[testStarted name='Firefox 128 - goodbye should say goodbye']
+##teamcity[testFailed name='Firefox 128 - goodbye should say goodbye' message='expected |'hello world|' to equal |'goodbye world|'' details='AssertionError: expected |'hello world|' to equal |'goodbye world|'|n    at http://localhost:7357/testem/chai.js:873|n    at assertEqual (http://localhost:7357/testem/chai.js:1386)|n    at http://localhost:7357/testem/chai.js:3627|n    at http://localhost:7357/hello_spec.js:14|n    at callFn (http://localhost:7357/testem/mocha.js:4338)|n    at http://localhost:7357/testem/mocha.js:4331|n    at http://localhost:7357/testem/mocha.js:4728|n    at http://localhost:7357/testem/mocha.js:4819|n    at next (http://localhost:7357/testem/mocha.js:4653)|n    at http://localhost:7357/testem/mocha.js:4663|n    at next (http://localhost:7357/testem/mocha.js:4601)|n    at http://localhost:7357/testem/mocha.js:4630|n    at timeslice (http://localhost:7357/testem/mocha.js:5761)']
+##teamcity[testFinished name='Firefox 128 - goodbye should say goodbye']
+
+##teamcity[testSuiteFinished name='mocha.suite' duration='11091']
+```
+
+</details>
 
 ### Command line options
 
@@ -242,9 +272,9 @@ To see all command line options for CI
 Configuration File
 ------------------
 
-For the simplest JavaScript projects, the TDD workflow described above will work fine. There are times when you want
-to structure your source files into separate directories, or want to have finer control over what files to include.
-This calls for the `testem.json` configuration file (you can also alternatively use the YAML format with a `testem.yml` file). It looks like
+For the simplest JavaScript projects, the TDD workflow described above will work fine. There are times when you want to structure your source files into separate directories, or want to have finer control over what files to include.
+
+This calls for the `testem.json` configuration file (you can also alternatively use the YAML format with a `testem.yml` file or return json from a javascript file `testem.js`). It looks like
 
 ```json
 {
@@ -312,10 +342,10 @@ Or if you are using require.js or another loader, just make sure you load `/test
 
 ### Dynamic Substitution
 
-To enable dynamic substitutions within the Javascript files in your custom test page, you must
+To enable dynamic substitutions within the JavaScript files in your custom test page, you must
 
 1. name your test page using `.mustache` as the extension
-2. use `{{#serve_files}}` to loop over the set of Javascript files to be served, and then reference its `src` property to access their path (or `{{#css_files}}` for stylesheets)
+2. use `{{#serve_files}}` to loop over the set of JavaScript files to be served, and then reference its `src` property to access their path (or `{{#css_files}}` for stylesheets)
 
 Example:
 
@@ -369,14 +399,14 @@ You can add your own custom paths to browser binaries by including `browser_path
 
 ```javascript
 "browser_paths": {
-  "Chromium": "./node_modules/puppeteer/.local-chromium/mac-549031/chrome-mac/Chromium.app/Contents/MacOS/Chromium"
+  "Chromium": "./path/to/chromium"
 }
 "browser_exes": {
   "Chromium": "chrome-custom-binary"
 }
 ```
 
-Adding a browser_path for a browser will override all default places for testem to look for the browser. So if the browser doesn't exist at the path you provided, you will get failures.
+Set `Chromium` to a real browser binary path, for example the Chromium or Chrome under your Puppeteer install (the exact `path/to/chromium` depends on your platform and Puppeteer version). Adding a browser_path for a browser will override all default places for testem to look for the browser. So if the browser doesn't exist at the path you provided, you will get failures.
 
 Customizing Browser Arguments
 -----------------------------
@@ -413,7 +443,7 @@ When you run `testem`, it will auto-launch the mocha process based on the specif
 Processes with TAP Output
 -------------------------
 
-If your process outputs test results in [TAP](http://en.wikipedia.org/wiki/Test_Anything_Protocol) format, you can tell that to testem via the `protocol` property. For example
+If your process outputs test results in [TAP](https://en.wikipedia.org/wiki/Test_Anything_Protocol) format, you can tell that to testem via the `protocol` property. For example
 
 ```javascript
 "launchers": {
@@ -426,60 +456,38 @@ If your process outputs test results in [TAP](http://en.wikipedia.org/wiki/Test_
 
 When this is done, Testem will read in the process's stdout and parse it as TAP, and then display the test results in Testem's normal format. It will also hide the process's stdout output from the console log panel, although it will still display the stderr.
 
-PhantomJS
----------
+Headless Chrome
+---------------
 
-PhantomJS is a Webkit-based headless browser. It's fast and it's awesome! Testem will pick it up if you have [PhantomJS](http://www.phantomjs.org/) installed in your system and the `phantomjs` executable is in your path. Run
+Testem ships a **Headless Chrome** launcher that runs [Google Chrome](https://www.google.com/chrome/) (or Chromium where that is the detected binary) with **`--headless`**, **`--disable-gpu`**, and other defaults suitable for CI and unattended runs. You need Chrome installed; run
 
     testem launchers
 
-And verify that it's in the list.
-
-If you want to debug tests in PhantomJS, include the `phantomjs_debug_port` option in your testem configuration, referencing an available port number.  Once testem has started PhantomJS, navigate (with a traditional browser) to http://localhost:<port> and attach to one of PhantomJS's browser tabs (probably the second one in the list).  `debugger` statements will now break in the debugging console.
-
-If you want to use any of the [PhantomJS command line options](http://phantomjs.org/api/command-line.html), include the `phantomjs_args` option in your testem configuration. For example:
-
-```javascript
-"phantomjs_args": [
-  "--ignore-ssl-errors=true"
-]
-```
-
-You can also customize the phantomjs launcher file by specifying the `phantomjs_launch_script` option.
-In this launcher you can change options like the `viewPortSize`. See `assets/phantom.js` for the default launcher.
-
-Preprocessors (CoffeeScript, LESS, Sass, Browserify, etc)
----------------------------------------------------------
-
-If you need to run a preprocessor (or indeed any shell command before the start of the tests) use the `before_tests` option, such as
+and confirm **Headless Chrome** appears.
 
-    "before_tests": "coffee -c *.coffee"
+Select it like any other launcher, for example:
 
-And Testem will run it before each test run. For file watching, you may still use the `src_files` option
-
-```javascript
-"src_files": [
-  "*.coffee"
-]
+```json
+{
+  "launch_in_ci": ["Headless Chrome"]
+}
 ```
 
-Since you want to be serving the `.js` files that are generated and not the `.coffee` files, you want to specify the `serve_files` option to tell it that
+To add or override flags, use **`browser_args`** (see [`docs/browser_args.md`](docs/browser_args.md)). Testem merges these with the built-in headless arguments—for example a fixed remote-debugging port for attaching DevTools:
 
-```javascript
-"serve_files": [
-  "*.js"
-]
+```json
+{
+  "browser_args": {
+    "Headless Chrome": ["--remote-debugging-port=9222"]
+  }
+}
 ```
 
-Testem will throw up a big ol' error dialog if the preprocessor command exits with an error code, so code checkers like jshint can be used here as well.
+**Remote debugging:** By default the headless launcher passes **`--remote-debugging-port=0`**, so Chrome chooses a random port—set a **fixed** port in `browser_args` (as in the example above) so you can connect reliably. With Testem running, open a regular Chrome window to **`chrome://inspect`**, use **Configure…** under “Discover network targets” to add **`localhost:9222`** (or whatever port you set), find your test page under **Remote Target**, and click **inspect**. You can also open **`http://localhost:9222`** and follow the links to a target page. **`debugger`** statements and breakpoints work in the DevTools **Sources** panel.
 
-If you need to run a command after your tests have completed (such as removing compiled `.js` files), use the `after_tests` option.
+**Headless Chrome Beta** is available when the Chrome Beta channel is installed. For legacy **PhantomJS**-specific options (`phantomjs_args`, `phantomjs_debug_port`, etc.), see [`docs/config_file.md`](docs/config_file.md).
 
-```javascript
-"after_tests": "rm *.js"
-```
-
-If you would prefer simply to clean up when Testem exits, you can use the `on_exit` option.
+**Internet Explorer** and the legacy **PhantomJS** launcher are still available, but we document them as **deprecated** targets: keeping them viable through transpilation and polyfills is likely to get more difficult over time, so prefer evergreen browsers, **Chrome** with `--headless` for headless automation, or Node for new projects. See the [configuration reference](docs/config_file.md) for how we categorize browsers.
 
 Running browser code after tests complete
 -------------
@@ -517,7 +525,7 @@ Sometimes you may want to re-map a URL to a different directory on the file syst
     + public
       + tests.html
 
-Let's say you want to serve `tests.html` at the top level url `/tests.html`, all the Javascripts under `/js` and all the css under `/css`. You can use the "routes" option to do that
+Let's say you want to serve `tests.html` at the top level url `/tests.html`, all the JavaScript files under `/js` and all the css under `/css`. You can use the "routes" option to do that
 
 ```javascript
 "routes": {
@@ -543,7 +551,7 @@ And then make sure you include the adapter code in your test suite and you are r
 Native notifications
 --------------------------------
 
-If you'd prefer not to be looking at the terminal while developing, you can enable native notifications (e.g. notification center, growl) using the `-g` option.
+If you'd prefer not to be looking at the terminal while developing, you can enable native notifications (e.g. Notification Center on macOS) using the `-g` option.
 
 API Proxy
 --------------------------------
@@ -568,77 +576,110 @@ Simply add a `proxies` section to the `testem.json` configuration file.
 ```
 
 This functionality is implemented as a *transparent proxy*, hence a request to
-`http://localhost:7357/api/posts.json` will be proxied to `http://localhost:4200/api/posts.json` without removing the `/api` prefix. Setting the `secure` option to `false` as in the above `/xmlapi` configuration block will ignore TLS certificate validation and allow tests to successfully reach that URL even if testem was launched over HTTP. Other available options can be found here: https://github.com/nodejitsu/node-http-proxy#options
+`http://localhost:7357/api/posts.json` will be proxied to `http://localhost:4200/api/posts.json` without removing the `/api` prefix. Setting the `secure` option to `false` as in the above `/xmlapi` configuration block will ignore TLS certificate validation and allow tests to successfully reach that URL even if testem was launched over HTTP. Other available options can be found here: https://github.com/http-party/node-http-proxy#options
 
 To limit the functionality to only certain content types, use "onlyContentTypes".
 
+Preprocessors (Babel, TypeScript, LESS, Sass, Browserify, CoffeeScript, etc)
+---------------------------------------------------------
+
+If you need to run a preprocessor (or indeed any shell command before the start of the tests) use the `before_tests` option, such as
+
+    "before_tests": "coffee -c *.coffee"
+
+or, with Babel (see the [Babel example](https://github.com/testem/testem/tree/master/examples/babel)):
+
+    "before_tests": "babel src --out-dir ."
+
+or, with a `tsconfig.json` that emits JavaScript next to your project (see the [TypeScript example](https://github.com/testem/testem/tree/master/examples/typescript)):
+
+    "before_tests": "tsc"
+
+And Testem will run it before each test run. Point **`src_files`** at the sources you want
+watched (see **File watching** under Development Mode above).
+
+```javascript
+"src_files": [
+  "*.coffee"
+]
+```
+
+Since you want to be serving the `.js` files that are generated and not the `.coffee` files, you want to specify the `serve_files` option to tell it that
+
+```javascript
+"serve_files": [
+  "*.js"
+]
+```
+
+Testem will throw up a big ol' error dialog if the preprocessor command exits with an error code, so code checkers like JSHint or ESLint can be used here as well.
+
+If you need to run a command after your tests have completed (such as removing compiled `.js` files), use the `after_tests` option.
+
+```javascript
+"after_tests": "rm *.js"
+```
+
+If you would prefer simply to clean up when Testem exits, you can use the `on_exit` option.
+
 Example Projects
 ----------------
 
 I've created [examples](https://github.com/testem/testem/tree/master/examples/) for various setups
 
+* [Vite (middleware + plugin)](https://github.com/testem/testem/tree/master/examples/vite)
+* [Electron](https://github.com/testem/testem/tree/master/examples/electron)
+* [TypeScript Project](https://github.com/testem/testem/tree/master/examples/typescript)
+* [ESLint Example](https://github.com/testem/testem/tree/master/examples/eslint)
+* [Babel Project](https://github.com/testem/testem/tree/master/examples/babel)
 * [Simple QUnit project](https://github.com/testem/testem/tree/master/examples/qunit_simple)
 * [Simple Jasmine project](https://github.com/testem/testem/tree/master/examples/jasmine_simple)
 * [Jasmine 2](https://github.com/testem/testem/tree/master/examples/jasmine2)
 * [Custom Jasmine project](https://github.com/testem/testem/tree/master/examples/jasmine_custom)
-* [Custom Jasmine project using Require.js](https://github.com/testem/testem/tree/master/examples/jasmine_requirejs)
 * [Simple Mocha Project](https://github.com/testem/testem/tree/master/examples/mocha_simple)
 * [Mocha + Chai](https://github.com/testem/testem/tree/master/examples/mocha_chai_simple)
 * [Hybrid Project](https://github.com/testem/testem/tree/master/examples/hybrid_simple) - Mocha tests running in both the browser and Node.
-* [Coffeescript Project](https://github.com/testem/testem/tree/master/examples/coffeescript)
-* [Browserify Project](https://github.com/testem/testem/tree/master/examples/browserify)
-* [JSHint Example](https://github.com/testem/testem/tree/master/examples/jshint)
 * [Custom Test Framework](https://github.com/testem/testem/tree/master/examples/custom_adapter)
 * [Tape Example](https://github.com/testem/testem/tree/master/examples/tape_example)
-* [BrowserStack Integration](https://github.com/testem/testem/tree/master/examples/browserstack) **bleeding edge**
-* [SauceLabs Integration](https://github.com/testem/testem/tree/master/examples/saucelabs) **bleeding edge**
-* [Code Coverage with Istanbul](https://github.com/testem/testem/tree/master/examples/coverage_istanbul) **bleeding edge**
-
-Known Issues
-------------
+* [Browserify Project](https://github.com/testem/testem/tree/master/examples/browserify)
+* [JSHint Example](https://github.com/testem/testem/tree/master/examples/jshint)
+* [Coffeescript Project](https://github.com/testem/testem/tree/master/examples/coffeescript)
+* [Custom Jasmine project using Require.js](https://github.com/testem/testem/tree/master/examples/jasmine_requirejs)
+* [BrowserStack Integration](https://github.com/testem/testem/tree/master/examples/browserstack)
+* [SauceLabs Integration](https://github.com/testem/testem/tree/master/examples/saucelabs)
+* [Code Coverage with Istanbul](https://github.com/testem/testem/tree/master/examples/coverage_istanbul)
 
-1. On Windows, Mocha fails to run under Testem due to an [issue](https://github.com/joyent/node/issues/3871) in Node core. Until that gets resolved, I've made a [workaround](https://github.com/airportyh/mocha/tree/windowsfix) for Mocha. To install this fork of Mocha, do
+Historical Screencasts
+----------------------
 
-        npm install https://github.com/airportyh/mocha/tarball/windowsfix -g
+These YouTube screencasts are from around **2012** and may not match the current UI or features, but they still illustrate the core ideas:
 
-2. If you are using prototype.js version 1.6.3 or below, you will [encounter issues](https://github.com/testem/testem/issues/130).
+* **[Introductory screencast (11:39)](https://www.youtube.com/watch?v=-1mjv4yk5JM)** &mdash; TDD workflow
+* **[Launchers (12:10)](https://www.youtube.com/watch?v=Up0lVjWk9Rk)** &mdash; auto-launch and running tests in **Node**
+* **[CI mode (4:24)](https://www.youtube.com/watch?v=Js16Cj80HKY)** &mdash; continuous integration
 
 Contributing
 ------------
 
 If you want to [contribute to the project](https://github.com/testem/testem/blob/master/CONTRIBUTING.md), I am going to do my best to stay out of your way.
 
-Roadmap
--------
-
-1. [BrowserStack](http://www.browserstack.com/user/dashboard) integration - following [Bunyip](http://www.thecssninja.com/javascript/bunyip)'s example
-2. Figure out a happy path for testing on mobile browsers (maybe BrowserStack).
-
 Core Maintainer(s)
 ------------------
 
 * [Johannes Würbach](https://github.com/johanneswuerbach)
 
-Community
----------
-
-* **Mailing list**: <https://groups.google.com/forum/?fromgroups#!forum/testem-users>
-
 Credits
 -------
 
 Testem depends on the following great software
 
-* [Jasmine](http://jasmine.github.io/)
-* [QUnit](http://code.google.com/p/jqunit/)
-* [Mocha](http://mochajs.org/)
-* [Node](http://nodejs.org/)
-* [Socket.IO](http://socket.io/)
-* [PhantomJS](http://www.phantomjs.org/)
-* [Node-Tap](https://github.com/isaacs/node-tap)
-* [Node-Charm](https://github.com/substack/node-charm)
-* [Node Commander](http://tjholowaychuk.com/post/9103188408/commander-js-nodejs-command-line-interfaces-made-easy)
+* [Jasmine](https://jasmine.github.io/)
+* [QUnit](https://qunitjs.com/)
+* [Mocha](https://mochajs.org/)
+* [Node](https://nodejs.org/)
+* [Socket.IO](https://socket.io/)
+* [tap-parser](https://github.com/tapjs/tap-parser)
+* [Charm](https://github.com/aheckmann/charm)
+* [Commander.js](https://github.com/tj/commander.js)
 * [JS-Yaml](https://github.com/nodeca/js-yaml)
-* [Express](http://expressjs.com/)
-* [jQuery](http://jquery.com/)
-* [Backbone](http://backbonejs.org/)
+* [Express](https://expressjs.com/)

package/lib/api.js

@@ -10,7 +10,7 @@ const Server = require('./server');
 /*
   CLI-level options:
 
-  file:                 [String]  configuration file (testem.json, .testem.json, testem.yml, .testem.yml)
+  file:                 [String]  configuration file path (JSON, YAML, JS: testem.js / .cjs / .mjs and dotted variants)
   host:                 [String]  server host to use (localhost)
   port:                 [Number]  server port to use (7357)
   launch:               [Array]   list of launchers to use for current runs (defaults to current mode)