Stryker was super easy to set up! Awesome.

$ npm start
 INFO ConfigReader Using stryker.conf.json
 INFO InputFileResolver Found 4 of 45 file(s) to be mutated.
 INFO InitialTestExecutor Starting initial test run. This may take a while.
 INFO InitialTestExecutor Initial test run succeeded. Ran 1 tests in 2 seconds (net 1070 ms, overhead 2 ms).
 INFO MutatorFacade 1994 Mutant(s) generated
 WARN MutantTestMatcher No coverage result found, even though coverageAnalysis is "all". Assuming that all tests cover each mutant. This might have a big impact on the performance.
 INFO SandboxPool Creating 8 test runners (based on CPU count)
[...]
Ran all tests for this mutant.
Ran 0.97 tests per mutant on average.
---------------|---------|----------|-----------|------------|----------|---------|
File           | % score | # killed | # timeout | # survived | # no cov | # error |
---------------|---------|----------|-----------|------------|----------|---------|
All files      |   55.27 |     1042 |        60 |        892 |        0 |       0 |
 dom-parser.js |   66.18 |      132 |         3 |         69 |        0 |       0 |
 dom.js        |   59.85 |      529 |        30 |        375 |        0 |       0 |
 entities.js   |    2.03 |        5 |         0 |        241 |        0 |       0 |
 sax.js        |   66.07 |      376 |        27 |        207 |        0 |       0 |
---------------|---------|----------|-----------|------------|----------|---------|
 INFO HtmlReporter Your report can be found at: reports/mutation/html/index.html
 INFO Stryker Done in 9 minutes 54 seconds.

I will wait for any reply before going further, I think the PR is already big enough.

To verify that nothing broke since forked, I did the following procedure

// assuming restore-test was checked out and npm i was run once before
git checkout $TAG
git checkout restore-tests -- test
//in test/**/*.vows.js point all imports to the correct location for this version
npx vows test/**/*.vows.js

Result:
v0.1.27 (last version published by original author)

      ✗ text & < 
        »        
        actual expected 
         
        <div xmlns="http://www.w3.org/1999/xhtml"> ©&amp;nbsp&amp;copy</div> 
         // /run/media/karfau/hdd-data/dev/xmldom/node_modules/vows/lib/assert/macros.js:14 
  ✗ Broken » 71 honored ∙ 1 broken (3.567s) 

This is this assertion, so I fixed it by adding back \u00a0.

v0.1.28-not-published (last tag pushed by original author)

      ✗ text & < 
        »        
        actual expected 
         
        <div xmlns="http://www.w3.org/1999/xhtml"> ©&amp;nbsp&amp;copy</div> 
         // /run/media/karfau/hdd-data/dev/xmldom/node_modules/vows/lib/assert/macros.js:14 
  ✗ Broken » 71 honored ∙ 1 broken (3.762s) 

Same assertion as above, so the regression was introduced by him.
Again fixed by adding back normal .

0.3.0 (first version with actual changes, no more v in the tag)

  ✓ OK » 72 honored (3.274s) 

since no code changes where done since that version: DONE 🎉

My biggest criticism is that the change from fb6f516 shows way too much diff on GitHub. I would strongly favor keeping the formatting change in a separate PR and consider using something automatic such as eslint, "Standard JS", or Prettier.

Just to make sure we are talking about the same thing:
When looking at that commit with github I don't see any changes in spaces or tabs or indentation:

so I checked the difference in my IDE:

So it's line separators... this change was of course unintended. But t's also a bit strange.
The related git setting is set to input since I'm on linux. I'm currently checking the details. It's possible that a mixture of line endings exists in the repo. Assuming I find something, do we generally agree that we should unify the line endings to LF in the repo as soon as possible?

Regarding splitting out into several PRs, that's fine. (I seem to have misunderstood your message in the issue as "stryker" being a requirement to fix/close the issue and assuming they should go into one PR.)

So it's line separators...

yup

It's possible that a mixture of line endings exists in the repo.

I would not be surprised.

I generally use command-line tools together with gitx, didn't think of anything going on with the IDE.

I would actually favor that we restore the test coverage before dealing with the LF endings or any other formatting items.

In terms of Stryker, I could go either way at this point if the total changes do not prove excessive. I would still really like to get the nbsp fix into its own PR (and maybe an issue).

Another side point is that the name of test/parse/test-doc-witespace.js has a misspelling, it should probably be changed to: test/parse/test-doc-whitespace.vows.js.

Just thinking out loud here (and for referencing it later), this is my current plan:

• file the requested issue and one for the line separator
• on my machine for this project set core.autocrlf false
• do a fresh checkout from upstream master
• redo the minimal changes to get the vows test running and file the PR Recover vows tests, drop proof tests #59
• after that PR landed, file PR fix: Convert all line separators to LF #66 that fixes Mixed line endings in the repo #56
• after that PR landed, unset core.autocrlf false (on my machine for this project)
• and file PR fix: Restore   behavior from v0.1.27 #67 that fixes Regression regarding handling of   with "(x)html" mimeType #57
• after that PR landed, continue to contribute 😄

FYI: The checklist is complete, I will still keep the branch since there are some links to it by now and maybe also some other changes that we could pick from it. But nothing urgent.