.gitattributes

@@ -0,0 +1,11 @@
+# Set the default behavior, in case people don't have core.autocrlf set
+* text=auto
+
+# Require Unix line endings
+* text eol=lf
+
+# Denote all files that are truly binary and should not be modified.
+*.png binary
+*.jpg binary
+*.ico binary
+*.gif binary

.github/FUNDING.yml

@@ -0,0 +1,3 @@
+# These are supported funding model platforms
+
+github: [isaacs]

.github/workflows/ci.yml

@@ -0,0 +1,36 @@
+name: ci
+
+on:
+  push:
+    paths-ignore:
+      - 'docs/**'
+      - 'docs-content/**'
+      - '*.md'
+  pull_request:
+    paths-ignore:
+      - 'docs/**'
+      - 'docs-content/**'
+      - '*.md'
+
+jobs:
+  test:
+    runs-on: ${{ matrix.os }}
+
+    strategy:
+      matrix:
+        node-version: [10.0.x, 10.x, 12.0.x, 12.x, 14.0.x, 14.x, 15.x]
+        os: [ubuntu-latest]
+
+    steps:
+      - uses: actions/checkout@v2
+
+      - name: Use Node.js
+        uses: actions/setup-node@v2.1.4
+        with:
+          node-version: ${{ matrix.node-version }}
+      - name: Install
+        run: |
+          npm install --ignore-scripts
+      - name: Run tests
+        run: |
+          npm test --color=always -- -c -t0

.gitignore

@@ -1,4 +1,26 @@
-node_modules/
-coverage/
-.nyc_output/
-nyc_output/
+/*
+/.*
+
+!bin/
+!lib/
+!settings.js
+!docs/
+/docs/public
+/docs/node_modules
+/docs/.cache
+!package.json
+!package-lock.json
+!README.md
+!CONTRIBUTING.md
+!LICENSE
+!CHANGELOG.md
+!example/
+!scripts/
+!tap-snapshots/
+!test/
+!.travis.yml
+!.gitignore
+!.gitattributes
+!coverage-map.js
+!postpublish.sh
+!netlify.toml

CONTRIBUTING.md

@@ -1,15 +1,13 @@
+Please consider signing [the neveragain.tech pledge](http://neveragain.tech/)
+
 - Check the [issues](https://github.com/tapjs/node-tap/issues) to see
   stuff that is likely to be accepted.
 - Every patch should have a new test that fails without the patch and
   passes with the patch.
-- All tests should pass on Node 0.8 and above.  If some tests have to
-  be skipped for very old Node versions that's fine, but the
-  functionality should still work as intended.
-- Run `npm run regen-fixtures` to re-generate the output tests
-  whenever output is changed.  However, when you do this, make sure to
-  check the change to ensure that it's what you intended, and that it
-  didn't cause any other inadvertent changes.
-- Prefer adding cases to an existing test rather than writing a new
-  one from scratch.  For example, add a new test in `test/test/*.js`
-  rather than create a new test that validates test output.
-- Docs should be changed on the `gh-pages` branch
+- All tests should pass on Node 8 and above.  If some tests have to be
+  skipped for very old Node versions that's fine, but the functionality
+  should still work as intended.
+- Run `npm run snap` to re-generate the output tests whenever output is
+  changed.  However, when you do this, make sure to check the change to
+  ensure that it's what you intended, and that it didn't cause any other
+  inadvertent changes.

README.md

@@ -3,10 +3,12 @@
 A <abbr title="Test Anything Protocol">TAP</abbr> test framework for
 Node.js.
 
-[![Build Status](https://travis-ci.org/tapjs/node-tap.svg?branch=master)](https://travis-ci.org/tapjs/node-tap) [![Build Status](https://ci.appveyor.com/api/projects/status/913p1ypf21gf4leu?svg=true)](https://ci.appveyor.com/project/isaacs/node-tap) [![Coverage Status](https://coveralls.io/repos/tapjs/node-tap/badge.svg?branch=master&service=github)](https://coveralls.io/github/tapjs/node-tap?branch=master)
+![Build Status](https://github.com/tapjs/node-tap/workflows/ci/badge.svg)
 
-It includes a command line test runner for consuming TAP-generating
-test scripts, and a JavaScript framework for writing such scripts.
+_Just wanna see some code? [Get started!](http://www.node-tap.org/basics/)_
+
+It includes a command line test runner for consuming TAP-generating test
+scripts, and a JavaScript framework for writing such scripts.
 
 * [Getting started guide](http://www.node-tap.org/basics/)
 * Built-in [test coverage](http://www.node-tap.org/coverage/)
@@ -15,8 +17,142 @@ test scripts, and a JavaScript framework for writing such scripts.
   * Great [promise support](http://www.node-tap.org/promises/)
   * Comprehensive [assert library](http://www.node-tap.org/asserts/)
   * Other [advanced stuff](http://www.node-tap.org/advanced/)
-* [Command-line interface](http://www.node-tap.org/cli/) for running
-  tests (whether they use node-tap or not)
+  * Mocha-like [BDD DSL](http://www.node-tap.org/mochalike/)
+  * [Parallel Testing](http://www.node-tap.org/parallel/)
+* [Command-line interface](http://www.node-tap.org/cli/) for running tests
+  (whether they use node-tap or not)
+
+See [the changelog](http://www.node-tap.org/changelog/) for recent updates,
+or just get started with [the basics](http://www.node-tap.org/basics/).
+
+All this is too much to manage in a single README file, so head over to
+[the website](http://www.node-tap.org/) to learn more.
+
+## Why TAP?
+
+Why should you use this thing!?  **LET ME TELL YOU!**
+
+Just kidding.
+
+Most frameworks spend a lot of their documentation telling you why they're
+the greatest.  I'm not going to do that.
+
+### <i lang="it" title="all tastes are tastes">tutti i gusti sono gusti</i>
+
+Software testing is a software and user experience design challenge that
+balances on the intersection of many conflicting demands.
+
+Node-tap is based on [my](http://izs.me) opinions about how a test
+framework should work, and what it should let you do.  I do _not_ have any
+opinion about whether or not you share those opinions.  If you do share
+them, you will probably enjoy this test library.
+
+1. **Test files should be "normal" programs that can be run directly.**
+
+   That means that it can't require a special runner that puts magic
+   functions into a global space.  `node test.js` is a perfectly ok way to
+   run a test, and it ought to function exactly the same as when it's run
+   by the fancy runner with reporting and such.  JavaScript tests should be
+   JavaScript programs; not english-language poems with weird punctuation.
+
+2. **Test output should be connected to the structure of the test file in a
+   way that is easy to determine.**
+
+   That means not unnecessarily deferring test functions until `nextTick`,
+   because that would shift the order of `console.log` output.  Synchronous
+   tests should be synchronous.
+
+3. **Test files should be run in separate processes.**
+
+   That means that it can't use `require()` to load test files.  Doing
+   `node ./test.js` must be the exact same sort of environment for the test
+   as doing `test-runner ./test.js`.  Doing `node test/1.js; node
+   test/2.js` should be equivalent (from the test's point of view) to doing
+   `test-runner test/*.js`.  This prevents tests from becoming implicitly
+   dependent on one anothers' globals.
+
+4. **Assertions should not normally throw (but throws MUST be handled
+   nicely).**
+
+   I frequently write programs that have many hundreds of assertions based
+   on some list of test cases.  If the first failure throws, then I don't
+   know if I've failed 100 tests or 1, without wrapping everything in a
+   try-catch.  Furthermore, I usually want to see some kind of output or
+   reporting to verify that each one actually ran.
+
+   Basically, it should be your decision whether you want to throw or not.
+   The test framework shouldn't force that on you, and should make either
+   case easy.
+
+5. **Test reporting should be separate from the test process, included in
+   the framework, and enabled by default for humans.**
+
+   The [raw test output](https://www.node-tap.org/tap-format/) should be
+   machine-parseable and human-intelligible, and a separate process should
+   consume test output and turn it into a [pretty summarized
+   report](https://www.node-tap.org/reporting/).  This means that test data
+   can be stored and parsed later, dug into for additional details, and so
+   on.  Also: nyan cat.
+
+6. **Writing tests should be easy, maybe even fun.**
+
+   The lower the barrier to entry for writing new tests, the more tests get
+   written.  That means that there should be a relatively small vocabulary
+   of actions that I need to remember as a test author.  There is no
+   benefit to having a distinction between a "suite" and a "subtest".
+   Fancy DSLs are pretty, but more to remember.
+
+   That being said, if you return a Promise, or use a DSL that throws a
+   decorated error, then the test framework should Just Work in a way that
+   helps a human being understand the situation.
+
+7. **Tests should output enough data to diagnose a failure, and no more or
+   less.**
+
+   Stack traces pointing at JS internals or the guts of the test framework
+   itself are not helpful.  A test framework is a serious UX challenge, and
+   should be treated with care.
+
+8. **Test coverage should be included.**
+
+   Running tests with coverage changes the way that you think about your
+   programs, and provides much deeper insight.  Node-tap bundles
+   [NYC](https://istanbul.js.org/) for this.
+
+   It _does_ necessarily change the nature of the environment a little bit.
+   But in this case, it's worth it, and NYC has come a long way towards
+   maintaining this promise.
+
+   Coverage _enforcement_ is not on by default, but I strongly encourage
+   it.  You can put `"tap":{"check-coverage":true}` in your package.json,
+   or pass [`--100`](https://www.node-tap.org/100/) on the command line.
+   In a future version, it will likely be enabled by default.
+
+9. **Tests should not require more building than your code.**
+
+   Babel and Webpack are lovely and fine.  But if your code doesn't require
+   compilation, then I think your tests shouldn't either.  Tap is extremely
+   [promise-aware](https://www.node-tap.org/promises/).  JSX, TypeScript,
+   Flow, and ES-Modules are
+   [built-in](https://www.node-tap.org/using-with/) when tests are run by
+   the tap CLI.
+
+10. **Tests should run as fast as possible, given all the prior
+    considerations.**
+
+   As of version 10, tap supports [parallel
+   tests](https://www.node-tap.org/parallel/).  As of version 13, the test
+   runner defaults to running the same number of parallel tests as there
+   are CPUs on the system.
+
+   This makes tests significantly faster in almost every case, on any machine
+   with multiple cores.
+
+Software testing should help you build software.  It should be a security
+blanket and a quality ratchet, giving you the support to undertake massive
+refactoring and fix bugs without worrying.  It shouldn't be a purification
+rite or a hazing ritual.
 
-All this is too much to manage in a single README file, so head over
-to [the website](http://www.node-tap.org/) to learn more.
+There are many opinions left off of this list!  Reasonable people can
+disagree.  But if you find yourself nodding along, [maybe tap is for
+you](https://www.node-tap.org/basics/).