Overhaul the public jsdom API

This introduces the new API, and a bunch of tests covering it. It replaces the old API as jsdom's default API, but the old API is still available, as explained in the new README.

The additional changes made as part of this process include:

* Changes the minimum Node.js version to v6 so we can start using new ECMAScript features.
* Changes the virtual console's omitJsdomErrors option to omitJSDOMErrors, for consistency.
* Fixes img elements to no longer fire load events unless they actually load something (which is only true in general when canvas is installed).
* Makes the browser vm shim better in a few ways:
  - Use of `this` at top level works now
  - Use of `sandbox.eval()` works more like it does in Node
  - Adds a `Script` shim
* Test reorganization and fixes:
  - Consolidates all tests of web platform features into test/to-port-to-wpts.
  - Consolidates all tests of the old API specifically to test/old-api.
  - Removes some old API tests when they were redundant with new API tests; old API will lose coverage, but it's going away eventually anyway.
  - Removes the jqueryify_url test, which wouldn't pass when offline; it's OK to lose some coverage for the old API.
  - Removes tests that weren't being run (mostly level3 stuff) or fixtures that weren't being used.
  - Updates port-finding and server setup to be more resilient in general.

.eslintignore

@@ -9,21 +9,23 @@ lib/jsdom/level3/xpath.js
 
 lib/jsdom/living/generated/**
 
+test/*.js
+!test/chai-helpers.js
+!test/karma*
+!test/util.js
+
 test/browser/files
 test/jquery-fixtures
 test/jsdom/files
 test/jsdom/leak.js
-test/level1
-test/level2
-test/level3
+test/runner
 test/sizzle
+test/to-port-to-wpts/files
+test/to-port-to-wpts/frame.js
+test/to-port-to-wpts/level1
+test/to-port-to-wpts/level2
+test/to-port-to-wpts/level3
+test/to-port-to-wpts/script.js
 test/web-platform-tests/tests
 test/web-platform-tests/to-upstream/dom/nodes/Document-createComment-createTextNode.js
 test/web-platform-tests/to-upstream/domparsing/DOMParser-dont-upstream.html
-test/window/files
-test/window/frame.js
-test/window/script.js
-test/*.js
-!test/karma*
-!test/util.js
-!test/chai-helpers.js

.eslintrc.json

@@ -56,7 +56,7 @@
     "no-case-declarations": "error",
     "no-div-regex": "off",
     "no-else-return": "error",
-    "no-empty-function": "error",
+    "no-empty-function": "off",
     "no-empty-pattern": "error",
     "no-eq-null": "error",
     "no-eval": "error",

.gitignore

@@ -5,7 +5,7 @@ gmon.out
 v8.log
 node_modules
 test/worker-bundle.js
-npm-debug.log
+npm-debug.log*
 benchmark/browser-bundle.js
 
 lib/jsdom/living/generated/**/*.js

.travis.yml

@@ -1,7 +1,7 @@
 language: node_js
 node_js:
-  - 4
-  - "7.2.1" # https://github.com/nodejs/node/issues/10806 and related regressions. Also change below.
+  - 6
+  - stable
 sudo: false
 
 git:
@@ -22,7 +22,7 @@ addons:
 
 matrix:
   include:
-    - node_js: 4
+    - node_js: 6
       env: TEST_SUITE=node-canvas-prebuilt
       script: "export CXX=g++-4.8 && npm i canvas-prebuilt && npm test"
       addons:
@@ -33,7 +33,7 @@ matrix:
           - www2.web-platform.test
           - xn--n8j6ds53lwwkrqhv28a.web-platform.test
           - xn--lve-6lad.web-platform.test
-    - node_js: 4
+    - node_js: 6
       env: TEST_SUITE=node-canvas
       script: "export CXX=g++-4.8 && npm i canvas && npm test"
       addons:
@@ -54,7 +54,7 @@ matrix:
             - libpango1.0-dev
             - libgif-dev
             - build-essential
-    - node_js: "7.2.1"
+    - node_js: stable
       env: TEST_SUITE=node-canvas
       script: "export CXX=g++-4.8 && npm i canvas && npm test"
       addons:

Contributing.md

@@ -25,7 +25,7 @@ If you can, then you've almost certainly found a bug in or missing feature of js
 
 **What spec covers this potential contribution?**
 
-Almost all of our relevant functionality is covered in either the [DOM Living Standard](http://dom.spec.whatwg.org/) or the [HTML Living Standard](http://www.whatwg.org/specs/web-apps/current-work/). There are various obsolete W3C specs ("DOM Level 2" etc.) that were never really implemented in browsers, and there is also the "DOM Level 4" W3C fork of the WHATWG DOM Living Standard. But we try to stick to the two main WHATWG specs for jsdom these days.
+Almost all of our relevant functionality is covered in either the [DOM Living Standard](https://dom.spec.whatwg.org/) or the [HTML Living Standard](https://html.spec.whatwg.org/multipage/). There are various obsolete W3C specs ("DOM Level 2" etc.) that were never really implemented in browsers, and there is also the "DOM Level 4" W3C fork of the WHATWG DOM Living Standard. But we try to stick to the two main WHATWG specs for jsdom these days.
 
 Other specs might pop up from time to time, especially in regard to CSS stuff. In general Mozilla's Servo project provides [good guidance on relevant places to look](https://github.com/servo/servo/wiki/Relevant-spec-links). [platform.html5.org](https://platform.html5.org/) is also pretty comprehensive.
 
@@ -39,31 +39,31 @@ First you'll want to `npm install`. Then, configure your system to run the web p
 
 ### Web platform feature tests
 
-All tests for web platform features (as opposed to features of jsdom itself, such as the `jsdom.*` APIs) should be in [web-platform-tests](https://github.com/w3c/web-platform-tests) format. We have some infrastructure for running these directly against jsdom documents. So ideally, when contributing a bugfix or new feature, you can browser the web-platform-tests repository and find the test covering your work, and then just enable it in [the manifest file](https://github.com/tmpvar/jsdom/blob/master/test/web-platform-tests/index.js). These tests are HTML files which use a special library called [testharness.js](http://testthewebforward.org/docs/testharness-library.html) to report their results.
+All tests for web platform features (as opposed to features of jsdom itself, such as the `JSDOM()` constructor) should be in [web-platform-tests](https://github.com/w3c/web-platform-tests) format. We have some infrastructure for running these directly against jsdom documents. So ideally, when contributing a bugfix or new feature, you can browser the web-platform-tests repository and find the test covering your work, and then just enable it in [the manifest file](https://github.com/tmpvar/jsdom/blob/master/test/web-platform-tests/index.js). These tests are HTML files which use a special library called [testharness.js](http://testthewebforward.org/docs/testharness-library.html) to report their results.
 
 However, the web-platform-tests project is not fully comprehensive. If you need to write your own test for a web platform feature, place it in our [to-upstream](https://github.com/tmpvar/jsdom/tree/master/test/web-platform-tests/to-upstream) directory. (It's so named because, over time, we hope to upstream these tests back to the web-platform-tests repository, so all browsers can benefit from them.) Note that you may need to create new directory structure, paralleling that of the main [web-platform-tests](https://github.com/w3c/web-platform-tests) repository.
 
 **To run all web-platform-tests:** `npm run test-wpt`
 
 **To run the to-upstream web-platform-tests:** `npm run test-tuwpt`
 
+**To run specific web-platform-tests already in the manifest**: `npm run test-wpt -- --fgrep dom/events`
+
 (Note for future reference for the maintainers: to update the submodules used for the web-platform-tests use the command `git submodule update --recursive --remote`.)
 
 ### jsdom API tests
 
-If you are testing something that can only be accomplished through the jsdom API, and not inside a normal web browser, you'll want to write a different kind of test.
-
-Our own test suites are currently being transitioned from nodeunit to [mocha](https://mochajs.org/) and [chai](http://chaijs.com/). Some of the test suites are run using nodeunit, while others are run using mocha. So if you would like to run a specific test, you will have to first figure out which kind it is. A test file containing `describe("foo", ...)` and `specify("foo", ...)` calls is for mocha. A test file containing `exports[foo] = ...` definitions is for nodeunit. After the transition finishes, there will be no nodeunit tests remaining.
+If you are testing something that can only be accomplished through the jsdom API, and not inside a normal web browser, you'll want to write a different kind of test. Such tests are written using [Mocha](https://mochajs.org/) and [Chai](http://chaijs.com/).
 
-All new tests should be written in the mocha format. To do that, simply add a file in the appropriate place (usually `test/jsdom`) following the surrounding conventions. Then, add it to the manifest at `test/index.js`.
+To write such a test that, simply add a file in `test/api/`, following the surrounding conventions. Then, add it to the manifest at `test/index.js`.
 
-**To run all mocha tests:** `npm run test-mocha-all`
+**To run all API tests:** `npm run test-api`
 
-**To run a specific mocha test:** `npm run test-mocha -- test/jsdom/env.js`
+**To run a specific API test:** `npm run test-mocha -- test/api/from-file.js`
 
-**To run older tests (and also web-platform-tests):** see `npm run test-old`
+### Older tests
 
-(The older tests also include a lot of web platform feature tests that are stuck in nodeunit format for now. We'd like to eventually move them to web-platform-tests format.)
+Although ideally you should not need to worry about this, there are some tests that are for legacy reasons not in the right place, or test old parts of jsdom. New tests should not be contributed following those patterns, but we're keeping them around for coverage until we can convert them to the appropriate format. If you run `npm test`, you will get the full test suite, including such old tests.
 
 ### Testing against the browser